CVE-2026-27587: 
NixOS vulnerability analysis and mitigation

CVE-2026-27587 is a path-based access control bypass vulnerability in the Caddy web server's HTTP path request matcher, caused by improper handling of case sensitivity in percent-encoded (%xx) path segments. Affecting Caddy versions 2.10.2 through 2.11.0, the flaw allows unauthenticated remote attackers to bypass path-based routing rules and any associated access controls by altering the casing of percent-encoded characters in the request path. The vulnerability was disclosed on February 23, 2026, and patched in version 2.11.1 released the same day. It carries a CVSS v3.1 base score of 9.1 (Critical) and a CVSS v4.0 base score of 7.7 (High) (Github Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-178 (Improper Handling of Case Sensitivity). In modules/caddyhttp/matchers.go, MatchPath.MatchWithError correctly lowercases the request path (strings.ToLower(r.URL.Path)) for normal pattern matching, but switches to a separate code branch when the match pattern contains a % character. In this branch, the comparison string is built from r.URL.EscapedPath() without applying strings.ToLower, meaning case differences in the request path cause the match to fail and the request to fall through to subsequent routes. For example, a rule blocking /admin%2Fpanel will correctly deny GET /admin%2Fpanel but will allow GET /ADMIN%2Fpanel to pass through. A public proof-of-concept bash script demonstrating the bypass using curl is included in the GitHub Security Advisory (Github Advisory, Caddy Advisory).

Successful exploitation allows an unauthenticated network attacker to bypass path-based access controls and routing policies enforced by Caddy, potentially gaining unauthorized access to sensitive or protected endpoints. The impact is most severe in deployments where Caddy is the sole enforcement point for access control on routes using percent-encoded path patterns (e.g., encoded slashes like %2F). If the backend application is case-insensitive or normalizes paths, the bypassed request will be processed as if it matched the protected route, leading to unauthorized data disclosure and integrity violations (Github Advisory, Caddy Advisory).

A proof-of-concept exploit script is publicly available in the GitHub Security Advisory, requiring only bash and curl to execute. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.042% (0.000420), placing it in the lower percentile for near-term exploitation probability (Github Advisory, Feedly).

1. Reconnaissance: Identify internet-facing Caddy server instances running versions 2.10.2 through 2.11.0 using tools like Shodan or Censys, or by inspecting the Server: Caddy response header.
2. Identify protected paths: Probe the target to discover path-based access control rules that use percent-encoded patterns (e.g., /admin%2Fpanel, /api%2Finternal). A 403 response to a request with a lowercase percent-encoded path indicates a blocking rule is in place.
3. Craft bypass request: Modify the casing of the alphabetic characters in the path segment (before the %xx sequence) to uppercase. For example, change /admin%2Fpanel to /ADMIN%2Fpanel.
4. Send bypass request: Issue the crafted HTTP request using curl or a similar tool:

   curl -v -H 'Host: target.example.com' http://target.example.com/ADMIN%2Fpanel

5. Achieve access: If the backend application normalizes or is case-insensitive to the path, the request is processed as if it accessed the protected endpoint, returning a 200 OK and the protected resource instead of a 403 Forbidden (Github Advisory, Caddy Advisory).

• Network: HTTP requests to paths containing percent-encoded sequences (e.g., %2F, %2f) where the alphabetic path components use mixed or uppercase casing (e.g., /ADMIN%2Fpanel, /Api%2FInternal); these requests returning HTTP 200 where a 403 would be expected.
• Logs: Caddy access log entries (http.log.access) showing requests with uppercase or mixed-case path segments containing %xx sequences that result in a status: 200 response, particularly to paths that are configured with blocking rules. Example log pattern:

  {"uri":"/ADMIN%2Fpanel", ..., "status":200}

• Logs: Absence of expected 403 log entries for known-protected percent-encoded paths when requests with altered casing are received (Github Advisory).

Upgrade Caddy to version 2.11.1 or later, which contains the fix for this vulnerability by ensuring the escaped-path matching branch also lowercases the comparison string before calling path.Match (Caddy Release). If immediate patching is not possible, implement additional authentication layers (e.g., HTTP Basic Auth, mTLS, or upstream authentication middleware) that are independent of Caddy's path matcher for security-critical endpoints. Additionally, review Caddyfile configurations to identify any path matchers using %xx patterns and consider supplementing them with case-insensitive application-level controls on the backend (Github Advisory, Red Hat Bugzilla).

The vulnerability was discovered and reported by security researcher Asim Viladi Oglu Manizada using a custom AI agent pipeline, which was then manually reproduced and validated. The Caddy maintainer (mholt) published the advisory and patch on February 23, 2026, as part of the broader Caddy 2.11.1 release that addressed six CVEs simultaneously. The vulnerability was noted by The Hacker Wire on Mastodon and Bluesky, and was picked up by Linux security aggregators including LinuxSecurity.com. The use of an AI-assisted discovery pipeline was explicitly disclosed in the advisory per Caddy's project policy (Caddy Release, Github Advisory).