vulnerability / NVI-00008870 / Revision 1
Caddy has an RFC 7230 §6.1 compliance issue / Hop-by-hop headers that leak through
GitHub lists this reviewed advisory for github.com/caddyserver/caddy/v2. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.
This report has not inspected your inventory, configuration, deployed build, reachability or evidence. A catalog listing and a severity score do not establish exposure or compromise.
01 / Meaning
Why it matters
Published affected context helps an owner decide what evidence to gather. This report has not examined your application.
02 / Applicability
The affected context
Affected versions, configuration prerequisites and known exclusions are public. Confirm each one against the deployed service.
github.com/caddyserver/caddy/v2
source listed<= 2.11.4
### AI Disclosure This vulnerability was discovered via deepseek-v4-pro[1m] for finding potential vulnerabilities / inconsistencies in the code base. I made the AI check if Caddy is compliant with various RFCs, incl. 7230. I also used it to help write the PoC, since it was honestly much faster than writing it by hand. I also let it write parts of this advisory text for brevity's sake, but had to rewrite half of it by hand. ### Summary Caddy's reverse proxy fails to strip RFC 7230 hop-by-hop headers from upstream responses when handling WebSocket upgrades (HTTP 101 Switching Protocols). Headers including `Alt-Svc`, `Keep-Alive`, `Proxy-Authenticate`, `Transfer-Encoding`, or `Trailer`, which Caddy actually correctly strips for normal HTTP responses, pass through unfiltered to the client during protocol upgrades. An upstream that sets these headers (intentionally or otherwise) can inject them into client responses, enabling connection hijacking via `Alt-Svc`, cookie injection via `Set-Cookie`, and proxy authentication phishing. The normal response path in `finalizeResponse` correctly strips all hop-by-hop headers before forwarding, but the 101 code path returns early, skipping the
03 / Response
What to do next
- investigate
Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.
Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system. GitHub Advisory Database
A fixed release is not deployment evidence.
Check current vendor support and compatibility. After making a change, verify the deployed build and relevant runtime conditions. Keep the evidence, owner and time. An updated lockfile alone does not prove what is running.
04 / Limits
What this report cannot establish
- Customer inventory, deployment, reachability and exploitation have not been inspected.
05 / Provenance
Sources you can inspect
Each assertion retains its source. Mirrored records may repeat one underlying publisher; additional links are not independent corroboration.
- GHSA-8qx7-j2v2-x6q5 ↗
GitHub Advisory Database · vendor advisory
Observed . GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.
Public revision history
Only published revisions appear here. Routine fetches do not create a material-change event.
- Revision 1 ·
First indexed by Null; source disclosure date is shown separately.