CVE-2026-30851
Received Received - Intake
Header Injection in Caddy forward_auth Enables Privilege Escalation

Publication date: 2026-03-07

Last updated on: 2026-03-11

Assigner: GitHub, Inc.

Description
Caddy is an extensible server platform that uses TLS by default. From version 2.10.0 to before version 2.11.2, forward_auth copy_headers does not strip client-supplied headers, allowing identity injection and privilege escalation. This issue has been patched in version 2.11.2.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-07
Last Modified
2026-03-11
Generated
2026-05-07
AI Q&A
2026-03-07
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
caddyserver caddy From 2.10.0 (inc) to 2.11.2 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-287 When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
CWE-345 The product does not sufficiently verify the origin or authenticity of data, in a way that causes it to accept invalid data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

The vulnerability in Caddy server versions 2.10.0 to before 2.11.2 involves the `forward_auth` directive when used with the `copy_headers` option. Caddy fails to strip client-supplied headers that share the same names as those specified in `copy_headers`. If the upstream authentication service returns a 200 OK status but does not include certain identity headers, Caddy does not remove any existing client-supplied headers with those names. This allows an attacker with any valid authentication token to inject forged identity headers (such as `X-User-Id` or `X-User-Role`) into requests, leading to identity injection and privilege escalation.

The root cause is a regression introduced by a code change that added a conditional guard to only set headers if the auth service response includes them, but did not delete client headers when those headers were absent. As a result, client headers persist and are forwarded to the backend, which may trust them.

The issue was fixed by adding an unconditional deletion step for each header before conditionally setting it, ensuring client-supplied headers are always removed regardless of the auth service response.


How can this vulnerability impact me? :

This vulnerability allows an attacker who possesses any valid authentication token to inject arbitrary trusted identity headers into requests forwarded by the Caddy server. Because the backend trusts these headers, the attacker can escalate privileges, potentially gaining unauthorized administrative or elevated access.

The attack requires no elevated privileges or user interaction beyond having a valid token, making it relatively easy to exploit in affected versions.

The impact includes compromise of confidentiality and integrity of the system, as unauthorized users can impersonate others or gain higher privileges, but it does not affect availability.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'The vulnerability involves client-supplied identity headers (e.g., X-User-Id, X-User-Role) not being stripped before forwarding requests to the backend when using Caddy server versions from 2.10.0 up to but not including 2.11.2 with the forward_auth directive and copy_headers option.'}, {'type': 'paragraph', 'content': 'Detection can involve monitoring HTTP requests forwarded by Caddy to check if identity headers are present that were not set by the authentication backend. Specifically, you can capture and inspect headers such as X-User-Id or X-User-Role to see if they originate from client requests rather than the auth service.'}, {'type': 'paragraph', 'content': 'Suggested commands include using network traffic inspection tools like tcpdump or Wireshark to capture HTTP headers, or using curl commands with crafted requests containing forged identity headers and a valid authentication token to test if the backend receives these headers.'}, {'type': 'list_item', 'content': "Use tcpdump to capture HTTP traffic on the relevant port: tcpdump -i <interface> -A 'tcp port <caddy_port>'"}, {'type': 'list_item', 'content': "Use curl to send a request with forged headers and a valid token: curl -H 'X-User-Id: attacker' -H 'Authorization: Bearer <valid_token>' https://<caddy_server>/protected-resource -v"}, {'type': 'list_item', 'content': 'Check backend logs or responses to verify if the forged headers are accepted and forwarded.'}] [1, 3]


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade Caddy server to version 2.11.2 or later, where the vulnerability has been patched.

The patch adds an unconditional deletion of client-supplied headers listed in copy_headers before conditionally setting headers from the authentication service response, preventing header injection.

If upgrading immediately is not possible, as a temporary measure, review and adjust your forward_auth configuration to manually strip or reject client-supplied identity headers before forwarding requests to the backend.

Additionally, monitor and audit logs for suspicious header injection attempts and restrict access tokens to minimize risk.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart