EUVD-2026-95428
GHSA-2gfw-j3c5-j46w
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify Go HTTP/1 server behind proxy
-
DeliverySend HTTP/1 CONNECT with smuggled request bytes
-
ExploitServer returns 2xx without hijacking connection
-
ExecutionProxy tunnels data while server parses it as HTTP
-
ImpactSmuggled request processed out-of-band
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, non-default server-side condition: an application HTTP handler that responds to an HTTP/1 CONNECT request with a 2xx status code AND then returns without hijacking (taking over) the underlying connection, causing the Go net/http server to keep reading HTTP requests on what should have become a tunnel. The practical impact further requires an intermediary proxy in front of the server that interprets the post-CONNECT bytes as tunneled data, creating the parser disagreement that enables request smuggling. Limiting factors: default handlers that do not 2xx-answer CONNECT, or that properly hijack the connection, are not affected; deployments with no fronting proxy see minimal impact; affected versions are net/http before 1.26.9 and the 1.27.x line before 1.27.2. |
| Impact | Despite a CVSS base score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N), the real-world priority is MODERATE-TO-LOW. Multiple independent signals converge against urgency: EPSS is only 0.18% (7th percentile), CISA SSVC lists Exploitation as 'none', and there is no KEV listing or public exploit. The one signal pointing toward concern is SSVC Automatable=yes with partial technical impact, consistent with CWE-444 request smuggling. The CVSS AC:L is arguably optimistic: the flaw only manifests when an application's own HTTP handler deliberately sends a 2xx response to an HTTP/1 CONNECT and then returns WITHOUT hijacking the connection - an atypical coding pattern - and smuggling only has impact when an intermediary proxy sits in front of the Go server and disagrees about whether the connection is a tunnel. These are non-default preconditions that AC:L does not capture, so the practical attack complexity is higher than the vector implies. Net assessment: a legitimate correctness/security bug worth patching in the normal cycle, not an emergency. |
| Exploit ScenarioDerived | A Go-based HTTP/1 server is deployed behind an intermediary proxy, and one of its handlers responds to a CONNECT request with a 2xx status but does not hijack the connection. An attacker sends a CONNECT request followed by smuggled bytes; the proxy treats the connection as an opaque tunnel while the Go server keeps parsing the trailing bytes as new HTTP requests, desynchronizing the two and enabling request smuggling. No public proof-of-concept is identified at time of analysis; exploitation requires both the specific handler behavior and a proxy in the request path. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 09, 2026
Request smuggling in the Go net/http standard library occurs when an application handler answers an HTTP/1 CONNECT request with a 2xx status and then returns without hijacking the connection, causing the server to keep parsing HTTP requests on a connection that an intermediate proxy now treats as an opaque tunnel. Affected builds are net/http before 1.26.9 and the 1.27.x line before 1.27.2 (CWE-444, parser disagreement between proxy and origin server). Exploitation requires a non-default handler pattern plus a fronting proxy, so despite the published CVSS base of 7.5 the assessed real-world priority is moderate-to-low; no public exploit code has been identified at time of analysis, EPSS is 0.18% (7th percentile), and CISA SSVC records Exploitation: none with Technical Impact: partial.
RemediationAI
Vendor-released patch: Go 1.26.9 and Go 1.27.2 (the 1.27.x fix supersedes all 1.27.0-0 through 1.27.1 releases). Rebuild and redeploy every affected Go binary with a patched toolchain, since the library fix is compiled into the binary rather than applied at runtime; track the advisory at https://pkg.go.dev/vuln/GO-2026-6613, the issue at https://go.dev/issue/81744, and the change at https://go.dev/cl/847311, with release notes at https://groups.google.com/g/golang-announce/c/U2fTuyDJznI. Until rebuilds are complete, the most effective compensating control is to remove the vulnerable handler pattern: any handler that can be reached with an HTTP/1 CONNECT should either reject the method with a non-2xx status, or, if it must tunnel, call Hijack and manage the connection itself so net/http never resumes HTTP parsing; the trade-off is that breaking the tunnel path disables legitimate CONNECT-based proxying or TLS-in-TLS use cases for those endpoints. As a secondary control, terminate or normalize CONNECT semantics at the fronting proxy (reject upstream CONNECT, rewrite or strip CONNECT before forwarding, or enforce strict request framing and reuse rules) so the parser disagreement cannot be constructed, at the cost of added proxy configuration complexity and possible incompatibility with legitimate tunneling clients. Deployments with no intermediary proxy in front of the Go server see minimal real-world exposure, but patching remains the correct fix because the underlying server behavior is the defect; note that generic input filtering does not address this class of framing disagreement.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The affected component is the Go standard library's net/http server, identified by CPE cpe:2.3:a:go_standard_library:net/http:*:*:*:*:*:*:*:*, i.e. the HTTP/1.x server implementation shipped with the Go toolchain rather than a third-party web framework. Per HTTP semantics, a 2xx response to an HTTP/1 CONNECT request converts the connection into a bidirectional tunnel for arbitrary bytes, and the handler is expected to take ownership of the socket through the Hijacker interface (Hijack). In the vulnerable behavior, a handler that writes a 2xx status to CONNECT and then returns without hijacking leaves the connection under the control of net/http's server loop, which continues to read and dispatch what it interprets as further HTTP requests. This creates the classic CWE-444 inconsistent interpretation of HTTP requests: an upstream proxy that honored the CONNECT and switched to tunnel mode treats the same bytes as opaque tunneled payload, while the Go server treats them as HTTP, so attacker-influenced bytes can be re-framed across the two parsers and smuggled into subsequent requests. The root cause is therefore a state machine/lifecycle defect (connection mode not transitioned after a 2xx CONNECT), not a memory-safety bug; the impact envelope is bounded by the requirement that an application actually answer CONNECT with 2xx and return without hijacking, and by the presence of an intermediary that interprets post-CONNECT data as tunneled. The upstream fix is captured in Go CL 847311 (issue 81744), and the affected version ranges are net/http 0 < 1.26.9 and 1.27.0-0 < 1.27.2.
Know when Net Http 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:H/I:N/A:N
Requires an atypical non-hijacking CONNECT handler plus a fronting proxy, so AC:H; parser desync across the proxy boundary is a scope change (S:C) yielding limited smuggling-based confidentiality/integrity impact.
Primary rating from Vendor (Go).
CVSS VectorVendor: Go
Lifecycle Timeline
3DescriptionCVE.org
When an HTTP server handler sends a 2xx response to an HTTP/1 CONNECT request and returns without hijacking the connection, the server improperly continues to read and serve requests from the connection. Since a 2xx response to an HTTP/1 CONNECT converts the connection into a tunnel, the server should not treat the connection as continuing to contain HTTP. The impact of this misbehavior is mostly limited to potential request smuggling, where an intermediate proxy considers the data on the connection to be tunneled and the server considers it to be HTTP.
Executive ViewAI
A request-smuggling flaw in the Go net/http standard library affects applications built with net/http versions before 1.26.9 and 1.27.x before 1.27.2, potentially allowing traffic to bypass fronting proxy controls when a specific non-default handler pattern returns a 2xx to CONNECT without hijacking the connection. Because exploitation requires both that handler pattern and a fronting proxy, and no public exploit code has been identified, the immediate organizational risk is limited but still warrants inventory and patching, especially for customer-facing services behind reverse proxies. Leadership should prioritize upgrading affected Go-based services to vendor-fixed releases to prevent proxy-origin parsing disagreements that could undermine access controls.
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.
Remote 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
Response smuggling is possible in Go's HTTP/2 implementation (net/http and golang.org/x/net/http2) when a program acts a
CPU exhaustion in the Go standard library's net/http file-serving handlers (FileServer, ServeContent, and ServeFile(FS))
Exploit-DB