Affected: Alpaquita:stream: containerd

Withdrawn by the publisher.

Affected: CleanStart: argo-cd-fips

Package argo-cd-fips version 3.1.14-r0 fixes 14 vulnerabilities: ghsa-mh2q-q3fh-2475, ghsa-p77j-4mvh-x3m3, ghsa-pc3f-x583-g7j2, ghsa-78h2-9frx-2jm8, ghsa-hfvc-g4fc-pqhx...

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.

Affected: Go: github.com/moby/spdystream

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…

Affected: openEuler:20.03-LTS-SP4: kubernetes, openEuler:22.03-LTS-SP4: kubernetes, openEuler:24.03-LTS: kubernetes, openEuler:24.03-LTS-SP1: kubernetes, openEuler:24.03-LTS-SP3: kubernetes

Container cluster management. Security Fix(es):

A flaw was found in the SPDY streaming code used by Kubelet, CRI-O, and kube-apiserver. An attacker with specific cluster roles, such as those allowing access to pod port forwarding, execution, or attachment, or node proxying, could exploit this vulnerability. This could lead to a Denial of Service (DoS) by causing the affected components to become unresponsive.(CVE-2026-35469)

containerd-1.7.33-1.1 on GA media

immutable-js: Immutable.js: Arbitrary code execution via Prototype Pollution github.com/jackc/pgproto3/v2: github.com/jackc/pgproto3/v2: Denial of Service via malicious PostgreSQL server google.golang.org/grpc/grpc-go: google.golang.org/grpc/authz: gRPC-Go: Authorization bypass due to improper HTTP/2 path validation github.com/jackc/pgx/v5: github.com/jackc/pgx: Memory-safety vulnerability github.com/jackc/pgx/v5: github.com/jackc/pgx: Memory-safety vulnerability github.com/go-jose/go-jose/v3: github.com/go-jose/go-jose/v4: Go JOSE: Denial of Service via crafted JSON Web Encryption (JWE) object Kubelet: CRI-O: kube-apiserver: Kubelet, CRI-O, kube-apiserver: Denial of Service via SPDY streaming code

Security update for containerd

Affected: Ubuntu:16.04:LTS: golang-github-docker-spdystream, Ubuntu:18.04:LTS: golang-github-docker-spdystream, Ubuntu:20.04:LTS: golang-github-docker-spdystream, Ubuntu:22.04:LTS: golang-github-docker-spdystream, Ubuntu:24.04:LTS: golang-github-docker-spdystream, Ubuntu:25.10: golang-github-docker-spdystream, Ubuntu:26.04:LTS: golang-github-docker-spdystream

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.

Ein Angreifer kann mehrere Schwachstellen in IBM App Connect Enterprise Certified Container ausnutzen, um beliebigen Code auszuführen, Sicherheitsmaßnahmen zu umgehen, Cross-Site-Scripting-Angriffe durchzuführen, Daten zu manipulieren, vertrauliche Informationen offenzulegen oder einen Denial-of-Service-Zustand zu verursachen.