https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 16:53:49 +0000 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1241 certfr-2026-avi-1241 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1241 https://vulnerability.circl.lu/vuln/fkie_cve-2026-84784 <p>Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.</p> <p>Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).</p> <p>CWE: CWE-770: Allocation of Resources Without Limits or Throttling</p> <p>Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.</p> <p>The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after th…</p> <p>Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.</p> <p>Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).</p> <p>CWE: CWE-770: Allocation of Resources Without Limits or Throttling</p> <p>Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.</p> <p>The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after th…</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-84784 https://vulnerability.circl.lu/vuln/ghsa-4fx9-95x6-pq4q <p>Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.</p> <p>Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).</p> <p>CWE: CWE-770: Allocation of Resources Without Limits or Throttling</p> <p>Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.</p> <p>The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after th…</p> <p>Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use.</p> <p>Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay).</p> <p>CWE: CWE-770: Allocation of Resources Without Limits or Throttling</p> <p>Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired.</p> <p>The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after th…</p> https://vulnerability.circl.lu/vuln/ghsa-4fx9-95x6-pq4q https://vulnerability.circl.lu/vuln/rhsa-2026:74162 <p>openssl: openssl: Denial of Service via excessive memory allocation in CRL distribution point processing openssl: openssl: Traffic amplification Denial of Service via QUIC packet over-accounting openssl: openssl: Denial of Service via inefficient QUIC stream reassembly openssl: OpenSSL: Private key recovery via timing side-channel in generic elliptic curve operations openssl: openssl: Denial of Service via excessive QUIC packet buffer retention openssl: openssl: information disclosure via non-constant-time SM2 scalar multiplication on ARM64 and RISC-V openssl: openssl: Denial of Service via out-of-bounds write during TLS context switch openssl: OpenSSL: Denial of Service via unenforced QUIC connection flow control openssl: openssl: Denial of Service via crafted CMP certificate revocation response openssl: OpenSSL: Denial of Service via undersized DTLS record openssl: OpenSSL: Private key recovery via SM2 timing side-channel openssl: compat-openssl: openssl: Information disclosure via DTLS handshake retransmission openssl: OpenSSL: Denial of Service via unbounded QUIC connection identifier backlog</p> <p>openssl: openssl: Denial of Service via excessive memory allocation in CRL distribution point processing openssl: openssl: Traffic amplification Denial of Service via QUIC packet over-accounting openssl: openssl: Denial of Service via inefficient QUIC stream reassembly openssl: OpenSSL: Private key recovery via timing side-channel in generic elliptic curve operations openssl: openssl: Denial of Service via excessive QUIC packet buffer retention openssl: openssl: information disclosure via non-constant-time SM2 scalar multiplication on ARM64 and RISC-V openssl: openssl: Denial of Service via out-of-bounds write during TLS context switch openssl: OpenSSL: Denial of Service via unenforced QUIC connection flow control openssl: openssl: Denial of Service via crafted CMP certificate revocation response openssl: OpenSSL: Denial of Service via undersized DTLS record openssl: OpenSSL: Private key recovery via SM2 timing side-channel openssl: compat-openssl: openssl: Information disclosure via DTLS handshake retransmission openssl: OpenSSL: Denial of Service via unbounded QUIC connection identifier backlog</p> https://vulnerability.circl.lu/vuln/rhsa-2026:74162 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-84784 <p><strong>Affected:</strong> Ubuntu:Pro:22.04:LTS: nodejs, Ubuntu:26.04:LTS: edk2, Ubuntu:26.04:LTS: edk2-hwe, Ubuntu:26.04:LTS: openssl</p> <p>Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the lo…</p> <p><strong>Affected:</strong> Ubuntu:Pro:22.04:LTS: nodejs, Ubuntu:26.04:LTS: edk2, Ubuntu:26.04:LTS: edk2-hwe, Ubuntu:26.04:LTS: openssl</p> <p>Issue summary: A malicious remote peer may flood the local QUIC stack with NEW_CONNECTION_ID frames by avoiding a limit check on how many connection IDs the remote QUIC stack can use. Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID frame is dispatched via the Control Frame Queue (CFQ). If the remote peer also withholds ACKs, then it can force the local stack to allocate ~400MB (depending on ACK delay). CWE: CWE-770: Allocation of Resources Without Limits or Throttling Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism by which a remote peer can notify the local QUIC stack to change the destination connection ID (a.k.a. CID) the local stack uses to identify the connection at the remote peer. Each CID is associated with a sequence number. The sequence number is transmitted in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID which is being either associated with a connection or retired. The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know a new CID is being associated with an existing connection. The NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the retire-prior-to number. The retire-prior-to identifies existing CIDs that are to be retired. The local QUIC stack must send a RETIRE_CONNECTION_ID for every destination CID whose sequence number is less than retire-prior-to. The CID becomes retired after the lo…</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-84784