CVE-2026-35469

CVE-2026-35469 is a high-severity allocation of resources without limits or throttling vulnerability in github.com/moby/spdystream (go), affecting versions <= 0.5.0. It is fixed in 0.5.1.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

SpdyStream: DOS on CRI

The SPDY/3 frame parser in spdystream does not validate
attacker-controlled counts and lengths before allocating memory. A
remote peer that can send SPDY frames to a service using spdystream can
cause the process to allocate gigabytes of memory with a small number of
malformed control frames, leading to an out-of-memory crash.
 
Three allocation paths in the receive side are affected:

  1. SETTINGS entry count -- The SETTINGS frame reader reads a 32-bit
    numSettings from the payload and allocates a slice of that size
    without checking it against the declared frame length. An attacker
    can set numSettings to a value far exceeding the actual payload,
    triggering a large allocation before any setting data is read.
  2. Header count -- parseHeaderValueBlock reads a 32-bit
    numHeaders from the decompressed header block and allocates an
    http.Header map of that size with no upper bound.
  3. Header field size -- Individual header name and value lengths are
    read as 32-bit integers and used directly as allocation sizes with
    no validation.

 
Because SPDY header blocks are zlib-compressed, a small on-the-wire
payload can decompress into attacker-controlled bytes that the parser
interprets as 32-bit counts and lengths. A single crafted frame is
enough to exhaust process memory.

Affected versions

github.com/moby/spdystream <= v0.5.0

Impact

Any program that accepts SPDY connections using spdystream -- directly
or through a dependent library -- is affected. A remote peer that can
send SPDY frames to the service can crash the process with a single
crafted SPDY control frame, causing denial of service.

The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap. Typical impact: resource exhaustion leading to denial of service.

Affected versions

github.com/moby/spdystream (<= 0.5.0)

Security releases

github.com/moby/spdystream → 0.5.1 (go)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

v0.5.1 addresses the receive-side allocation bugs and adds related
hardening:
 
Core fixes:  

  • SETTINGS entry-count validation -- The SETTINGS frame reader now
    checks that numSettings is consistent with the declared frame
    length (numSettings <= (length-4)/8) before allocating.
  • Header count limit -- parseHeaderValueBlock enforces a maximum
    number of headers per frame (default: 1000).
  • Header field size limit -- Individual header name and value
    lengths are checked against a per-field size limit (default: 1 MiB)
    before allocation.
  • Connection closure on protocol error -- The connection read loop
    now closes the underlying net.Conn when it encounters an
    InvalidControlFrame error, preventing further exploitation on the
    same connection.

 
Additional hardening:  

  • Write-side bounds checks -- All frame write methods now verify
    that payloads fit within the 24-bit length field, preventing the
    library from producing invalid frames.

 
Configurable limits:  

  • Callers can adjust the defaults using NewConnectionWithOptions or
    the lower-level spdy.NewFramerWithOptions with functional options:
    WithMaxControlFramePayloadSize, WithMaxHeaderFieldSize, and
    WithMaxHeaderCount.

Frequently Asked Questions

  1. What is CVE-2026-35469? CVE-2026-35469 is a high-severity allocation of resources without limits or throttling vulnerability in github.com/moby/spdystream (go), affecting versions <= 0.5.0. It is fixed in 0.5.1. The application allocates resources such as memory, threads, or file descriptors based on untrusted input without enforcing a cap.
  2. Which versions of github.com/moby/spdystream are affected by CVE-2026-35469? github.com/moby/spdystream (go) versions <= 0.5.0 is affected.
  3. Is there a fix for CVE-2026-35469? Yes. CVE-2026-35469 is fixed in 0.5.1. Upgrade to this version or later.
  4. Is CVE-2026-35469 exploitable, and should I be worried? Whether CVE-2026-35469 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-35469 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-35469? Upgrade github.com/moby/spdystream to 0.5.1 or later.

Stop the waste.
Protect your environment with Kodem.