CVE-2026-30852: 
NixOS vulnerability analysis and mitigation

CVE-2026-30852 is an information disclosure vulnerability in Caddy's vars_regexp HTTP matcher that allows unauthenticated remote attackers to leak environment variables, file contents, and system information by injecting Caddy placeholder syntax into user-controlled request input. The vulnerability affects Caddy versions 2.7.5 through 2.11.1 and was introduced by PR #5408 (merged March 2, 2023). It was reported by researcher sammiee5311, published to the GitHub Advisory Database on March 6, 2026, and patched in version 2.11.2 released the same day. The CVSS v3.1 base score is 7.5 (High), while the CVSS v4.0 score is 5.5 (Medium) (GitHub Advisory, Caddy Advisory).

The root cause is a double-expansion bug in modules/caddyhttp/vars.go at line 337 within the MatchVarsRE.MatchWithError() function, classified as CWE-74 (Injection) and CWE-200 (Exposure of Sensitive Information). When vars_regexp is configured to match against a placeholder like {http.request.header.X-Input}, Caddy's replacer (repl.Get()) first resolves the placeholder to the raw header value (expected behavior), then incorrectly passes that resolved value through repl.ReplaceAll() a second time — causing any Caddy placeholder syntax embedded in the user-supplied value (e.g., {env.DATABASE_URL}, {file./etc/passwd}, {system.hostname}) to be evaluated server-side. By contrast, header_regexp and path_regexp pass values directly to Match() without this second expansion, making this an inconsistency introduced specifically by the PR #5408 fix. Exploitation requires a configuration where vars_regexp matches user-controlled input and the capture group result is reflected back in the HTTP response (GitHub Advisory, Caddy PR #5408).

Successful exploitation allows an unauthenticated network attacker to exfiltrate sensitive server-side data without any privileges. Specifically, an attacker can read arbitrary environment variables (e.g., DATABASE_URL, AWS_SECRET_ACCESS_KEY, API keys), read file contents up to 1MB from the server filesystem (e.g., /etc/passwd, /proc/self/environ), and enumerate system metadata such as hostname, OS, and working directory. While there is no direct integrity or availability impact, leaked credentials could enable lateral movement, privilege escalation, or compromise of downstream services (GitHub Advisory, Caddy Release v2.11.2).

A proof-of-concept exploit is publicly available in the GitHub Security Advisory, consisting of concrete curl commands and a complete Caddy configuration that reproducibly demonstrates the information disclosure (Caddy Advisory). The CVSS v4.0 exploit maturity is rated PROOF_OF_CONCEPT. There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.045% (6th percentile), indicating low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Detection is available via Nessus (ID 301659) and Qualys (ID 761789) (Feedly).

1. Reconnaissance: Identify internet-facing Caddy instances running versions 2.7.5–2.11.1 using tools like Shodan or Censys, searching for the Server: Caddy response header.
2. Identify vulnerable configuration: Determine whether the target Caddy instance uses vars_regexp with a user-controlled placeholder (e.g., {http.request.header.X-Input}) as the match key and reflects the capture group in the response body.
3. Craft malicious request: Send an HTTP request with a Caddy placeholder payload in the targeted header field. For example, to leak an environment variable:

   curl -H 'X-Input: {env.SECRET_API_KEY}' http://target:8080/

4. Leak environment variables: The server evaluates {env.SECRET_API_KEY} during the second repl.ReplaceAll() pass and returns the value in the response body (e.g., Leaked: sk-PRODUCTION-abcdef123456).
5. Read sensitive files: Use {file./etc/passwd} or {file./proc/self/environ} payloads to read file contents up to 1MB:

   curl -H 'X-Input: {file./etc/passwd}' http://target:8080/

6. Enumerate system info: Use {system.hostname}, {system.os}, or {system.wd} to gather system metadata for further attack planning (Caddy Advisory).

• Network: Unusual HTTP requests containing Caddy placeholder syntax (e.g., {env.*}, {file.*}, {system.*}) in request headers such as X-Input or other user-controlled fields targeted by vars_regexp matchers; repeated requests probing different environment variable names or file paths.
• Logs: Caddy access logs showing requests with header values matching patterns like {env., {file., or {system. in fields processed by vars_regexp; response bodies containing file contents or credential-like strings reflected to clients.
• File System: No direct file system artifacts expected from read-only exploitation; however, if leaked credentials are subsequently used, look for unauthorized access in downstream systems (databases, cloud APIs).
• Process: No unusual child processes expected; the vulnerability is purely a data disclosure via the Caddy HTTP handler without code execution (Caddy Advisory).

The primary remediation is to upgrade Caddy to version 2.11.2 or later, which removes the erroneous repl.ReplaceAll() call on the resolved variable value in modules/caddyhttp/vars.go (Caddy Release v2.11.2). The one-line fix changes valExpanded := repl.ReplaceAll(varStr, "") to valExpanded := varStr, making vars_regexp consistent with header_regexp and path_regexp. As a temporary workaround for those unable to upgrade immediately, audit and disable any vars_regexp configurations that use user-controlled placeholders as match keys and reflect capture groups in responses; replacing vars_regexp with header_regexp or path_regexp where possible eliminates the vulnerable code path (GitHub Advisory).

Caddy maintainer Matt Holt (mholt) published the security advisory and released the patch on March 6, 2026, noting in the v2.11.2 release notes that vars_regexp double-expanded placeholders, "allowing some unusual configs to reveal secrets" (Caddy Release v2.11.2). The reporter (sammiee5311) noted uncertainty about whether the issue qualified as a security vulnerability given its configuration dependency, but chose responsible disclosure due to the potential for credential leakage. The advisory was picked up by security aggregators including GitLab Advisories, CVEFeed, and VulnDB shortly after publication, with community discussion on Bluesky (Caddy Advisory).