CVE-2026-30851: 
NixOS vulnerability analysis and mitigation

CVE-2026-30851 is an authorization bypass vulnerability in Caddy's forward_auth directive with copy_headers that allows authenticated attackers to inject forged identity headers and escalate privileges. The vulnerability affects Caddy versions >= 2.10.0 and < 2.11.2, introduced as a regression by PR #6608 merged November 4, 2024. It was disclosed on March 6, 2026, and patched in Caddy v2.11.2. The CVSS v3.1 base score is 8.1 (High) per the official advisory, though Feedly's aggregated score is 8.8 (GitHub Advisory, Caddy Security Advisory).

The root cause (CWE-287: Improper Authentication; CWE-345: Insufficient Verification of Data Authenticity) lies in the parseCaddyfile function in modules/caddyhttp/reverseproxy/forwardauth/caddyfile.go. PR #6608 added a MatchNot guard to skip the Set header operation when the upstream auth service does not return a given header — preventing headers from being set to empty placeholder strings. However, this change inadvertently removed the incidental protection of the prior unconditional Set, which would overwrite any client-supplied header value. With the guard in place, when the auth service returns 200 OK without a copy_headers-listed header (e.g., X-User-Id), the MatchNot condition fires, the Set is skipped, and no Delete operation exists — leaving the original client-supplied header value intact and forwarded to the backend. An attacker with any valid (non-privileged) authentication token can exploit this by including forged identity headers (e.g., X-User-Id: admin, X-User-Role: superadmin) in their request (GitHub Advisory, Fix PR #7545).

An authenticated attacker holding any valid token can impersonate privileged users — including administrators — by injecting arbitrary values into trusted identity headers that the backend application uses for access control decisions. This results in high confidentiality and integrity impact, as the attacker can access restricted resources and perform unauthorized actions on behalf of privileged identities. Deployments most at risk include those using stateless JWT validators (which verify signatures but return no identity headers), session validators that leave identity decoding to the backend, and auth services with conditional header responses (e.g., Authelia with bypass rules) (GitHub Advisory, Caddy Security Advisory).

A proof-of-concept exploit with complete step-by-step reproduction instructions is publicly available in the official GitHub security advisory, including exact curl commands demonstrating privilege escalation (Caddy Security Advisory). The EPSS score is approximately 0.023% (7th percentile), and there is no evidence of in-the-wild exploitation at this time. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires only a valid (non-privileged) authentication token — no admin credentials are needed — making it accessible to any authenticated user of the affected application.

1. Reconnaissance: Identify Caddy deployments (versions 2.10.0–2.11.1) using the forward_auth directive with copy_headers configured. This can be done via HTTP response headers (e.g., Server: Caddy) or service fingerprinting tools like Shodan or Censys.
2. Obtain a valid token: Acquire any valid authentication token for the target application — no elevated privileges are required. This could be a low-privilege user account's JWT or session token.
3. Craft the attack request: Prepare an HTTP request that includes both the valid Authorization header and forged identity headers matching the copy_headers configuration (e.g., X-User-Id: admin and X-User-Role: superadmin).
4. Send the request: Issue the crafted request to the Caddy proxy endpoint:

   curl -v http://target:8080/ \
     -H "Authorization: Bearer token123" \
     -H "X-User-Id: admin" \
     -H "X-User-Role: superadmin"

5. Auth service validates token: The upstream auth service receives the request, validates the token, and returns 200 OK without including X-User-Id or X-User-Role in its response headers.
6. Caddy skips header sanitization: Because the auth service did not return the identity headers, the MatchNot guard fires and Caddy skips the Set operation. No Delete operation exists, so the attacker-supplied headers pass through unchanged.
7. Backend grants elevated access: The backend receives X-User-Id: admin and X-User-Role: superadmin and grants the attacker administrative access based on those forged values (Caddy Security Advisory).

• Network: HTTP requests to Caddy-proxied endpoints that include both a valid Authorization: Bearer header and identity headers such as X-User-Id, X-User-Role, Remote-User, Remote-Groups, or other headers listed in copy_headers configuration — particularly from low-privilege accounts accessing admin-restricted resources.
• Logs: Caddy access logs showing requests with identity headers (e.g., X-User-Id: admin) from users whose token does not correspond to that identity; backend application logs showing privileged actions performed by accounts that should not have elevated access.
• Logs: Caddy debug logs showing DEBUG http.handlers.reverse_proxy handling response {"handler": "copy_headers"} with no subsequent header deletion log entry, combined with a 200 auth response and client-supplied identity headers in the original request.
• Application: Unexpected administrative actions, configuration changes, or data access events attributed to non-privileged user accounts in backend application audit logs (Caddy Security Advisory).

Upgrade Caddy to version 2.11.2 or later, which adds an unconditional Delete route for each copy_headers entry before the conditional Set route, ensuring client-supplied headers are always stripped regardless of the auth service response (Fix PR #7545, Caddy Security Advisory). As a short-term workaround for deployments that cannot immediately upgrade, manually add request_header delete directives in the Caddy configuration to explicitly strip any headers listed in copy_headers before they reach the backend. Additionally, review and update auth service configurations to ensure identity headers are explicitly returned in every 200 OK response, eliminating the conditional path that triggers the vulnerability.

The vulnerability was reported by researcher NucleiAv and published by Caddy maintainer mholt on March 6, 2026. The advisory notes that an LLM was used to polish the report. A follow-up discussion in PR #7545 identified a residual edge case where client-supplied identity headers are not stripped for non-2xx auth responses (e.g., deployments allowing anonymous access), with maintainer francislavoie acknowledging the complexity of fully addressing all scenarios (Fix PR #7545). The vulnerability was picked up by security news aggregators and vulnerability databases shortly after disclosure, and an openSUSE security announcement was issued for downstream package consumers (openSUSE Security).