Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.

We now delete malformed framing-related headers when received by our HTTP/2 transport, so they will not be forwarded to a potentially vulnerable HTTP/1 client.

NOTE: https://www.openwall.com/lists/oss-security/2026/10/08/9
NOTE: https://github.com/golang/go/issues/81115
NOTE: Fixed by: https://github.com/golang/go/commit/072779d81582543bf2872c259e0c6cceea728de4 (go1.27.2)
TODO: check might need tracking for golang-golang-x-net