CVE-2026-35469: SpdyStream: DOS on CRI

Summary: Possible DOS in SPDY streaming code, used for attach, exec and port forwarding.

Requirements To Exploit: Access to the kubelet's endpoint (granted through nodes/proxy) or access to any of portforward, exec, or attach to pods. These all can be represented by the cluster roles

pods/portforward (create)

pods/exec (create)

pods/attach (create)

nodes/proxy (get/create)

Component Affected: Kubelet, CRI-O, kube-apiserver

Version Affected: Openshift 4.21.4 and below

Patch Available: yes

Version Fixed: none yet

Cvss: (Based on [https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator]). Please note that only the Base Score Metrics are required by the incident response team.

Impact: Based on the https://access.redhat.com/security/updates/classification , what do you think would be the impact and why? This helps a lot the analyst to understand why such a report must be or not considered Moderate/Important or even Critical.

Steps To Reproduce: apply:

— apiVersion: v1 kind: ServiceAccount metadata: name: poc-sa-portforward namespace: default — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: Role metadata: name: poc-role-portforward namespace: default rules:

apiGroups: [""] resources: ["pods/portforward"] verbs: ["create"] — apiVersion: [rbac.authorization.k8s.io/v1:(http://rbac.authorization.k8s.io/v1)(http://rbac.authorization.k8s.io/v1)] kind: RoleBinding metadata: name: poc-rb-portforward namespace: default subjects:

kind: ServiceAccount name: poc-sa-portforward namespace: default roleRef: kind: Role name: poc-role-portforward apiGroup: rbac.authorization.k8s.io — apiVersion: v1 kind: Pod metadata: name: poc-target namespace: default spec: containers:

name: nginx image: nginx:alpine

set env:

export APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}' | sed 's|https://||')

export TOKEN=$(kubectl create token poc-sa-portforward)

export POD=poc-target

run attached pocportforward.py

Mitigation: disable the above cluster roles from untrusted users.

Embargo Reason: Coordination with three upstream communities: containerd, CRI-O, kubernetes

Original Report: https://github.com/moby/spdystream/security/advisories/GHSA-pc3f-x583-g7j2

— Red Hat

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. 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. Affected versions  github.com/moby/spdystream <= v0.5.0 Fix  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.

— GitHub