CVE-2026-35469

What it actually does

CVE-2026-35469 is a remotely triggerable denial-of-service flaw in the Go spdystream library. In versions 0.5.0 and earlier, the SPDY/3 frame parser trusts attacker-controlled 32-bit count and length fields before allocating memory. The vulnerable allocation paths include SETTINGS frame entry counts, header counts in header value block parsing, and individual header field lengths. Because SPDY header blocks are zlib-compressed, an attacker can send a relatively small network payload that decompresses into very large allocation requests. A remote peer able to send SPDY frames to an affected service can force excessive memory allocation and crash the process through an out-of-memory condition. The impact is availability-only; the flaw does not directly provide code execution, data theft, or privilege escalation.

Why it matters to the business

Successful exploitation can make affected services unavailable by crashing processes that use vulnerable spdystream parsing. This can interrupt APIs, control-plane communication, tunneling, streaming, proxying, or other components that rely on SPDY multiplexing. The CVSS availability impact is high, exploitation requires network access and no authentication, but current public exploitation signals are low: EPSS is 0.00656, the 30-day trend is flat, the issue is not in CISA KEV, is not known to be used in ransomware campaigns, and exploit maturity is currently listed as none. Organizations should still remediate because a single crafted frame can be sufficient to trigger a crash where the vulnerable parser is reachable.

How an attack unfolds

An attacker first identifies a network-exposed service or peer-to-peer endpoint that accepts SPDY traffic handled by vulnerable spdystream versions 0.5.0 or earlier. The attacker establishes or reaches a SPDY connection and sends a crafted control frame, such as a SETTINGS frame or compressed header block, containing inflated 32-bit count or length values. The vulnerable parser decompresses and processes the frame without validating those values against safe limits. It then attempts to allocate memory based directly on attacker-supplied counts or field sizes. The allocation pressure rapidly exhausts process memory, causing the Go runtime or operating system to terminate the process, which results in a denial of service until the service is restarted and the traffic path is protected or patched.

How to fix it

Upgrade spdystream to version 0.5.1 or later wherever it is used. Because this is a library vulnerability, review both direct and transitive Go module dependencies and rebuild/redeploy affected binaries after updating go.mod/go.sum. If immediate upgrade is not possible, reduce exposure by restricting network access to SPDY-speaking endpoints, allowing only trusted peers, enforcing connection-level authentication before frame parsing where feasible, applying request/body/frame size limits at surrounding proxies, rate-limiting new connections, and using process supervision with memory limits and automatic restart to reduce outage duration. These mitigations reduce risk but do not replace upgrading to a fixed version, because the vulnerable parser still trusts attacker-controlled allocation sizes.

How to confirm the fix worked

Confirm that no deployed build includes spdystream version 0.5.0 or earlier. For Go projects, inspect go.mod and go.sum for github.com/moby/spdystream or equivalent module references and verify the resolved version is 0.5.1 or later. Generate an SBOM or run Go dependency scanning against built artifacts to catch statically compiled binaries and transitive dependencies. After patching, redeploy all affected services and verify runtime versions by checking build metadata, container image SBOMs, or binary provenance. Exposure can be validated by identifying services that accept SPDY traffic and confirming they are either patched, not externally reachable, or protected by strict peer allowlisting and resource controls. Functional validation should include negative testing with oversized or malformed SPDY frames in a controlled environment to confirm the process rejects the frame without abnormal memory growth or crash.

Typical attack path

1. Identify a service, component, proxy, tunnel, or API endpoint that accepts SPDY frames through the Go spdystream library.
2. Confirm the endpoint will process unauthenticated or attacker-reachable SPDY/3 control frames.
3. Create a malformed SPDY control frame with oversized SETTINGS counts, header counts, or header field lengths.
4. Optionally compress the malicious header block so the network payload remains small while decompression yields large attacker-controlled values.
5. Send the crafted frame to the vulnerable service.
6. Trigger unbounded memory allocation during frame parsing.
7. Cause the affected process to crash from memory exhaustion, interrupting service availability.

How to detect it

Look for evidence of process memory exhaustion or abrupt restarts on services that use SPDY or spdystream. Relevant sources include application logs, Go runtime stderr/stdout, container runtime events, Kubernetes events, systemd journals, kernel logs, process supervisor logs, reverse proxy or load balancer connection logs, and network telemetry for SPDY traffic. Indicators include Go runtime out-of-memory messages, Linux OOM killer entries, container OOMKilled events, abnormal memory spikes immediately before crashes, short-lived connections followed by process termination, repeated restarts of the same service, and malformed or unusually large compressed SPDY control/header frames. Because this vulnerability primarily causes denial of service rather than persistent compromise, durable host artifacts may be limited to crash logs, core dumps, restart events, and network captures. If threat hunting is possible, correlate service crashes with inbound SPDY sessions from the same remote address, especially where the connection sends a small payload shortly before a large memory allocation event. No named threat actors or active exploitation campaigns are currently reported for this CVE.

• github.com/moby/spdystream v0.5.0
• github.com/moby/spdystream v0.4
• spdystream
• SPDY/3
• SETTINGS
• parseHeaderValueBlock
• fatal error: runtime: out of memory
• runtime: out of memory
• out of memory
• cannot allocate memory
• OOMKilled
• Killed process
• invoked oom-killer
• Memory cgroup out of memory
• signal: killed

What your security team should do

• Inventory all Go applications and container images that include spdystream, including transitive dependencies and statically compiled binaries.
• Prioritize upgrade to spdystream 0.5.1 or later for any internet-facing, cross-tenant, or untrusted-peer SPDY endpoints.
• Rebuild and redeploy affected binaries after dependency updates; updating source manifests alone is not sufficient for compiled Go services.
• Restrict access to SPDY-speaking services to trusted networks and peers until all affected components are patched.
• Add monitoring for sudden memory growth, Go runtime out-of-memory crashes, container OOM kills, and repeated service restarts on components that process SPDY traffic.
• Review recent crash and availability incidents since publication on 2026-04-16 for symptoms consistent with malformed SPDY frame handling.
• Because EPSS is low and there is no KEV or ransomware linkage, schedule remediation according to normal high-availability service risk, but accelerate for exposed critical services where a single unauthenticated packet path can crash the process.