CVE-2026-33814

What it actually does

This is a network-reachable denial-of-service flaw in Go HTTP/2 handling. When a Go HTTP/2 transport processes a malicious SETTINGS frame where SETTINGS_MAX_FRAME_SIZE is set to 0, it can enter an infinite loop writing CONTINUATION frames. Because HTTP/2 SETTINGS frames are exchanged as part of normal connection negotiation, exploitation requires no authentication or user interaction. The impact is availability loss: affected Go clients, proxies, services, or libraries using the vulnerable HTTP/2 transport may consume CPU, memory, network bandwidth, goroutines, or file descriptors until the process becomes degraded or unavailable.

Why it matters to the business

An attacker that can make an affected Go-based component establish or process HTTP/2 connections with attacker-controlled peers may be able to crash, hang, or severely degrade that component. This can interrupt APIs, service-to-service calls, outbound integrations, reverse proxies, gateways, or backend workers that rely on Go HTTP/2. The CVSS score is high for availability impact, but EPSS is currently low and no known exploited-in-the-wild status is reported, so remediation should be prioritized for internet-facing, high-throughput, or mission-critical Go services first.

How an attack unfolds

An attacker positions a malicious HTTP/2 peer, commonly by operating a server that an affected Go client, proxy, crawler, webhook processor, integration service, or backend component connects to. During HTTP/2 negotiation, the malicious peer sends a SETTINGS frame containing SETTINGS_MAX_FRAME_SIZE with an invalid value of 0. Instead of rejecting the setting cleanly, the vulnerable Go HTTP/2 transport can enter an infinite loop writing CONTINUATION frames. The resulting loop can drive sustained CPU usage, excessive outbound traffic, goroutine buildup, memory pressure, and connection exhaustion. Repeating the interaction across many connections can make the affected process unresponsive or unavailable.

How to fix it

Upgrade Go and any vendored golang.org/x/net/http2 dependency to a vendor-fixed release when available. Because no exact fixed versions were provided in the input, track the official Go security advisory and distribution/package manager advisories for the patched Go toolchain and x/net/http2 module versions. Rebuild and redeploy all statically linked Go binaries after upgrading, because Go applications typically embed library code at build time. If immediate patching is not possible, reduce exposure by disabling HTTP/2 where operationally feasible, preventing untrusted destinations from being contacted over HTTP/2, enforcing egress allow-lists for components that initiate outbound HTTP/2 connections, applying connection and request timeouts, limiting concurrent connections, and using reverse proxies or gateways that validate and reject invalid HTTP/2 SETTINGS frames before vulnerable Go components process them.

How to confirm the fix worked

Confirm remediation by inventorying Go runtimes, Go module dependencies, and statically compiled binaries that use net/http or golang.org/x/net/http2. Verify builds use a patched Go toolchain and patched http2 module once vendor-fixed versions are available. Use `go version -m <binary>` where applicable to inspect embedded Go version and module metadata. Review `go.mod` and `go.sum` for golang.org/x/net versions and rebuild binaries after dependency updates. In test environments, validate that an HTTP/2 peer sending SETTINGS_MAX_FRAME_SIZE=0 is rejected or the connection is closed without sustained CONTINUATION-frame emission, CPU spikes, goroutine growth, or process instability. Also confirm compensating controls such as HTTP/2 disablement, egress allow-listing, and connection limits are active where patches cannot yet be deployed.

Typical attack path

1. Identify an affected Go-based application, proxy, service, or library path that uses HTTP/2 transport.
2. Gain the ability to act as, or redirect traffic to, an attacker-controlled HTTP/2 peer.
3. Complete enough of the HTTP/2 connection setup for SETTINGS processing to occur.
4. Send an HTTP/2 SETTINGS frame with SETTINGS_MAX_FRAME_SIZE set to 0.
5. Trigger the vulnerable transport into repeatedly writing CONTINUATION frames.
6. Maintain or repeat connections until the target process experiences resource exhaustion or availability failure.

How to detect it

To determine whether exploitation already occurred, review network telemetry, HTTP/2-aware proxy logs, packet captures, load balancer logs, egress gateway logs, and host runtime metrics for evidence of invalid HTTP/2 SETTINGS frames where SETTINGS_MAX_FRAME_SIZE equals 0 followed by excessive CONTINUATION frames from the affected Go process. On hosts and containers, look for sudden sustained CPU usage, goroutine count growth, memory pressure, file descriptor exhaustion, high outbound traffic, repeated connection resets, or health-check failures correlated with HTTP/2 sessions to a small set of remote peers. Application logs may not record the malformed frame, so prioritize packet capture/Zeek/Suricata/Envoy/nghttp2 debug logs where available. For Go services, examine runtime profiles, pprof data, container restart events, OOM events, and orchestration logs around incidents of degraded availability. No named threat actors or known exploited-in-the-wild campaigns are reported in the provided data, so detection should focus on protocol anomalies and resource-exhaustion behavior rather than actor-specific infrastructure.

• SETTINGS_MAX_FRAME_SIZE=0
• SETTINGS_MAX_FRAME_SIZE: 0
• setting=SETTINGS_MAX_FRAME_SIZE value=0
• HTTP/2 SETTINGS frame with SETTINGS_MAX_FRAME_SIZE 0
• HTTP2 SETTINGS_MAX_FRAME_SIZE 0
• http2.settings.max_frame_size == 0
• http2.settings.max_frame_size: 0
• HTTP/2 setting identifier 0x5 value 0x00000000
• SETTINGS frame identifier=0x5 value=0
• frame_type=CONTINUATION
• HTTP/2 CONTINUATION frame flood
• excessive CONTINUATION frames
• CONTINUATION frames sent in a loop

What your security team should do

• Prioritize patching or mitigation for internet-facing Go services, proxies, gateways, crawlers, webhook processors, and any Go components that connect to untrusted HTTP/2 peers.
• Create an inventory of Go binaries and services using net/http HTTP/2 or golang.org/x/net/http2, including statically linked applications that will require rebuilds.
• Monitor Go security advisories and package distribution advisories for the exact fixed versions, then rebuild and redeploy affected binaries promptly.
• Temporarily disable HTTP/2 or restrict outbound HTTP/2 connections to trusted destinations where patching is delayed.
• Add detection for invalid HTTP/2 SETTINGS frames with SETTINGS_MAX_FRAME_SIZE set to 0 and abnormal bursts of outbound CONTINUATION frames.
• Tune runtime and infrastructure safeguards: connection timeouts, max concurrent streams/connections, process resource limits, autoscaling alerts, and health checks for rapid recovery.
• Investigate recent unexplained CPU spikes, goroutine growth, connection churn, or outbound HTTP/2 frame floods from Go services since publication.