{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "HIGH",
              "attackVector": "NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 3.7,
              "baseSeverity": "LOW",
              "confidentialityImpact": "LOW",
              "integrityImpact": "NONE",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-77696",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-29T16:51:30.070097Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-29T16:51:33.618Z",
          "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"
            },
            {
              "lessThan": "3.0.23",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            },
            {
              "lessThan": "1.1.1zj",
              "status": "affected",
              "version": "1.1.1",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Vladimir Tokarev"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Igor Ustinov"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Viktor Dukhovni"
        }
      ],
      "datePublic": "2026-09-29T14:21:57.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Issue summary: SM2 signature generation uses non-constant-time arithmetic\u003cbr\u003eon secret values, forming a timing side-channel.\u003cbr\u003e\u003cbr\u003eImpact summary: An attacker able to measure SM2 signing times may learn\u003cbr\u003einformation about the per-signature secret nonce, which over many signatures\u003cbr\u003ecan, via a lattice / Hidden Number Problem attack, lead to recovery of the\u003cbr\u003eprivate key.\u003cbr\u003e\u003cbr\u003eCWE: CWE-208: Observable Timing Discrepancy\u003cbr\u003e\u003cbr\u003eDescription: SM2 signature generation computes the signature value using\u003cbr\u003evariable-time BIGNUM operations on the secret nonce and the private key, so\u003cbr\u003ethe time taken to produce an SM2 signature depends on these secret values,\u003cbr\u003eforming a timing side-channel.\u003cbr\u003e\u003cbr\u003eApplications performing SM2 signature generation are affected on all\u003cbr\u003eplatforms.\u003cbr\u003e\u003cbr\u003eFIPS Impact: no\u003cbr\u003eSM2 is not a FIPS algorithm."
            }
          ],
          "value": "Issue summary: SM2 signature generation uses non-constant-time arithmetic\non secret values, forming a timing side-channel.\n\nImpact summary: An attacker able to measure SM2 signing times may learn\ninformation about the per-signature secret nonce, which over many signatures\ncan, via a lattice / Hidden Number Problem attack, lead to recovery of the\nprivate key.\n\nCWE: CWE-208: Observable Timing Discrepancy\n\nDescription: SM2 signature generation computes the signature value using\nvariable-time BIGNUM operations on the secret nonce and the private key, so\nthe time taken to produce an SM2 signature depends on these secret values,\nforming a timing side-channel.\n\nApplications performing SM2 signature generation are affected on all\nplatforms.\n\nFIPS Impact: no\nSM2 is not a FIPS algorithm."
        }
      ],
      "metrics": [
        {
          "format": "other",
          "other": {
            "content": {
              "text": "Low"
            },
            "type": "https://openssl-library.org/policies/general/security-policy/"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-208",
              "description": "CWE-208 Observable Timing Discrepancy",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-29T15:32:22.520Z",
        "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/20b20628d39b2dcc4677194bd68c7c060fa598cb"
        },
        {
          "name": "3.6.5 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/1c4aed808a7aea32d2d013049c2e0d9fef164fc9"
        },
        {
          "name": "3.5.9 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/6b90445a56b99a328ac1feba058abf976504f440"
        },
        {
          "name": "3.4.8 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/419f5cb519721dceed393dbc524d79e487c72e64"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Timing Side-Channel in SM2 Signature Generation",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "3a12439a-ef3a-4c79-92e6-6081a721f1e5",
    "assignerShortName": "openssl",
    "cveId": "CVE-2026-77696",
    "datePublished": "2026-09-29T15:32:22.520Z",
    "dateReserved": "2026-08-21T07:47:36.032Z",
    "dateUpdated": "2026-09-29T16:51:33.618Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "HIGH",
              "baseScore": 8.2,
              "baseSeverity": "HIGH",
              "confidentialityImpact": "LOW",
              "integrityImpact": "NONE",
              "privilegesRequired": "NONE",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-84782",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-29T16:45:35.833483Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-29T16:45:40.378Z",
          "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"
            },
            {
              "lessThan": "3.0.23",
              "status": "affected",
              "version": "3.0.0",
              "versionType": "semver"
            },
            {
              "lessThan": "1.1.1zj",
              "status": "affected",
              "version": "1.1.1",
              "versionType": "custom"
            },
            {
              "lessThan": "1.0.2zs",
              "status": "affected",
              "version": "1.0.2",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Laurent Gaffie (secorizon.com)"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ryan Hooper"
        }
      ],
      "datePublic": "2026-09-29T14:21:57.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Issue summary: The DTLS retransmission logic does not correctly handle\u003cbr\u003ea handshake message write that is suspended part-way through.\u003cbr\u003eThe retransmitted message can be read past the message buffer and\u003cbr\u003ethe retransmission overwrites the internal state the suspended write\u003cbr\u003eneeds to resume correctly.\u003cbr\u003e\u003cbr\u003eImpact summary: The retransmitted message can disclose a heap memory\u003cbr\u003eto the peer as plaintext handshake data or cause a crash and a Denial\u003cbr\u003eof Service when the read reaches an unmapped memory region.\u003cbr\u003e\u003cbr\u003eCWE: CWE-125: Out-of-bounds Read\u003cbr\u003e\u003cbr\u003eDescription: DTLS handshake messages can be written out in multiple\u003cbr\u003efragments, and a write can suspend mid-message (returning WANT_WRITE)\u003cbr\u003eif the underlying transport temporarily cannot accept more data. While\u003cbr\u003esuch a write is suspended, the DTLS retransmission timer may\u003cbr\u003eindependently fire and ask the retransmission logic to resend an\u003cbr\u003eearlier, already-acknowledged-as-sent message from its retransmit\u003cbr\u003equeue.\u003cbr\u003e\u003cbr\u003eThe retransmission logic reused the same internal buffer and position\u003cbr\u003etracking as the message that was still being written, without\u003cbr\u003eresetting the position back to the start of the message being\u003cbr\u003eretransmitted. As a result the retransmission was read starting from\u003cbr\u003ewherever the suspended write had left off, producing a mislabelled\u003cbr\u003emessage whose body was leftover bytes from the other, larger message\u003cbr\u003estill in flight - content that was never meant to be sent at that\u003cbr\u003epoint, and which could run past the end of the allocated buffer.\u003cbr\u003e\u003cbr\u003eSeparately, even when the retransmission is positioned correctly,\u003cbr\u003eallowing it to run to completion while another write is suspended\u003cbr\u003eoverwrites the same shared bookkeeping that the suspended write\u003cbr\u003edepends on to resume. When the application later resumes the\u003cbr\u003esuspended write (via a subsequent SSL_read(), SSL_write(),\u003cbr\u003eSSL_accept(), or SSL_connect() call), it finds that bookkeeping in a\u003cbr\u003estate inconsistent with the message and aborts the process in\u003cbr\u003ea debugging build.\u003cbr\u003e\u003cbr\u003eThe fix resets the retransmission\u0027s read position to the start of the\u003cbr\u003emessage before resending, and skips retransmission entirely whenever a\u003cbr\u003ehandshake write is still suspended, deferring to the next call that\u003cbr\u003eresumes it instead.\u003cbr\u003e\u003cbr\u003eFIPS impact: no\u003cbr\u003eThe affected code is outside the FIPS module boundary."
            }
          ],
          "value": "Issue summary: The DTLS retransmission logic does not correctly handle\na handshake message write that is suspended part-way through.\nThe retransmitted message can be read past the message buffer and\nthe retransmission overwrites the internal state the suspended write\nneeds to resume correctly.\n\nImpact summary: The retransmitted message can disclose a heap memory\nto the peer as plaintext handshake data or cause a crash and a Denial\nof Service when the read reaches an unmapped memory region.\n\nCWE: CWE-125: Out-of-bounds Read\n\nDescription: DTLS handshake messages can be written out in multiple\nfragments, and a write can suspend mid-message (returning WANT_WRITE)\nif the underlying transport temporarily cannot accept more data. While\nsuch a write is suspended, the DTLS retransmission timer may\nindependently fire and ask the retransmission logic to resend an\nearlier, already-acknowledged-as-sent message from its retransmit\nqueue.\n\nThe retransmission logic reused the same internal buffer and position\ntracking as the message that was still being written, without\nresetting the position back to the start of the message being\nretransmitted. As a result the retransmission was read starting from\nwherever the suspended write had left off, producing a mislabelled\nmessage whose body was leftover bytes from the other, larger message\nstill in flight - content that was never meant to be sent at that\npoint, and which could run past the end of the allocated buffer.\n\nSeparately, even when the retransmission is positioned correctly,\nallowing it to run to completion while another write is suspended\noverwrites the same shared bookkeeping that the suspended write\ndepends on to resume. When the application later resumes the\nsuspended write (via a subsequent SSL_read(), SSL_write(),\nSSL_accept(), or SSL_connect() call), it finds that bookkeeping in a\nstate inconsistent with the message and aborts the process in\na debugging build.\n\nThe fix resets the retransmission\u0027s read position to the start of the\nmessage before resending, and skips retransmission entirely whenever a\nhandshake write is still suspended, deferring to the next call that\nresumes it instead.\n\nFIPS impact: no\nThe affected code is outside the FIPS module boundary."
        }
      ],
      "metrics": [
        {
          "format": "other",
          "other": {
            "content": {
              "text": "High"
            },
            "type": "https://openssl-library.org/policies/general/security-policy/"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-125",
              "description": "CWE-125 Out-of-bounds Read",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-29T15:32:23.605Z",
        "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/d951e02ede8f6a6ff8150546db44b34f0518192c"
        },
        {
          "name": "3.6.5 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/a383dafdd754eb5b22bf45e37e1bff9d07277a58"
        },
        {
          "name": "3.5.9 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/906cf0ef1c85ca40ce69163e9086d6d3fe292943"
        },
        {
          "name": "3.4.8 git commit",
          "tags": [
            "patch"
          ],
          "url": "https://github.com/openssl/openssl/commit/9f6b34422af7eb5dac61322e33dac1ae989fa628"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "DTLS Retransmits Handshake Messages From a Stale Buffer Offset",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "3a12439a-ef3a-4c79-92e6-6081a721f1e5",
    "assignerShortName": "openssl",
    "cveId": "CVE-2026-84782",
    "datePublished": "2026-09-29T15:32:23.605Z",
    "dateReserved": "2026-09-02T10:14:02.262Z",
    "dateUpdated": "2026-09-29T16:45:40.378Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "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-84783",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-29T16:42:36.722506Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-29T16:42:41.306Z",
          "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"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "Tim Becker (Xint.io)"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "aydinmercan"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Bob Beck"
        }
      ],
      "datePublic": "2026-09-29T14:21:57.000Z",
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Issue summary: The first concurrent use of the same X.509 certificate by\u003cbr\u003eseveral threads may cause its cached extension data to be freed while\u003cbr\u003eanother thread is still using it.\u003cbr\u003e\u003cbr\u003eImpact summary: A remote, unauthenticated peer could crash a multi-threaded\u003cbr\u003eTLS client, or a multi-threaded TLS server that requests client\u003cbr\u003ecertificates, if the first certificate chains built to the same trusted CA\u003cbr\u003ecertificate are built by several connections at the same time. This is a\u003cbr\u003euse-after-free read, which is likely to crash the process, resulting in a\u003cbr\u003eDenial of Service.\u003cbr\u003e\u003cbr\u003eCWE: CWE-416: Use After Free\u003cbr\u003e\u003cbr\u003eDescription: OpenSSL caches the decoded values of a certificate\u0027s X.509v3\u003cbr\u003eextensions inside the X509 object the first time they are needed. In\u003cbr\u003eOpenSSL 4.0 this cache is built in two phases: the extension values are\u003cbr\u003ecomputed while holding a read lock on the certificate, and the results are\u003cbr\u003ethen installed into the certificate under a write lock. Because a read lock\u003cbr\u003edoes not exclude other readers, several threads can compute the cache for\u003cbr\u003ethe same certificate at the same time. Each thread that subsequently\u003cbr\u003eacquires the write lock installs its own results and frees the values\u003cbr\u003einstalled by the thread before it, even though that earlier thread has\u003cbr\u003ealready marked the cache as complete and may have returned pointers into it\u003cbr\u003eto its caller. A caller still using those pointers then reads freed memory.\u003cbr\u003e\u003cbr\u003eAny certificate shared between threads is exposed the first time its\u003cbr\u003eextensions are decoded. In TLS the certificates at risk are the trusted CA\u003cbr\u003ecertificates supplied for chain verification, by whatever means, since these\u003cbr\u003eare shared by every connection and their extensions are decoded and cached\u003cbr\u003ethe first time a chain is built to them. Certificates sent by the peer are\u003cbr\u003edecoded separately for each connection and are not shared, so they are not\u003cbr\u003eaffected. In a TLS client verifying server certificates, or a TLS server\u003cbr\u003ethat requests and verifies client certificates, the use-after-free could\u003cbr\u003eonly occur if the first chains built to the same trusted CA are built by\u003cbr\u003eseveral connections at the same time.\u003cbr\u003e\u003cbr\u003eFIPS impact: no\u003cbr\u003eThe FIPS module is not affected as X.509 certificate handling is outside\u003cbr\u003eof the OpenSSL FIPS module boundary.\u003cbr\u003e\u003cbr\u003eOpenSSL 4.0 is vulnerable to this issue.\u003cbr\u003e\u003cbr\u003eOpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.\u003cbr\u003e\u003cbr\u003eOpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.\u003cbr\u003e\u003cbr\u003eThis issue was reported on 27 August 2026 by Tim Becker (Xint.io) and\u003cbr\u003eindependently in a public report on 31 August 2026 by aydinmercan.\u003cbr\u003e\u003cbr\u003eThe fix has been developed by Bob Beck.\u003cbr\u003e\u003cbr\u003e-- cut (non-publishing metadata for internal use) --\u003cbr\u003eReported by: Tim Becker (Xint.io), aydinmercan\u003cbr\u003eFixed by: Bob Beck"
            }
          ],
          "value": "Issue summary: The first concurrent use of the same X.509 certificate by\nseveral threads may cause its cached extension data to be freed while\nanother thread is still using it.\n\nImpact summary: A remote, unauthenticated peer could crash a multi-threaded\nTLS client, or a multi-threaded TLS server that requests client\ncertificates, if the first certificate chains built to the same trusted CA\ncertificate are built by several connections at the same time. This is a\nuse-after-free read, which is likely to crash the process, resulting in a\nDenial of Service.\n\nCWE: CWE-416: Use After Free\n\nDescription: OpenSSL caches the decoded values of a certificate\u0027s X.509v3\nextensions inside the X509 object the first time they are needed. In\nOpenSSL 4.0 this cache is built in two phases: the extension values are\ncomputed while holding a read lock on the certificate, and the results are\nthen installed into the certificate under a write lock. Because a read lock\ndoes not exclude other readers, several threads can compute the cache for\nthe same certificate at the same time. Each thread that subsequently\nacquires the write lock installs its own results and frees the values\ninstalled by the thread before it, even though that earlier thread has\nalready marked the cache as complete and may have returned pointers into it\nto its caller. A caller still using those pointers then reads freed memory.\n\nAny certificate shared between threads is exposed the first time its\nextensions are decoded. In TLS the certificates at risk are the trusted CA\ncertificates supplied for chain verification, by whatever means, since these\nare shared by every connection and their extensions are decoded and cached\nthe first time a chain is built to them. Certificates sent by the peer are\ndecoded separately for each connection and are not shared, so they are not\naffected. In a TLS client verifying server certificates, or a TLS server\nthat requests and verifies client certificates, the use-after-free could\nonly occur if the first chains built to the same trusted CA are built by\nseveral connections at the same time.\n\nFIPS impact: no\nThe FIPS module is not affected as X.509 certificate handling is outside\nof the OpenSSL FIPS module boundary.\n\nOpenSSL 4.0 is vulnerable to this issue.\n\nOpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.\n\nOpenSSL 4.0 users should upgrade to OpenSSL 4.0.3.\n\nThis issue was reported on 27 August 2026 by Tim Becker (Xint.io) and\nindependently in a public report on 31 August 2026 by aydinmercan.\n\nThe fix has been developed by Bob Beck.\n\n-- cut (non-publishing metadata for internal use) --\nReported by: Tim Becker (Xint.io), aydinmercan\nFixed by: Bob Beck"
        }
      ],
      "metrics": [
        {
          "format": "other",
          "other": {
            "content": {
              "text": "Moderate"
            },
            "type": "https://openssl-library.org/policies/general/security-policy/"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-416",
              "description": "CWE-416 Use After Free",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-29T15:32:24.699Z",
        "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/de97a1a54f43edefd43b5084ecac54ecadb33081"
        }
      ],
      "source": {
        "discovery": "UNKNOWN"
      },
      "title": "Use-After-Free in X.509 Extension Cache Under Concurrent Use",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "3a12439a-ef3a-4c79-92e6-6081a721f1e5",
    "assignerShortName": "openssl",
    "cveId": "CVE-2026-84783",
    "datePublished": "2026-09-29T15:32:24.699Z",
    "dateReserved": "2026-09-02T10:14:02.262Z",
    "dateUpdated": "2026-09-29T16:42:41.306Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

{
  "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\u003cbr\u003estack with NEW_CONNECTION_ID frames by avoiding a limit check on\u003cbr\u003ehow many connection IDs the remote QUIC stack can use.\u003cbr\u003e\u003cbr\u003eImpact summary: The local QUIC stack sends a RETIRE_CONN_ID frame\u003cbr\u003efor every NEW_CONNECTION_ID frame it receives. The RETIRE_CONN_ID\u003cbr\u003eframe is dispatched via the Control Frame Queue (CFQ). If the remote\u003cbr\u003epeer also withholds ACKs, then it can force the local stack\u003cbr\u003eto allocate ~400MB (depending on ACK delay).\u003cbr\u003e\u003cbr\u003eCWE: CWE-770: Allocation of Resources Without Limits or Throttling\u003cbr\u003e\u003cbr\u003eDescription: RFC 9000 sections 5.1.1 and 5.1.2 [1] describe the mechanism\u003cbr\u003eby which a remote peer can notify the local QUIC stack to change the\u003cbr\u003edestination connection ID (a.k.a. CID) the local stack uses to\u003cbr\u003eidentify the connection at the remote peer. Each CID is associated\u003cbr\u003ewith a sequence number. The sequence number is transmitted\u003cbr\u003ein NEW_CONNECTION_ID and RETIRE_CONNECTION_ID frames to identify the CID\u003cbr\u003ewhich is being either associated with a connection or retired.\u003cbr\u003e\u003cbr\u003eThe remote peer sends a NEW_CONNECTION_ID frame to let the local stack know\u003cbr\u003ea new CID is being associated with an existing connection. The\u003cbr\u003eNEW_CONNECTION_ID frame carries the new CID, its sequence number, and the\u003cbr\u003eretire-prior-to number. The retire-prior-to identifies existing\u003cbr\u003eCIDs that are to be retired. The local QUIC stack must send a\u003cbr\u003eRETIRE_CONNECTION_ID for every destination CID whose sequence number\u003cbr\u003eis less than retire-prior-to. The CID becomes retired after the\u003cbr\u003elocal stack receives an ACK for its RETIRE_CONNECTION_ID frame.\u003cbr\u003e\u003cbr\u003eAlthough the OpenSSL QUIC stack supports at most one destination CID\u003cbr\u003efor every connection, it can be tricked into processing more than\u003cbr\u003eone RETIRE_CONNECTION_ID frame per connection. The OpenSSL QUIC\u003cbr\u003estack currently retires the destination CID as soon as it receives\u003cbr\u003ethe NEW_CONNECTION_ID, while in fact the destination CID must\u003cbr\u003ebe retired after an ACK for the RETIRE_CONNECTION_ID frame is received.\u003cbr\u003eCorrecting the flawed logic also fixes the backlog growth.\u003cbr\u003e\u003cbr\u003e[1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids\u003cbr\u003e\u003cbr\u003eFIPS impact: no\u003cbr\u003eThe FIPS module is not affected as the QUIC implementation is outside of\u003cbr\u003ethe 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"
}