{"api_version":"1","generated_at":"2026-10-01T11:59:29+00:00","cve":"CVE-2026-84784","urls":{"html":"https://cve.report/CVE-2026-84784","api":"https://cve.report/api/cve/CVE-2026-84784.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-84784","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-84784"},"summary":{"title":"QUIC: Unbounded RETIRE_CONNECTION_ID Backlog","description":"Issue summary: A malicious remote peer may flood the local QUIC\nstack with NEW_CONNECTION_ID frames by avoiding a limit check on\nhow many connection IDs the remote QUIC stack can use.\n\nImpact summary: The local QUIC stack sends a RETIRE_CONN_ID frame\nfor every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID\nframe is dispatched via the Control Frame Queue (CFQ). If the remote\npeer also withholds ACKs, then it can force the local stack\nto allocate ~400MB (depending on ACK delay).\n\nCWE: CWE-770: Allocation of Resources Without Limits or Throttling\n\nDescription: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism\nby which a remote peer can notify the local QUIC stack to change the\ndestination connection ID (a.k.a. CID) the local stack uses to\nidentify the connection at the remote peer. Each CID is associated\nwith a sequence number. The sequence number is transmitted\nin NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID\nwhich is being either associated with a connection or retired.\n\nThe remote peer sends a NEW_CONNECTION_ID frame to let the local stack know\na new CID is being associated with an existing connection. The\nNEW_CONNECTION_ID frame carries the new CID, its sequence number, and the\nretire-prior-to number. The retire-prior-to identifies existing\nCIDs that are to be retired. The local QUIC stack must send a\nRETIRE_CONNECTION_ID for every destination CID whose sequence number\nis less than retire-prior-to. The CID becomes retired after the\nlocal stack receives an ACK for its RETIRE_CONNECTION_ID frame.\n\nAlthough the OpenSSL QUIC stack supports at most one destination CID\nfor every connection, it can be tricked into processing more than\none RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC\nstack currently retires the destination CID as soon as it receives\nthe NEW_CONNECTION_ID, while in fact the destination CID must\nbe retired after an ACK for the RETIRE_CONNECTION_ID frame is received.\nCorrecting the flawed logic also fixes the backlog growth.\n\n[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids\n\nFIPS impact: no\nThe FIPS module is not affected as the QUIC implementation is outside of\nthe OpenSSL FIPS module boundary.","state":"PUBLISHED","assigner":"openssl","published_at":"2026-09-29 16:17:12","updated_at":"2026-09-29 21:27:41"},"problem_types":["CWE-770","CWE-770 CWE-770 Allocation of Resources Without Limits or Throttling"],"metrics":[{"version":"3.1","source":"ADP","type":"DECLARED","score":"7.5","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":7.5,"baseSeverity":"HIGH","confidentialityImpact":"NONE","integrityImpact":"NONE","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"}},{"version":"3.1","source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","score":"7.5","severity":"HIGH","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"}}],"references":[{"url":"https://github.com/openssl/openssl/commit/e9e5155833fa968bee50024bf9ca3a185ab599fe","name":"https://github.com/openssl/openssl/commit/e9e5155833fa968bee50024bf9ca3a185ab599fe","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/openssl/openssl/commit/dba3c48d653c64fcbc9070a17a0ee2b3e2f3af1f","name":"https://github.com/openssl/openssl/commit/dba3c48d653c64fcbc9070a17a0ee2b3e2f3af1f","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/openssl/openssl/commit/9a30fe0fba195c14e5b87bf93c0d0fdb70373806","name":"https://github.com/openssl/openssl/commit/9a30fe0fba195c14e5b87bf93c0d0fdb70373806","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://openssl-library.org/news/secadv/20260929.txt","name":"https://openssl-library.org/news/secadv/20260929.txt","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/openssl/openssl/commit/4685c914b0d410b1034f40b547c95bc95e7a380a","name":"https://github.com/openssl/openssl/commit/4685c914b0d410b1034f40b547c95bc95e7a380a","refsource":"openssl-security@openssl.org","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-84784","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-84784","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 4.0.0 4.0.3 semver","platforms":[]},{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 3.6.0 3.6.5 semver","platforms":[]},{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 3.5.0 3.5.9 semver","platforms":[]},{"source":"CNA","vendor":"OpenSSL","product":"OpenSSL","version":"affected 3.4.0 3.4.8 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Bhabani Sankar Das","lang":"en"},{"source":"CNA","value":"Alexandr Nedvedicky","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"metrics":[{"cvssV3_1":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":7.5,"baseSeverity":"HIGH","confidentialityImpact":"NONE","integrityImpact":"NONE","privilegesRequired":"NONE","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","version":"3.1"}},{"other":{"content":{"id":"CVE-2026-84784","options":[{"Exploitation":"none"},{"Automatable":"yes"},{"Technical Impact":"partial"}],"role":"CISA Coordinator","timestamp":"2026-09-29T16:43:47.766260Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-09-29T16:44:09.766Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"defaultStatus":"unaffected","product":"OpenSSL","vendor":"OpenSSL","versions":[{"lessThan":"4.0.3","status":"affected","version":"4.0.0","versionType":"semver"},{"lessThan":"3.6.5","status":"affected","version":"3.6.0","versionType":"semver"},{"lessThan":"3.5.9","status":"affected","version":"3.5.0","versionType":"semver"},{"lessThan":"3.4.8","status":"affected","version":"3.4.0","versionType":"semver"}]}],"credits":[{"lang":"en","type":"reporter","value":"Bhabani Sankar Das"},{"lang":"en","type":"remediation developer","value":"Alexandr Nedvedicky"}],"datePublic":"2026-09-29T14:21:57.000Z","descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"Issue summary: A malicious remote peer may flood the local QUIC<br>stack with NEW_CONNECTION_ID frames by avoiding a limit check on<br>how many connection IDs the remote QUIC stack can use.<br><br>Impact summary: The local QUIC stack sends a RETIRE_CONN_ID frame<br>for every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID<br>frame is dispatched via the Control Frame Queue (CFQ). If the remote<br>peer also withholds ACKs, then it can force the local stack<br>to allocate ~400MB (depending on ACK delay).<br><br>CWE: CWE-770: Allocation of Resources Without Limits or Throttling<br><br>Description: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism<br>by which a remote peer can notify the local QUIC stack to change the<br>destination connection ID (a.k.a. CID) the local stack uses to<br>identify the connection at the remote peer. Each CID is associated<br>with a sequence number. The sequence number is transmitted<br>in NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID<br>which is being either associated with a connection or retired.<br><br>The remote peer sends a NEW_CONNECTION_ID frame to let the local stack know<br>a new CID is being associated with an existing connection. The<br>NEW_CONNECTION_ID frame carries the new CID, its sequence number, and the<br>retire-prior-to number. The retire-prior-to identifies existing<br>CIDs that are to be retired. The local QUIC stack must send a<br>RETIRE_CONNECTION_ID for every destination CID whose sequence number<br>is less than retire-prior-to. The CID becomes retired after the<br>local stack receives an ACK for its RETIRE_CONNECTION_ID frame.<br><br>Although the OpenSSL QUIC stack supports at most one destination CID<br>for every connection, it can be tricked into processing more than<br>one RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC<br>stack currently retires the destination CID as soon as it receives<br>the NEW_CONNECTION_ID, while in fact the destination CID must<br>be retired after an ACK for the RETIRE_CONNECTION_ID frame is received.<br>Correcting the flawed logic also fixes the backlog growth.<br><br>[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids<br><br>FIPS impact: no<br>The FIPS module is not affected as the QUIC implementation is outside of<br>the OpenSSL FIPS module boundary."}],"value":"Issue summary: A malicious remote peer may flood the local QUIC\nstack with NEW_CONNECTION_ID frames by avoiding a limit check on\nhow many connection IDs the remote QUIC stack can use.\n\nImpact summary: The local QUIC stack sends a RETIRE_CONN_ID frame\nfor every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID\nframe is dispatched via the Control Frame Queue (CFQ). If the remote\npeer also withholds ACKs, then it can force the local stack\nto allocate ~400MB (depending on ACK delay).\n\nCWE: CWE-770: Allocation of Resources Without Limits or Throttling\n\nDescription: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism\nby which a remote peer can notify the local QUIC stack to change the\ndestination connection ID (a.k.a. CID) the local stack uses to\nidentify the connection at the remote peer. Each CID is associated\nwith a sequence number. The sequence number is transmitted\nin NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID\nwhich is being either associated with a connection or retired.\n\nThe remote peer sends a NEW_CONNECTION_ID frame to let the local stack know\na new CID is being associated with an existing connection. The\nNEW_CONNECTION_ID frame carries the new CID, its sequence number, and the\nretire-prior-to number. The retire-prior-to identifies existing\nCIDs that are to be retired. The local QUIC stack must send a\nRETIRE_CONNECTION_ID for every destination CID whose sequence number\nis less than retire-prior-to. The CID becomes retired after the\nlocal stack receives an ACK for its RETIRE_CONNECTION_ID frame.\n\nAlthough the OpenSSL QUIC stack supports at most one destination CID\nfor every connection, it can be tricked into processing more than\none RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC\nstack currently retires the destination CID as soon as it receives\nthe NEW_CONNECTION_ID, while in fact the destination CID must\nbe retired after an ACK for the RETIRE_CONNECTION_ID frame is received.\nCorrecting the flawed logic also fixes the backlog growth.\n\n[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids\n\nFIPS impact: no\nThe FIPS module is not affected as the QUIC implementation is outside of\nthe OpenSSL FIPS module boundary."}],"metrics":[{"format":"other","other":{"content":{"text":"Low"},"type":"https://openssl-library.org/policies/general/security-policy/"}}],"problemTypes":[{"descriptions":[{"cweId":"CWE-770","description":"CWE-770 Allocation of Resources Without Limits or Throttling","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-09-29T15:32:25.758Z","orgId":"3a12439a-ef3a-4c79-92e6-6081a721f1e5","shortName":"openssl"},"references":[{"name":"OpenSSL Advisory","tags":["vendor-advisory"],"url":"https://openssl-library.org/news/secadv/20260929.txt"},{"name":"4.0.3 git commit","tags":["patch"],"url":"https://github.com/openssl/openssl/commit/e9e5155833fa968bee50024bf9ca3a185ab599fe"},{"name":"3.6.5 git commit","tags":["patch"],"url":"https://github.com/openssl/openssl/commit/4685c914b0d410b1034f40b547c95bc95e7a380a"},{"name":"3.5.9 git commit","tags":["patch"],"url":"https://github.com/openssl/openssl/commit/dba3c48d653c64fcbc9070a17a0ee2b3e2f3af1f"},{"name":"3.4.8 git commit","tags":["patch"],"url":"https://github.com/openssl/openssl/commit/9a30fe0fba195c14e5b87bf93c0d0fdb70373806"}],"source":{"discovery":"UNKNOWN"},"title":"QUIC: Unbounded RETIRE_CONNECTION_ID Backlog","x_generator":{"engine":"Vulnogram 0.2.0"}}},"cveMetadata":{"assignerOrgId":"3a12439a-ef3a-4c79-92e6-6081a721f1e5","assignerShortName":"openssl","cveId":"CVE-2026-84784","datePublished":"2026-09-29T15:32:25.758Z","dateReserved":"2026-09-02T10:14:02.262Z","dateUpdated":"2026-09-29T16:44:09.766Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-09-29 16:17:12","lastModifiedDate":"2026-09-29 21:27:41","problem_types":["CWE-770","CWE-770 CWE-770 Allocation of Resources Without Limits or Throttling"],"metrics":{"cvssMetricV31":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H","baseScore":7.5,"baseSeverity":"HIGH","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"NONE","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"NONE","integrityImpact":"NONE","availabilityImpact":"HIGH"},"exploitabilityScore":3.9,"impactScore":3.6}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-09-29T16:43:47.766260Z","id":"CVE-2026-84784","options":[{"exploitation":"none"},{"automatable":"yes"},{"technicalImpact":"partial"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"84784","Ordinal":"1","Title":"QUIC: Unbounded RETIRE_CONNECTION_ID Backlog","CVE":"CVE-2026-84784","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"84784","Ordinal":"1","NoteData":"Issue summary: A malicious remote peer may flood the local QUIC\nstack with NEW_CONNECTION_ID frames by avoiding a limit check on\nhow many connection IDs the remote QUIC stack can use.\n\nImpact summary: The local QUIC stack sends a RETIRE_CONN_ID frame\nfor every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID\nframe is dispatched via the Control Frame Queue (CFQ). If the remote\npeer also withholds ACKs, then it can force the local stack\nto allocate ~400MB (depending on ACK delay).\n\nCWE: CWE-770: Allocation of Resources Without Limits or Throttling\n\nDescription: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism\nby which a remote peer can notify the local QUIC stack to change the\ndestination connection ID (a.k.a. CID) the local stack uses to\nidentify the connection at the remote peer. Each CID is associated\nwith a sequence number. The sequence number is transmitted\nin NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID\nwhich is being either associated with a connection or retired.\n\nThe remote peer sends a NEW_CONNECTION_ID frame to let the local stack know\na new CID is being associated with an existing connection. The\nNEW_CONNECTION_ID frame carries the new CID, its sequence number, and the\nretire-prior-to number. The retire-prior-to identifies existing\nCIDs that are to be retired. The local QUIC stack must send a\nRETIRE_CONNECTION_ID for every destination CID whose sequence number\nis less than retire-prior-to. The CID becomes retired after the\nlocal stack receives an ACK for its RETIRE_CONNECTION_ID frame.\n\nAlthough the OpenSSL QUIC stack supports at most one destination CID\nfor every connection, it can be tricked into processing more than\none RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC\nstack currently retires the destination CID as soon as it receives\nthe NEW_CONNECTION_ID, while in fact the destination CID must\nbe retired after an ACK for the RETIRE_CONNECTION_ID frame is received.\nCorrecting the flawed logic also fixes the backlog growth.\n\n[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids\n\nFIPS impact: no\nThe FIPS module is not affected as the QUIC implementation is outside of\nthe OpenSSL FIPS module boundary.","Type":"Description","Title":"QUIC: Unbounded RETIRE_CONNECTION_ID Backlog"}]}}}