Go net/http CVE-2026-78660
HIGHAttack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessInfluence/control HTTP/2 backend response
-
DeliveryInject malformed framing-related headers
-
ExploitGo reverse proxy forwards headers to HTTP/1 client
-
ExecutionNon-strict HTTP/1 client desynchronizes parsing
-
ImpactResponse smuggling poisons client's response stream
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V4 - API and Web Service HTTP request consistency
|
| Exploitation Conditions | Exploitation requires a specific deployment: a Go application using net/http (or golang.org/x/net/http2) operating as a reverse proxy that terminates HTTP/2 upstream and serves an HTTP/1 downstream client. The upstream HTTP/2 response must contain malformed framing-related headers (which Go historically did not reject), AND the downstream HTTP/1 client must itself fail to parse strictly. Exploitation is further limited by the attacker needing to influence the backend/upstream response content; pure HTTP/2-only or strict HTTP/1 client deployments are not affected, and non-proxy Go servers are not in scope. |
| Impact | Signals are consistent and point to a real-but-not-urgent issue. The input CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, 7.5 HIGH) reflects an integrity-only impact (response smuggling, CWE-444) with no confidentiality or availability loss. The EPSS score is very low (0.19%, 8th percentile) and CISA SSVC lists Exploitation: none, Automatable: yes, Technical Impact: partial - so there is no evidence of active exploitation and the vulnerability is NOT in CISA KEV. No public POC is indicated. The main tension is that the input CVSS uses AC:L and PR:N, yet the description sets out several stacked prerequisites (Go deployed as an HTTP/2-to-HTTP/1 reverse proxy, a backend that emits malformed framing headers, AND a non-strict HTTP/1 client); this realistically implies higher attack complexity than AC:L suggests. Overall this is a legitimate hardening/defense-in-depth fix in a very widely used library rather than a drop-everything emergency: patch in normal cycles, prioritizing internet-facing Go reverse proxies. |
| Exploit ScenarioDerived | A Go service using net/http or golang.org/x/net/http2 acts as a reverse proxy, speaking HTTP/2 to a backend and HTTP/1 to a downstream client. A backend (or an attacker able to influence backend responses) returns malformed framing-related headers that Go's lax HTTP/2 handling forwards verbatim; a downstream HTTP/1 client that also parses non-strictly then desynchronizes and interprets part of the stream as a separate smuggled response. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 09, 2026
Response smuggling is possible in Go's HTTP/2 implementation (net/http and golang.org/x/net/http2) when a program acts as a reverse proxy that receives an HTTP/2 upstream response and forwards it to a downstream HTTP/1 client. Because Go has historically not rejected malformed framing-related headers such as connection-specific or length-related headers that RFC 7540 requires to be treated as malformed, those headers can be relayed verbatim; if the downstream HTTP/1 client is also lenient in parsing, the attacker can desynchronize the response stream and smuggle content. The issue is unauthenticated from the network perspective (CVSS PR:N) but exploitation is constrained to that specific proxy topology and requires attacker influence over the upstream response plus a non-strict HTTP/1 client; there is no public exploit identified at time of analysis, EPSS is low at 0.19% (8th percentile), and CISA SSVC records no exploitation with partial technical impact.
RemediationAI
Patch available per vendor advisory: upgrade to the Go toolchain release containing the fixes from https://go.dev/cl/835145 and https://go.dev/cl/836385, and update any dependency on golang.org/x/net/http2 to the corresponding corrected version (track via GO-2026-6610, https://pkg.go.dev/vuln/GO-2026-6610, and issue 81115, https://go.dev/issue/81115). Because the vulnerability requires a specific proxy topology, the most effective interim mitigation is to avoid the risky translation path: either keep the downstream leg on HTTP/2 (HTTP/2-to-HTTP/2 proxying is not affected), or ensure the reverse proxy strips or rejects malformed framing-related headers such as Transfer-Encoding, Content-Length conflicts and other connection-specific headers before forwarding, accepting the trade-off that this can break backend services that rely on non-standard header behavior. Conversely, upgrading or hardening the downstream HTTP/1 client to parse strictly (rejecting ambiguous framing) also breaks the chain, at the cost of compatibility with loosely built servers. There is no public exploit identified at time of analysis and no CISA KEV exploitation, so remediation can be scheduled in a normal patch cycle rather than treated as an emergency, but proxy-heavy Go deployments should be prioritized.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-444 (inconsistent interpretation of HTTP requests/responses), a classic desynchronization class. In HTTP/2, RFC 7540 section 8.1.2.6 defines connection-specific header fields and other framing-related headers as malformed and requires them to be treated as a stream error; Go's net/http, net/http/internal/http2 and the golang.org/x/net/http2 package historically did not enforce this strictly because such headers cannot interfere with HTTP/2's own binary framing. The problem only materializes at a protocol translation boundary: a Go reverse proxy terminating an HTTP/2 connection from the upstream and emitting an HTTP/1 response to the downstream client. The forwarded malformed headers (for example conflicting length or transfer-encoding semantics) can then be interpreted differently by the downstream HTTP/1 parser than by the proxy, producing a smuggling primitive. Affected components per the CPE data are cpe:2.3:a:go_standard_library:net/http, cpe:2.3:a:go_standard_library:net/http/internal/http2 and cpe:2.3:a:golang.org/x/net:golang.org/x/net/http2. Our independent assessment scores this as CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N, reflecting higher attack complexity and a scope change relative to the CVE record vector (7.5, AV:N/AC:L/S:U), which is consistent with the narrow deployment prerequisites described in the vendor advisory thread and issue tracker.
Know when Golang Org X Net Http2 gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
AC:H because exploitation needs a proxy forwarding malformed upstream headers plus a non-strict HTTP/1 client; S:C as the smuggled response affects a separate downstream client; integrity-only, so C:N/A:N.
Primary rating from Vendor (Go).
CVSS VectorVendor: Go
Lifecycle Timeline
3DescriptionCVE.org
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.
Executive ViewAI
CVE-2026-78660 affects Go's net/http and golang.org/x/net/http2 libraries in reverse-proxy deployments that translate HTTP/2 upstream responses to HTTP/1 downstream clients. In that specific topology, an unauthenticated attacker with influence over the upstream response may be able to desynchronize and smuggle response content, potentially undermining response integrity for downstream users. A vendor patch is available per advisory, no public exploit has been identified at time of analysis, and EPSS is very low, so leadership should prioritize remediation based on exposure and patch management rather than emergency incident response.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
HTTP request smuggling exploits inconsistencies in how front-end and back-end servers parse HTTP message boundaries.
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Affected Products (CPE)CVE.org
More in Golang Org X Net Http2
View allRemote denial of service in Go's HTTP/2 stack (both golang.org/x/net/http2 and the net/http standard library) allows an
Signals conflict: the original CVSS rates integrity and availability impact as high (9.1), but independent assessment de
GitHub PoC
Exploit-DB