CVE-2026-35469

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.

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.

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.  

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 is an industry-standard container runtime with an emphasis on simplicity, robustness and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

Security Fix(es):

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.(CVE-2026-35469)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
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.

These are all security issues fixed in the containerd-1.7.33-1.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the containerized-data-importer1.65-api-1.65.0-2.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the kubevirt1.8-container-disk-1.8.4-1.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the containerized-data-importer1.66-api-1.66.0-1.1 package on the GA media of openSUSE Tumbleweed.

This update for containerd fixes the following issues

Update to 1.7.33:

• CVE-2024-25621: overly broad default permission vulnerability (bsc#1253126).
• CVE-2025-64329: goroutine leaks can lead to memory exhaustion on the host (bsc#1253132).
• CVE-2026-33186: google.golang.org/grpc: authorization bypass due to improper validation of the HTTP/2 :path pseudo- header (bsc#1260296).
• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265794).
• CVE-2026-34986: github.com/go-jose/go-jose/v4,github.com/go-jose/go-jose/v3: crafted JWE input with a missing encrypted key can lead to a denial of service (bsc#1262948).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262266).
• CVE-2026-39821: golang.org/x/net/idna: failure to reject ASCII-only Punycode-encoded labels allows for validation bypass and privilege escalation (bsc#1266640).
• CVE-2026-46680: containerd user ID handling bypass allows runAsNonRoot evasion (bsc#1268355).
• CVE-2026-47262: Denial of Service (DoS) condition via a maliciously crafted image (bsc#1268441).
• CVE-2026-53488: CRI plugin propagates labels from an image config to a container without validation (bsc#1268430).

Changes for containerd:

• https://github.com/containerd/containerd/releases/tag/v1.7.33
• https://github.com/containerd/containerd/releases/tag/v1.7.32
• https://github.com/containerd/containerd/releases/tag/v1.7.31
• https://github.com/containerd/containerd/releases/tag/v1.7.30
• https://github.com/containerd/containerd/releases/tag/v1.7.29
• https://github.com/containerd/containerd/releases/tag/v1.7.28

This update for govulncheck-vulndb fixes the following issues:

• Update to version 0.0.20260723T184607 2026-07-23T18:46:07Z (jsc#PED-11136).

Go CVE Numbering Authority IDs added or updated with aliases:

• GO-2026-4730 CVE-2026-33022 GHSA-cv4x-93xx-wgfj
• GO-2026-4761 CVE-2026-33211 GHSA-j5q5-j9gm-2w5c
• GO-2026-5102 CVE-2026-45021 GHSA-3vcp-chfh-f6r2
• GO-2026-5272 CVE-2026-40938 GHSA-94jr-7pqp-xhcq
• GO-2026-5486 CVE-2026-40924 GHSA-m2cx-gpqf-qf74
• GO-2026-5542 CVE-2026-40090 GHSA-pj97-4p9w-gx3q
• GO-2026-5630 CVE-2026-25542 GHSA-rmx9-2pp3-xhcr
• GO-2026-5643 CVE-2026-40923 GHSA-rx35-6rhx-7858
• GO-2026-5675 CVE-2026-41492 GHSA-vvf7-6rmr-m29q
• GO-2026-5711 CVE-2026-40161 GHSA-wjxp-xrpv-xpff
• GO-2026-5746 CVE-2026-41567 GHSA-x86f-5xw2-fm2r
• GO-2026-5749 CVE-2026-41328 GHSA-x92x-px7w-4gx4
• GO-2026-5837 CVE-2026-44840 GHSA-q2m9-6jp9-c6mc
• GO-2026-5929 CVE-2026-44342 GHSA-26v7-h57m-gh9m
• GO-2026-5930 CVE-2026-33655 GHSA-6qcr-qxgr-m7fv
• GO-2026-5933 GHSA-3g4q-2f67-2gvh
• GO-2026-5934 GHSA-59qp-cfj3-rp64
• GO-2026-5935 GHSA-7856-g3gv-9wq8
• GO-2026-5936 CVE-2026-53552 GHSA-26rh-24rg-j3vv
• GO-2026-5937 CVE-2026-53508 GHSA-2jcc-mxv7-p3f9
• GO-2026-5938 CVE-2026-53553 GHSA-4g5x-hcwm-82jw
• GO-2026-5939 CVE-2026-10517 GHSA-698x-9w2p-7vvp
• GO-2026-5940 CVE-2026-53572 GHSA-6w3m-4hhp-775q
• GO-2026-5941 CVE-2026-53487 GHSA-gvhc-wv3v-7pf8
• GO-2026-5942 CVE-2026-46600
• GO-2026-5944 CVE-2026-50197 GHSA-659f-rgp5-w4wf
• GO-2026-5945 CVE-2026-6815 GHSA-rmxx-v9rj-vpvg
• GO-2026-5946 CVE-2026-52831 GHSA-v5px-423j-pf7p
• GO-2026-5947 CVE-2026-53649 GHSA-xqhv-chqm-fhcc
• GO-2026-5948 CVE-2026-50554 GHSA-588f-fvcv-xhvf
• GO-2026-5949 CVE-2026-50553 GHSA-rqrh-8wpv-x7hh
• GO-2026-5950 CVE-2026-53602 GHSA-339v-266x-79xr
• GO-2026-5951 CVE-2026-10219 GHSA-6jm8-4fhr-5w64
• GO-2026-5952 CVE-2026-49834 GHSA-9vcr-p3rj-q5q6
• GO-2026-5953 CVE-2026-9094 GHSA-c9w5-qp6m-m395
• GO-2026-5956 CVE-2026-55252 GHSA-h5g6-xmh4-hc37
• GO-2026-5957 CVE-2026-54158 GHSA-5xfx-xj4h-5p7r
• GO-2026-5958 CVE-2026-54068 GHSA-gcm7-57gf-953c
• GO-2026-5959 CVE-2026-54072 GHSA-h29v-hj44-q8cv
• GO-2026-5961 CVE-2026-54069 GHSA-hvr9-72v2-fff3
• GO-2026-5962 CVE-2026-54088 GHSA-m93h-4hw7-5qcm
• GO-2026-5963 CVE-2026-54067 GHSA-mvjr-vv3c-w4qv
• GO-2026-5964 CVE-2026-54066 GHSA-p4m3-mgmm-c664
• GO-2026-5965 CVE-2026-54070 GHSA-w7cg-whh7-xp28
• GO-2026-5966 CVE-2026-54089 GHSA-xqp3-jq6g-x3qm
• GO-2026-5967 CVE-2026-50551 GHSA-56mp-4f3v-fgj2
• GO-2026-5968 CVE-2026-54174 GHSA-fpg8-7664-jc5q
• GO-2026-5969 GHSA-g936-7jqj-mwv8
• GO-2026-5970 CVE-2026-56852
• GO-2026-5973 CVE-2026-54250 GHSA-jxr7-mqhw-9p98
• GO-2026-5974 CVE-2026-44300 GHSA-wmj8-9953-vff5
• GO-2026-5975 CVE-2026-50018 GHSA-42j2-w334-qxw7
• GO-2026-5976 CVE-2026-50141 GHSA-g7mm-9vx7-jm7h
• GO-2026-5977 CVE-2026-50013 GHSA-qrh4-p6v4-mrfg
• GO-2026-5978 CVE-2026-50125 GHSA-qw5r-ppcg-f8rj
• GO-2026-5979 CVE-2026-50006 GHSA-xrcf-6jh3-ggvx
• GO-2026-5980 CVE-2026-50158 GHSA-2c7f-fxww-6w6c
• GO-2026-5981 GHSA-mqxv-9rm6-w8qc
• GO-2026-5982 GHSA-pqg7-v6wh-3pfp
• GO-2026-5984 CVE-2026-53604 GHSA-2p2f-px33-4vv5
• GO-2026-5985 GHSA-7rx3-5wx3-5v76
• GO-2026-5986 CVE-2026-61699 GHSA-cm26-5974-52h8
• GO-2026-5987 CVE-2026-55513 GHSA-g4x6-jcvr-9m3g
• GO-2026-5988 CVE-2026-54628 GHSA-hwrq-8wxh-q4xv
• GO-2026-5989 CVE-2026-55512 GHSA-m3cx-mwpg-32jg
• GO-2026-5990 CVE-2026-54629 GHSA-mf78-3rpf-r784
• GO-2026-5991 CVE-2026-53603 GHSA-q4vm-pq3q-8wgq
• GO-2026-5992 CVE-2026-61549 GHSA-qf34-295c-26v8
• GO-2026-5996 CVE-2026-54450 GHSA-pph6-vfjv-vpjw
• GO-2026-5997 CVE-2026-54452 GHSA-xgch-x3mx-cm3c
• GO-2026-5998 CVE-2026-54495 GHSA-398h-7f66-3h4p
• GO-2026-5999 CVE-2026-10814 GHSA-jh6h-v6mp-h22v
• GO-2026-6002 CVE-2026-58196 GHSA-pr64-jmmf-jp54
• GO-2026-6003 CVE-2026-53714 GHSA-22xc-xg2r-9j7v
• GO-2026-6004 CVE-2026-52833 GHSA-3v79-m2cg-89ww
• GO-2026-6005 CVE-2026-53715 GHSA-8fv2-88gg-hm7q
• GO-2026-6006 CVE-2026-53716 GHSA-cxpq-8v7q-cg56 *…

This update for kubevirt1.8 fixes the following issues:

Update to version 1.8.4.

Security issues fixed:

• CVE-2026-13201: virt-handler-rhel9: kubevirt: safepath OpenAtNoFollow symlink following via /proc/self/fd allows host file metadata modification (bsc#1269093).
• CVE-2026-13622: virt-handler migration proxy follows symlinks and allows container escape to host (bsc#1272840).
• CVE-2026-25680, CVE-2026-25681, CVE-2026-27136, CVE-2026-42502, CVE-2026-42506: golang.org/x/net/html: multiple issues when parsing HTML files (bsc#1267120).
• CVE-2026-33814: golang.org/x/net/http2: processing of HTTP/2 SETTINGS frames with a crafted SETTINGS_MAX_FRAME_SIZE can lead to an infinite loop and a denial of service (bsc#1265736).
• CVE-2026-35469: github.com/moby/spdystream: improper validation of attacker-controlled input in the SPDY/3 frame parser allows for a denial of service via crafted SPDY frames (bsc#1262265).
• CVE-2026-39821: golang.org/x/net/idna: failure to reject ASCII-only Punycode-encoded labels allows for validation bypass and privilege escalation (bsc#1266575).
• CVE-2026-39827, CVE-2026-39828, CVE-2026-39829, CVE-2026-39830, CVE-2026-39831, CVE-2026-39832, CVE-2026-39833, CVE-2026-39834, CVE-2026-39835, CVE-2026-42508, CVE-2026-46595, CVE-2026-46597, CVE-2026-46598: golang.org/x/crypto/ssh: multiple issues in x/crypto/ssh (bsc#1266151).
• CVE-2026-46600: parsing of invalid SVCB or HTTPS RR when the size of a parameter value overflows the message buffer can lead to panic (bsc#1273606).
• CVE-2026-56852: improper handling of truncated/invalid UTF-8 input can lead to an infinite loop (bsc#1272011).

Other updates and bugfixes:

• Fix the release manifests' image references (bsc#1272604).
• Add a libguestfs-tools subpackage.
• Build with Go >= 1.25 (required by golang.org/x/net 0.55).
• Version 1.8.4:
  • node-labeller: use new libvirt flags for full feature expansion.
  • Fix gRPC connection leak in GetLauncherClient; clean up ghost launcher record on connection setup failure.
  • api: validate VMI VSOCK CID and checksum status fields as uint32.
  • virt-operator: refine canary flow to fully support out-of-band changes.
  • New virt-api/virt-handler/virt-operator ready and down metrics, alerts and recording rules.
• Refresh disks-images-provider.yaml to the v1.8.4 image tag.

This update for containerized-data-importer1.65 fixes the following issues:

• CVE-2025-22869: Denial of Service in the Key Exchange of golang.org/x/crypto/ssh (bsc#1239322).
• CVE-2025-22870: golang.org/x/net/proxy: proxy bypass using IPv6 zone IDs (bsc#1238699).
• CVE-2025-22872: golang.org/x/net/html: incorrectly interpreted tags can cause content to be placed wrong scope during DOM construction (bsc#1241838).
• CVE-2025-47911: golang.org/x/net/html: various algorithms with quadratic complexity when parsing HTML documents (bsc#1251495).
• CVE-2025-47913: client process termination when receiving an unexpected message type in response to a key listing or (bsc#1253506).
• CVE-2025-47914: non validated message size can cause a panic due to an out of bounds read (bsc#1253967).
• CVE-2025-58058: github.com/ulikunitz/xz: github.com/ulikunitz/xz leaks memory (bsc#1248946).
• CVE-2025-58181: invalidated number of mechanisms can cause unbounded memory consumption (bsc#1253784).
• CVE-2025-58190: golang.org/x/net/html: excessive memory consumption by html.ParseFragment when processing specially crafted input (bsc#1251689).
• CVE-2026-25680,CVE-2026-25681,CVE-2026-27136,CVE-2026-42502,CVE-2026-42506: golang.org/x/net/html: multiple issues when parsing HTML files (bsc#1267176).
• CVE-2026-33186: google.golang.org/grpc: authorization bypass due to improper validation of the HTTP/2 :path pseudo- header (bsc#1260295).
• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265799).
• CVE-2026-34986: github.com/go-jose/go-jose/v3: crafted JWE input with a missing encrypted key can lead to a denial of service (bsc#1262952).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262269).
• CVE-2026-39821: golang.org/x/net/idna: failure to reject ASCII-only Punycode-encoded labels allows for validation bypass and privilege escalation (bsc#1266639).
• CVE-2026-39827,CVE-2026-39828,CVE-2026-39829,CVE-2026-39830,CVE-2026-39831,CVE-2026-39832,CVE-2026-39833, CVE-2026-39834,CVE-2026-39835,CVE-2026-42508,CVE-2026-46595,CVE-2026-46597, CVE-2026-46598: multiple issues in golang.org/x/crypto/ssh (bsc#1266179).
• CVE-2026-41178: go.opentelemetry.io/otel/baggage: no rejection of raw-length headers in baggage parsing allows for DoS via oversized inputs (bsc#1276687).
• CVE-2026-56852: golang.org/x/text/unicode/norm: infinite loop on truncated/invalid UTF-8 input (bsc#1272064).
• CVE-2026-56854,CVE-2026-56855,CVE-2026-78662: golang.org/x/crypto/ssh: authentication bypass and deadlocks in the crypto/ssh library (bsc#1278621).
• CVE-2026-84303: google.golang.org/grpc: xDS RBAC HTTP filter implementation issue allows for bypass of authorization policies via mixed-case or canonical-case header matches (bsc#1279315).
• CVE-2026-84304: google.golang.org/grpc: heap memory exhaustion via HTTP/2 DATA frame fragmentation (bsc#1279234).

Root has patched CVE-2026-35469 in the github.com/moby/spdystream package for Root:Go. Multiple fixed versions available.

This update for containerd fixes the following issues

• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262266).

This update for containerd fixes the following issues

• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262266).

This update for kubernetes1.23 fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

This update for kubernetes1.24 fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

This update for kubernetes1.26 fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

This update for kubernetes1.27 fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

This update for kubernetes1.23 fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

This update for kubernetes fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265748).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262270).

Changes for kubernetes:

• Update to version 1.35.4:

This update for kubernetes1.24 fixes the following issues

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

This update for kubernetes1.28 fixes the following issues:

Security fixes:

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

Other fixes:

• Adding Requires: diffutils dependency to Kubernetes*-client package (bsc#1251168)

This update for kubernetes1.25 fixes the following issues:

Security fixes:

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265740).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262271).

Other fixes:

• Adding Requires: diffutils dependency to Kubernetes*-client package (bsc#1251168)

This update for containerd fixes the following issues:

• CVE-2026-53488: CRI plugin propagates labels from an image config to a container without validation (bsc#1268430).

This update for kubernetes-old fixes the following issues:

• CVE-2026-33814: golang.org/x/net/http2: infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE (bsc#1265747).
• CVE-2026-35469: github.com/moby/spdystream: memory amplification in SPDY frame parsing leads to denial of service (bsc#1262268).

Changes for kubernetes-old:

• Update to version 1.33.11:

This update for kubevirt-1.6 fixes the following issues:

• CVE-2026-9804: Symlink escape in the VMExport dir handler let an attacker controlling an exported PVC read sensitive files (TLS keys, tokens, service-account creds) from the exporter pod. (bsc#1266733)
• CVE-2025-14525: A VM reporting many guest-internal interfaces via the guest agent could flood VMI status and fill etcd (denial of service). Caps reported interfaces at 10. (bsc#1256434)
• CVE-2026-35469: resource-exhaustion in the SPDY/3 protocol implementation of github.com/moby/spdystream. (GHSA-pc3f-x583-g7j2,bsc#1262265)

This update for kubevirt fixes the following issues:

• CVE-2026-9804: Symlink escape in the VMExport dir handler let an attacker controlling an exported PVC read sensitive files (TLS keys, tokens, service-account creds) from the exporter pod. (bsc#1266733)
• CVE-2025-14525: A VM reporting many guest-internal interfaces via the guest agent could flood VMI status and fill etcd (denial of service). Caps reported interfaces at 10. (bsc#1256434)
• CVE-2026-35469: resource-exhaustion in the SPDY/3 protocol implementation of github.com/moby/spdystream. (GHSA-pc3f-x583-g7j2,bsc#1262265)

This update for kubevirt fixes the following issues:

• Security: re-vendor the bundled Go dependencies (no upstream source changes; tarball rebuilt from v1.7.4 with updated go.mod/vendor):
  • golang.org/x/net v0.48.0 -> v0.55.0: CVE-2026-33814 (bsc#1265736), CVE-2026-39821 (bsc#1266575), CVE-2026-25680, CVE-2026-25681, CVE-2026-27136, CVE-2026-42502, CVE-2026-42506 (bsc#1267120)
  • golang.org/x/crypto v0.46.0 -> v0.52.0: CVE-2026-39827, CVE-2026-39828, CVE-2026-39829, CVE-2026-39830, CVE-2026-39831, CVE-2026-39832, CVE-2026-39833, CVE-2026-39834, CVE-2026-39835, CVE-2026-42508, CVE-2026-46595, CVE-2026-46597, CVE-2026-46598 (bsc#1266151)
  • github.com/moby/spdystream v0.5.0 -> v0.5.1 folded into the vendor tree;
• Build with Go >= 1.25 (required by golang.org/x/net 0.55).