CVE-2026-35469: 
Docker Compose vulnerability analysis and mitigation

CVE-2026-35469 is a memory amplification vulnerability in the github.com/moby/spdystream Go library (SPDY/3 frame parser) that allows a remote, unauthenticated attacker to cause a denial-of-service via out-of-memory crash. All versions up to and including v0.5.0 are affected; the issue was patched in v0.5.1. The advisory was published on April 16, 2026, with a CVSS v4 base score of 8.7 (High) (Github Advisory, GHSA Advisory). Downstream products confirmed affected include Microsoft Azure Linux containerd, IBM App Connect Enterprise, IBM Instana Observability, Splunk AppDynamics Cluster Agent, and Red Hat OpenShift Container Platform (Github Advisory, IBM Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the SPDY/3 frame parser trusts attacker-supplied 32-bit integer fields as allocation sizes without validating them against actual frame lengths. Three distinct allocation paths are vulnerable: (1) the SETTINGS frame reader allocates a slice of size numSettings without checking it against the declared frame length; (2) parseHeaderValueBlock allocates an http.Header map of size numHeaders with no upper bound; and (3) individual header name and value lengths are read as 32-bit integers and used directly as allocation sizes. Because SPDY header blocks are zlib-compressed, a small on-the-wire payload can decompress into attacker-controlled bytes, meaning a single crafted control frame is sufficient to trigger gigabyte-scale allocations and crash the process (GHSA Advisory, Github Advisory).

Successful exploitation results in a complete denial-of-service: the target process exhausts available memory and crashes with an out-of-memory error. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. Any program that accepts SPDY connections using spdystream (directly or via a dependent library such as containerd, Kubernetes CRI components, or Portainer) is at risk, meaning container orchestration infrastructure could be disrupted by a single malformed frame from a remote peer (GHSA Advisory, Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.014–0.029%, placing it in a low percentile for near-term exploitation probability. However, the attack requires no authentication, no user interaction, and low complexity — a single crafted SPDY frame sent over the network is sufficient — making it trivially weaponizable if an attacker has network access to a vulnerable service (GHSA Advisory).

1. Reconnaissance: Identify services that accept SPDY connections and use github.com/moby/spdystream v0.5.0 or earlier — common targets include containerd, Kubernetes API server components, or CRI-O endpoints. Use network scanning tools (e.g., nmap, Shodan) to locate exposed SPDY endpoints.
2. Craft a malicious SETTINGS frame: Construct a SPDY/3 SETTINGS control frame where the numSettings field is set to a very large 32-bit integer (e.g., 0x7FFFFFFF) that far exceeds the actual payload length. This causes the parser to attempt allocating a slice of that size before reading any data.
3. Alternatively, craft a malicious HEADERS frame: Build a zlib-compressed SPDY header block where the decompressed bytes encode a large numHeaders value or individual header name/value lengths as large 32-bit integers. The compression ratio allows a small on-the-wire payload to expand into attacker-controlled bytes.
4. Send the frame: Transmit the crafted SPDY control frame to the target service over a network connection. No authentication is required.
5. Achieve denial of service: The vulnerable parser allocates gigabytes of memory based on the attacker-supplied counts/lengths, exhausting process memory and triggering an out-of-memory crash, taking down the service (GHSA Advisory).

• Logs: Sudden out-of-memory (OOM) kill events in system logs (e.g., kernel: Out of memory: Kill process or OOMKilled in Kubernetes pod events) affecting containerd, CRI-O, or other spdystream-dependent services.
• Process Behavior: Rapid, sustained growth in memory consumption by the affected Go process (containerd, kube-apiserver, etc.) immediately following receipt of a SPDY connection, without a corresponding increase in legitimate workload.
• Network: Unexpected or anomalous SPDY control frame traffic (particularly SETTINGS or HEADERS frames) from unknown or untrusted remote peers to SPDY-enabled service ports; connections that terminate abruptly after sending a single frame.
• System: Repeated service restarts or crash loops of containerd, CRI-O, or Kubernetes components coinciding with inbound SPDY connections from a specific source IP.

The primary remediation is to upgrade github.com/moby/spdystream to v0.5.1 or later, which adds validation of numSettings against frame length, enforces a maximum header count of 1,000 per frame, limits individual header field sizes to 1 MiB, and closes the connection on protocol errors (GHSA Advisory, spdystream v0.5.1). Downstream consumers should update to patched releases: containerd v2.0.8, v2.1.7, or v2.2.3; CRI-O v1.33.12; and apply vendor-specific patches from Microsoft (Azure Linux), IBM (App Connect Enterprise, Instana), Splunk (AppDynamics), and Red Hat (OpenShift) (IBM Advisory, Splunk Advisory). As a workaround where patching is not immediately possible, implement network segmentation to restrict SPDY frame transmission to trusted peers only and monitor for anomalous memory consumption.

The vulnerability was disclosed via GitHub Security Advisory (GHSA-pc3f-x583-g7j2) by maintainer thaJeztah on April 15–16, 2026, and quickly picked up by multiple downstream vendors including Microsoft, IBM, Red Hat, Splunk, and SUSE, all of whom issued their own advisories and patches within weeks (Github Advisory, IBM Advisory). The Kubernetes community newsletter (Last Week in Kubernetes Development) noted the issue in its April 2026 edition. SUSE issued multiple security updates for various Kubernetes versions (1.23, 1.24, 1.26) in response. Coverage was also noted in German Linux security outlets (pro-linux.de) covering the containerd and CRI-O fixes.