Go net/http CVE-2026-78669

The victim must be running a Go net/http or golang.org/x/net HTTP/2 endpoint (server with HTTP/2 enabled - the default for Go servers over TLS - or a Go HTTP/2 client connecting to an attacker-controlled server), in a version predating the O(1) initial-window-size fix tracked in Go issue 81742. No authentication, no user interaction, and no non-default configuration are required beyond HTTP/2 being active. Exploitation is explicitly tied to HTTP/2's stream multiplexing: an attacker needs the ability to open many streams on one connection and send repeated SETTINGS_INITIAL_WINDOW_SIZE updates. Limiting factors: HTTP/1-only deployments are not affected, the impact is confined to CPU/availability (no data compromise), and patched x/net/Go versions neutralize the issue.

CVE-2026-78669 is an algorithmic-complexity denial-of-service in Go's HTTP/2 implementation (golang.org/x/net and net/http): a malicious HTTP/2 peer opens many streams, then sends repeated small SETTINGS frames carrying SETTINGS_INITIAL_WINDOW_SIZE, forcing the victim to recompute per-stream window state in O(number of streams) each time, which burns CPU. No CVSS vector, EPSS score, KEV entry, or POC was supplied in the input, so quantitative exploitation signals are absent and cannot be compared. On the metrics that ARE derivable from the description, this is a classic unauthenticated, network-reachable, low-complexity availability bug (no confidentiality or integrity impact), which my independent assessment scores as High (7.5). The real-world priority is moderate-to-high for exposed Go HTTP/2 services because the trigger is cheap and needs no credentials, but it is a resource-exhaustion issue only - not RCE or data exposure - so it should be patched promptly on internet-facing services yet does not carry the same urgency as a code-execution flaw. IMPORTANT DATA CAVEAT: the two linked articles (the GitHub Go issue #81857 and RyotaK's site) describe CVE-2026-78659 (the Trailer-header memory-exhaustion bug), NOT CVE-2026-78669; the only directly on-point source for 78669 is the oss-security advisory text and Go issue 81742 (reported by Jakub Ciolek). Treat the linked articles as context for a sibling CVE, not as corroboration of this one.

An attacker establishes an HTTP/2 connection to a vulnerable Go server (or lures a vulnerable Go HTTP/2 client to connect to an attacker-controlled server), opens a large number of concurrent streams, and then floods many small SETTINGS frames that change SETTINGS_INITIAL_WINDOW_SIZE. Each change forces the peer to walk every open stream to adjust flow-control windows, driving CPU toward saturation and degrading or denying service. No public exploit code is identified at time of analysis, though the technique is simple and well-described in the advisory.