Caddy: Windows `file_server` path authorization bypass via encoded backslash

Vulnerability

On Windows, Caddy's path matcher (MatchPath.MatchWithError()) compares the raw URL path without normalizing backslashes (\) to forward slashes (/). Consequently, a request containing an encoded backslash (e.g., /private%5csecret.txt) is not matched by a route pattern such as /private/*. The file_server handler later resolves the same path using SanitizedPathJoin(), which on Windows treats the backslash as a directory separator, enabling access to files inside the protected directory [1][2]. This vulnerability affects all Caddy versions on Windows prior to a patch, including the current HEAD at the time of disclosure.

Exploitation

An unauthenticated remote attacker sends an HTTP request with an encoded backslash (%5c) in the path, for example GET /private%5csecret.txt. No authentication or special network access is required beyond the ability to reach the Caddy server. The attacker does not need user interaction or any additional privileges. The only condition is that the server uses a path matcher to restrict access to a directory and also serves files via file_server [1][2].

Impact

Successful exploitation allows an attacker to bypass path-scoped authorization or denial rules (e.g., a respond @private 403 directive) and retrieve arbitrary files from the protected directory via the file_server. The outcome is information disclosure of sensitive content that should have been blocked. No code execution or file write is achieved [1][2].

Mitigation

As of the advisory publication date (2026-06-16), no official fix has been released. The vulnerability exists in all Caddy versions on Windows. Until a patch is available, administrators should avoid relying solely on path matchers in front of file_server on Windows, or implement additional authentication and validation layers. A fix for the underlying normalization mismatch is expected in a future Caddy release [1][2].