Description
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
local stack receives an ACK for its RETIRE_CONNECTION_ID frame.

Although the OpenSSL QUIC stack supports at most one destination CID
for every connection, it can be tricked into processing more than
one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC
stack currently retires the destination CID as soon as it receives
the NEW_CONNECTION_ID, while in fact the destination CID must
be retired after an ACK for the RETIRE_CONNECTION_ID frame is received.
Correcting the flawed logic also fixes the backlog growth.

[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids

FIPS impact: no
The FIPS module is not affected as the QUIC implementation is outside of
the OpenSSL FIPS module boundary.
Published: 2026-09-29
Score: 7.5 High
EPSS: < 1% Very Low
KEV: No
Impact: Denial of Service
Action: Immediate Patch
AI Analysis

Impact

A remote host can send a large number of NEW_CONNECTION_ID frames to a local OpenSSL QUIC stack, causing the stack to enqueue a RETIRE_CONNECTION_ID frame for each received frame. Because the stack releases these frames only after an ACK is received, an attacker can avoid ACKs and force the Local QUIC stack to allocate up to around 400 MB of memory, leading to resource exhaustion. This issue arises from a flaw in the QUIC implementation that disregards limits on the number of connection identifiers and is classified as CWE‑770: Allocation of Resources Without Limits or Throttling.

Affected Systems

The vulnerability affects the OpenSSL QUIC implementation in all product releases that include QUIC support. Specific affected version ranges are not provided in the advisory, so all releases prior to the fix that contain the QUIC stack are considered vulnerable.

Risk and Exploitability

The CVSS score of 7.5 indicates moderate‑to‑high severity, and although the EPSS score is not available, the lack of a KEV listing suggests exploitation is not yet widely documented. An attacker can trigger the issue from the remote side without special privileges by sending large volumes of QUIC frames and suppressing ACKs. The exploitation requires a reachable QUIC service and the ability to send or replay QUIC frames, implying that the attack vector is remote and unauthenticated.

Generated by OpenCVE AI on September 29, 2026 at 22:30 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade OpenSSL to a release that contains the fix for CVE‑2026‑84784.
  • If an immediate upgrade is not feasible, consider disabling QUIC traffic or configuring a firewall rule to rate‑limit QUIC packets to mitigate resource exhaustion.
  • Implement monitoring on QUIC connection buffers and trigger an automated restart or resource cleanup when the buffer size exceeds a safe threshold.

Generated by OpenCVE AI on September 29, 2026 at 22:30 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Debian DSA Debian DSA DSA-6531-1 openssl security update
Ubuntu USN Ubuntu USN USN-8847-1 OpenSSL vulnerabilities
History

Thu, 08 Oct 2026 01:30:00 +0000

Type Values Removed Values Added
CPEs cpe:2.3:a:openssl:openssl:*:*:*:*:*:*:*:*

Wed, 30 Sep 2026 00:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

threat_severity

Moderate


Tue, 29 Sep 2026 17:45:00 +0000

Type Values Removed Values Added
First Time appeared Openssl
Openssl openssl
Vendors & Products Openssl
Openssl openssl

Tue, 29 Sep 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Tue, 29 Sep 2026 15:45:00 +0000

Type Values Removed Values Added
Description 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 local stack receives an ACK for its RETIRE_CONNECTION_ID frame. Although the OpenSSL QUIC stack supports at most one destination CID for every connection, it can be tricked into processing more than one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC stack currently retires the destination CID as soon as it receives the NEW_CONNECTION_ID, while in fact the destination CID must be retired after an ACK for the RETIRE_CONNECTION_ID frame is received. Correcting the flawed logic also fixes the backlog growth. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS impact: no The FIPS module is not affected as the QUIC implementation is outside of the OpenSSL FIPS module boundary.
Title QUIC: Unbounded RETIRE_CONNECTION_ID Backlog
Weaknesses CWE-770
References

cve-icon MITRE

Status: PUBLISHED

Assigner: openssl

Published:

Updated: 2026-09-29T16:44:09.766Z

Reserved: 2026-09-02T10:14:02.262Z

Link: CVE-2026-84784

cve-icon Vulnrichment

Updated: 2026-09-29T16:43:59.933Z

cve-icon NVD

Status : Analyzed

Published: 2026-09-29T16:17:12.810

Modified: 2026-10-08T01:21:22.543

Link: CVE-2026-84784

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-09-29T15:32:25Z

Links: CVE-2026-84784 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-09-29T22:30:19Z

Weaknesses
  • CWE-770

    Allocation of Resources Without Limits or Throttling