Live › vulnerability › CVE-2026-78660
Go to dashboardGo's net/http HTTP/2 implementation accepts malformed framing-related headers and can forward them to HTTP/1 clients when acting as a reverse proxy. A downstream HTTP/1 client that parses them loosely can be tricked into response smuggling, letting an attacker desync responses.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 19:13 UTC, 0h before NVD. All times on this page are UTC.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| stdlib | go | < 1.26.9 | 1.26.9 |
| stdlib | go | >= 1.27.0-0, < 1.27.2 | 1.27.2 |
| golang.org/x/net | go | < 0.60.0 | 0.60.0 |
Check whether the Go binary's stdlib is below 1.26.9 or in 1.27.0-0 to 1.27.1 (go version -m <binary>), and whether golang.org/x/net is below 0.60.0 in go.mod or go.sum.
Upgrade the Go toolchain to 1.26.9 or 1.27.2, and golang.org/x/net to 0.60.0, then rebuild.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-78660")
Go Vulnerability Database, CC-BY 4.0 · EPSS scores by FIRST, used with attribution · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.