https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T00:39:44.076813+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/certfr-2026-avi-0218 certfr-2026-avi-0218 — De multiples vulnérabilités ont été découvertes dans les produits VMware. Certaines d'entre elles permettent à un attaq… 2026-10-03T00:39:44.226295+00:00 certfr-2026-avi-0218 https://cve.radiocsirt.org/vuln/cleanstart-2026-bb57522 Withdrawn: CLEANSTART-2026-BB57522 — Security fixes in kubernetes-dns-node-cache 1.25.0-r8 2026-10-03T00:39:44.226344+00:00

Withdrawn by the publisher.

Affected: CleanStart: kubernetes-dns-node-cache

Package kubernetes-dns-node-cache version 1.25.0-r8 fixes 17 vulnerabilities: CVE-2026-41178, CVE-2026-35579, CVE-2026-46600, CVE-2025-64702, CVE-2025-68151...

 https://cve.radiocsirt.org/vuln/euvd-2026-263484 EUVD-2026-263484 2026-10-03T00:39:44.226377+00:00 EUVD-2026-263484 https://cve.radiocsirt.org/vuln/fkie_cve-2025-64702 fkie_cve-2025-64702 2026-10-03T00:39:44.226392+00:00

quic-go is an implementation of the QUIC protocol in Go. Versions 0.56.0 and below are vulnerable to excessive memory allocation through quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an http.Header (used on the http.Request and http.Response, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion. This issue is fixed in version 0.57.0.

 https://cve.radiocsirt.org/vuln/ghsa-g754-hx8w-x2g6 GHSA-g754-hx8w-x2g6 — quic-go HTTP/3 QPACK Header Expansion DoS 2026-10-03T00:39:44.226418+00:00

Affected: Go: github.com/quic-go/quic-go

## Summary

An attacker can cause excessive memory allocation in quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an `http.Header` (used on the `http.Request` and `http.Response`, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion.

## Impact

A misbehaving or malicious peer can cause a denial-of-service (DoS) attack on quic-go's HTTP/3 servers or clients by triggering excessive memory allocation, potentially leading to crashes or exhaustion. It affects both servers and clients due to symmetric header construction.

## Details

In HTTP/3, headers are compressed using QPACK (RFC 9204). quic-go's HTTP/3 server (and client) decodes the QPACK-encoded HEADERS frame into header fields, then constructs an http.Request (or response).

`http3.Server.MaxHeaderBytes` and `http3.Transport.MaxResponseHeaderBytes`, respectively, limit encoded HEADERS frame size (default: 1 MB server, 10 MB client), but not decoded size. A maliciously crafted HEADERS frame can expand to ~50x the encoded size using QPACK static table entries with long names / values.

RFC 9114 requires enforcing decoded field section size limits via SETTINGS, which quic-go did not do.

## The Fix

quic-go now enforces RFC 9114 decoded field section size limits…

 https://cve.radiocsirt.org/vuln/opensuse-su-2026:10035-1 openSUSE-SU-2026:10035-1 — teleport-17.7.13-1.1 on GA media 2026-10-03T00:39:44.226463+00:00

teleport-17.7.13-1.1 on GA media

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-64702 UBUNTU-CVE-2025-64702 2026-10-03T00:39:44.226481+00:00

Affected: Ubuntu:22.04:LTS: golang-github-lucas-clemente-quic-go, Ubuntu:24.04:LTS: golang-github-lucas-clemente-quic-go, Ubuntu:25.10: golang-github-lucas-clemente-quic-go, Ubuntu:26.04:LTS: golang-github-lucas-clemente-quic-go

quic-go is an implementation of the QUIC protocol in Go. Versions 0.56.0 and below are vulnerable to excessive memory allocation through quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an http.Header (used on the http.Request and http.Response, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion. This issue is fixed in version 0.57.0.