spdystream is a Go library for multiplexing streams over SPDY connections. In versions 0.5.0 and below, the SPDY/3 frame parser does not validate attacker-controlled counts and lengths before allocating memory. Three allocation paths are affected: the SETTINGS frame entry count, the header count in parseHeaderValueBlock, and individual header field sizes — all read as 32-bit integers and used directly as allocation sizes with no bounds checking. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into large attacker-controlled values. A remote peer that can send SPDY frames to a service using spdystream can exhaust process memory and cause an out-of-memory crash with a single crafted control frame. This issue has been fixed in version 0.5.1.
Security readout for executives and security teams
Plain-English summary
CVE-2026-35469 is a denial-of-service flaw in moby spdystream before 0.5.1. A remote peer able to send SPDY frames to an affected service may crash the process by forcing excessive memory allocation. The issue affects availability, not confidentiality or integrity, based on the supplied record.
Executive priority
Treat as high priority for systems exposing affected SPDY-based control paths. The business risk is service outage from remote memory exhaustion, especially in infrastructure components where process crashes can disrupt container or platform operations.
Technical view
The SPDY/3 frame parser fails to bound attacker-controlled 32-bit counts and lengths before allocation. Affected paths include SETTINGS entry count, header count, and individual header field sizes. Compressed header blocks can carry small wire data that expands into large allocation requests, causing out-of-memory termination. Version 0.5.1 fixes this.
Likely exposure
Exposure is limited to services or downstream products using moby/spdystream below 0.5.1 where an untrusted remote peer can send SPDY frames. The bundle lists Red Hat advisories, so downstream package status should be verified through vendor guidance.
Exploitation context
The source bundle does not show CISA KEV listing or confirmed active exploitation. It does state network, low-complexity, unauthenticated availability impact, with a single crafted control frame potentially causing process memory exhaustion.
Researcher notes
Focus review on reachability of spdystream frame parsing from untrusted peers and dependency lineage. The advisory identifies three unbounded allocation paths and a fixed release, but the bundle does not provide detailed downstream affected-product mapping beyond listed vendor references.
Mitigation direction
Upgrade moby/spdystream to 0.5.1 or later where directly vendored.
Check downstream vendor advisories, including listed Red Hat errata, before assuming fixed status.
Restrict untrusted peers from reaching SPDY endpoints using vulnerable spdystream versions.
Monitor process memory and crash loops until affected components are upgraded.
Validation and detection
Inventory Go modules and vendor trees for moby/spdystream versions below 0.5.1.
Review SBOMs and container images for transitive inclusion of vulnerable spdystream.
Confirm deployed downstream packages map to fixed vendor errata.
Validate service availability controls without reproducing weaponized crash payloads.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-770: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.