CVE-2026-27585: 
NixOS vulnerability analysis and mitigation

CVE-2026-27585 is a path sanitization bypass vulnerability in Caddy's file matcher that allows unauthenticated remote attackers to bypass path-based security protections by exploiting improper handling of backslash characters in glob patterns. It affects all versions of Caddy prior to 2.11.1 (Go module github.com/caddyserver/caddy/v2). The vulnerability was reported by researcher parrot409, published to the GitHub Advisory Database on February 23, 2026, and to the NVD on February 24, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, Caddy Release).

The root cause is improper input validation (CWE-20) in Caddy's file matcher (modules/caddyhttp/fileserver/matcher.go). When the try_files directive processes request paths, it sanitizes glob special characters (*, [, ?) by escaping them, but fails to escape backslashes. In Unix glob semantics, a backslash before a non-special character is silently ignored — for example, the pattern h\ello* matches hello world. An attacker can exploit this by URL-encoding a backslash (%5c) in a request path (e.g., /do%5ccuments/) so that a path-based access control rule matching /documents/* is bypassed, because the glob expansion treats do\cuments as equivalent to documents. The vulnerability requires a specific Caddy configuration where the try_files directive and the filtering route/handle are in separate blocks, or where header directives execute before try_files (GitHub Advisory, Caddy Source).

Successful exploitation allows an unauthenticated network attacker to bypass path-based access controls, potentially gaining unauthorized read access to protected files and directories (confidentiality impact) or circumventing security headers and content policies applied to specific paths (integrity impact). The vulnerability does not directly impact availability. In layered architectures where an upstream reverse proxy (e.g., nginx) enforces path-based restrictions and Caddy serves as the backend with try_files, the upstream protection can be entirely bypassed, exposing sensitive files such as credentials, configuration files, or private documents (GitHub Advisory).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, demonstrating the bypass using a Docker Compose setup with nginx and Caddy. The PoC uses curl 'localhost:8000/secre%5ct/secret.txt' to access a file protected by an nginx location /secret { return 403; } rule. There is no evidence of active in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.085% (0.000850), placing it in the 31st percentile for exploitation probability within 30 days. The vulnerability is not listed in the CISA KEV catalog (GitHub Advisory, Feedly).

1. Reconnaissance: Identify Caddy server instances running versions prior to 2.11.1 using banner grabbing or service fingerprinting tools (e.g., Shodan, curl -I). Confirm the server uses try_files with {path} in its Caddyfile configuration.
2. Identify protected paths: Probe the target for path-based access restrictions (e.g., paths returning HTTP 403) to identify candidate protected directories such as /secret/, /documents/, or /uploads/.
3. Craft bypass request: Construct a URL where a backslash (\, URL-encoded as %5c) is inserted within the protected path segment. For example, to bypass protection on /secret/, request /secre%5ct/secret.txt.
4. Send the request: Issue the crafted HTTP GET request to the server: curl 'http://target:8000/secre%5ct/secret.txt'. The glob expansion in Caddy's file matcher treats secre\t as equivalent to secret, matching the file on disk and serving it despite the upstream access control rule blocking /secret.
5. Access protected content: If the configuration is vulnerable (i.e., try_files and the filtering route are in separate blocks), the server returns the protected file's contents, confirming the bypass (GitHub Advisory).

• Network: HTTP GET requests containing %5c (URL-encoded backslash) within path segments that correspond to known protected directories (e.g., /secre%5ct/, /do%5ccuments/); requests to protected paths that return HTTP 200 instead of the expected 403.
• Logs: Caddy or upstream proxy access logs showing requests with %5c in the URI path; successful responses (HTTP 200) to paths that should be blocked by access control rules; repeated probing of multiple path variations with encoded backslashes.
• File System: No direct file system artifacts are expected from read-only exploitation; however, unexpected access patterns to sensitive files (e.g., configuration files, secrets) may be visible in file access audit logs if enabled.

The primary remediation is to upgrade Caddy to version 2.11.1 or later, which fixes the backslash sanitization gap in the file matcher's globSafeRepl replacer (Caddy Release). Organizations unable to patch immediately should review their Caddyfile configurations to ensure that try_files and access-control route/handle directives are placed within the same block (which is not vulnerable), rather than in separate blocks. Additionally, deploying a Web Application Firewall (WAF) rule to block or normalize requests containing %5c or literal backslashes in URI paths can serve as a temporary compensating control. Monitoring access logs for requests with encoded backslashes in path segments is recommended to detect exploitation attempts (GitHub Advisory).

The vulnerability was disclosed by Caddy maintainer mholt as part of the Caddy 2.11.1 release, which bundled fixes for six CVEs simultaneously. The release notes explicitly credit researcher parrot409 for the discovery. The advisory notes that an LLM was used to polish the report, reflecting a growing trend in AI-assisted vulnerability disclosure. No significant independent researcher commentary or broad media coverage has been identified beyond standard vulnerability database aggregation (Caddy Release, GitHub Advisory).