CVE-2026-55458

### 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 stripping entirely. ### Details In `modules/caddyhttp/reverseproxy/reverseproxy.go`, the `finalizeResponse` method (line 1178) handles upstream responses. For all normal responses, it strips hop-by-hop headers before copying to the client: ```go // reverseproxy.go:1194-1198 removeConnectionHeaders(res.Header) for _, h := range hopHeaders { res.Header.Del(h) } ``` However, the 101 Switching Protocols check at line 1187 returns before this stripping code: ```go // reverseproxy.go:1186-1192 if res.StatusCode == http.StatusSwitchingProtocols { var wg sync.WaitGroup h.handleUpgradeResponse(logger, &wg, rw, req, res) wg.Wait() return nil // <-- returns BEFORE removeConnectionHeaders and hopHeaders loop } ``` Inside `handleUpgradeResponse` (`streaming.go:60-91`), all u