OpenSSL's DTLS leak is scored 8.2 by CISA and 7.4 by Red Hat, and the gap is what OpenSSL did not say

8.2 from CISA, 7.4 from Red Hat, and no score from OpenSSL

At 10:35 UTC (11:35 BST) on 30 September 2026, the only CVSS score on the NVD and CVE.org records for CVE-2026-84782, the DTLS flaw OpenSSL fixed on 29 September, is 8.2. OpenSSL did not assign it. The advisory says only "Severity: High", and OpenSSL's security policy says the project does not use CVSS. The 8.2 is a CVSS 3.1 score that CISA, acting as an authorised data publisher (CISA-ADP), attached to the CVE record; the National Vulnerability Database (NVD) lists it as a secondary score. Red Hat scored the same flaw 7.4.

The two vectors agree on six of the eight base metrics. They split on attack complexity (CISA Low, Red Hat High) and on confidentiality impact (CISA Low, Red Hat High). Those are the two things the advisory leaves open: whether anyone can bring about the conditions the bug needs, and what the leaked memory contains. Neither party explains those two metric choices, so what follows about why is inference. The CVSS 3.1 specification defines High complexity as depending on "conditions beyond the attacker's control", which is one way to read a bug that needs a write to be paused at the moment a timer fires. CISA's own SSVC entry for the same record says automatable yes, and its SSVC guide frames that decision point as "Can an attacker reliably automate, creating exploitation events for this vulnerability?" Red Hat's High complexity pulls the other way, and the advisory settles neither.

I recomputed both scores from the specification's formula and reproduced 8.2 and 7.4 exactly. Changing one metric at a time shows how much rides on each unknown. Setting complexity to High alone gives 6.5. Setting confidentiality to High alone gives 9.1, which is in the Critical band (9.0 to 10.0). The published gap of 0.8 is two large disagreements cancelling out (derived).

Who has said what about CVE-2026-84782, read from the primary records between 10:27 and 10:35 UTC on 30 September 2026. Several of these can change today.

Party	Stated	Not stated
OpenSSL (advisory and CVE record)	Severity High. No CVSS: its policy says it does not use CVSS and that outside scores can differ greatly.	Why High and not Critical. Leak size. Whether a peer can trigger it.
CISA-ADP (shown in NVD as secondary)	CVSS 3.1 score 8.2, vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H. SSVC at 16:45 UTC on 29 September: exploitation none, automatable yes, technical impact partial.	Why complexity and confidentiality are Low. Anything after that timestamp.
Red Hat (Amazon Linux shows the same vector)	CVSS 3.1 score 7.4, vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:H, rated Important. Says exposure is DTLS over UDP under non-blocking I/O, and TLS over TCP is unaffected.	Why complexity and confidentiality are High. The non-blocking condition is Red Hat's wording, not the advisory's.
NVD	Status Awaiting Analysis, last modified 21:27 UTC on 29 September. No score of its own.	Any NVD assessment. Any CVSS 4.0 score, here or in the CVE, Red Hat or Amazon Linux records I read.

The labels agree far better than the numbers. OpenSSL says High. CISA's 8.2 and Red Hat's 7.4 both sit in CVSS's High band (7.0 to 8.9), Red Hat and Amazon Linux call the flaw Important, and Ubuntu's priority is High. Five labels in all, and none says what leaves the process. OpenSSL's policy says High covers issues of lower risk than Critical, "perhaps due to affecting less common configurations"; the advisory does not say why it chose High here. Ubuntu's own notice, USN-8847-1, summarises the flaw as "incorrect handshake behavior or a denial of service" and does not mention memory disclosure at all. A label is a summary of someone's assumptions, and here the assumptions are exactly what is missing. This site has traced the pattern before: seventeen flaws with two official scores each, and an advisory that carried a word but no score.

What OpenSSL says the flaw is

DTLS is TLS for datagrams. With no reliable transport underneath, it resends handshake messages itself when a timer expires; RFC 6347 calls this "a simple retransmission timer". A large handshake message is split into fragments, and a write can pause part-way if the transport cannot take more data at that moment. OpenSSL's advisory says that if the retransmission timer fires while such a write is paused, the library resends an earlier message using the paused write's buffer and position instead of going back to the start of the message being resent. The result is a mislabelled message whose body is leftover bytes from the larger message, and the read can run past the end of the buffer. Depending on what lies beyond it, OpenSSL says the peer receives heap memory as plaintext handshake data, or the process crashes. A second defect overwrites the bookkeeping the paused write needs to resume, and OpenSSL says the resumed write then aborts in a debugging build.

Read what is missing. The advisory does not say whether a peer can make a write pause, or time its way into the overlap. It gives no amount either: the only bound is that the read "could run past the end of the allocated buffer", so no per-message leak size can be computed from the record. The fix commit message says the body is "typically leftover content from the other, larger message", which describes the common case, not a limit. Note also what the advisory does not describe: a duplicate message sent by the peer. The resend is the library's own.

The fix is small. Across the four commits the library change is four lines of logic under long comments: one resets the read position to zero before a resend, and a three-line guard skips the retransmission while a write is parked. A further 414 added lines are tests, which the commit message says cover a client and a server on DTLS 1.2. It does not say whether other DTLS versions were tested, and neither does the advisory.

Which versions get a fix, and for how long

OpenSSL's wording is: "OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue." The table sets the fixed releases beside the support dates on OpenSSL's release strategy page, read on 30 September.

Fixed versions as the advisory words them, with support end dates from OpenSSL's release strategy page and its 16 September end-of-life post.

Branch	Fix, per the advisory	Who can get it, and support end
4.0	4.0.3	Public. Supported until 14 May 2027.
3.6	3.6.5	Public. Supported until 1 November 2026.
3.5 (LTS)	3.5.9	Public. Supported until 8 April 2030.
3.4	3.4.8	Public. Supported until 22 October 2026.
3.0	3.0.23	Premium support customers only. End of life 7 September 2026.
1.1.1	1.1.1zj	Premium support customers only. No longer supported.
1.0.2	1.0.2zs	Premium support customers only. No longer supported.
3.1, 3.2, 3.3	None listed	Out of support, and "have not been analysed".

Three points follow. First, arithmetic: on the day of the advisory, 3.4 had 23 days of public support left and 3.6 had 33 (derived). The fix gives those branches weeks, not a plan. Second, 3.0, the long-term-support branch that Ubuntu 22.04 and 24.04 and Debian 12 still package according to their trackers, left public support on 7 September, 22 days before the advisory, according to OpenSSL's own end-of-life post. Its fix, 3.0.23, goes to customers with a support contract. OpenSSL Corporation sells that support, and the project says it intends to provide it "as long as it remains commercially viable". That is a business stated openly, and a security decision for whoever is buying. Third, silence: OpenSSL says 3.1, 3.2 and 3.3 "have not been analysed". That is not a clean bill. Ubuntu's tracker lists a fixed package even for OpenSSL 1.0.1f, a branch the advisory does not name, which is consistent with the flawed code being old (inference). For a related case where the branch people actually ran got nothing, see the fix that was only a beta.

Two more comfortable labels. LTS: the 3.0 label promised five years, and the five years ended on 7 September. FIPS: the advisory says "FIPS impact: no" because the affected code is outside the FIPS module boundary. That means the module itself needs no fix. It does not follow that a deployment running the FIPS provider avoids the bug, because the DTLS code sits in the surrounding library (inference from the advisory's own sentence). OpenSSL's 16 September post adds that the remaining 3.0 FIPS 140-2 certificates move to the CMVP Historical List on 21 September 2026, so a team held on 3.0 by FIPS needs a plan, not just a patch.

43 days, and what the record says about them

Dates from the OpenSSL advisory, the CVE record, the fix commit and the release pages. Times are UTC unless stated.

When	What happened	Source
17 August 2026	Reported to OpenSSL by Laurent Gaffie (Secorizon).	Advisory
2 September, 10:14	CVE ID reserved.	CVE record
2 September, 15:15 (UTC-4)	Fix commit authored by Ryan Hooper.	Commit header
29 September, 11:18 to 11:19	Four fix commits merged. The trailer gives no time zone.	Commit trailers
29 September, 13:53 to 14:19	Releases 4.0.3, 3.6.5, 3.5.9 and 3.4.8 published on GitHub.	Release pages
29 September, 14:21	Advisory public (CVE date public).	CVE record
29 September, 15:32 to 16:45	CVE published (15:32), NVD entry (16:17), CISA-ADP score and SSVC (16:45).	CVE, NVD, CISA-ADP

From report to advisory is 43 days. From report to the fix being written is 16, and from the fix being written to publication is 27 (all derived). OpenSSL's security policy says High issues should be private for "no longer than a month where this is something under our control", so 43 days is 13 days past that aim. The advisory does not say why. It fixed 14 CVEs together, and one of the other reports arrived as late as 23 September, so a release schedule may explain the timing (inference).

The same policy says OpenSSL usually gives operating-system vendors and some commercial partners patches about two weeks before release. Whether it did that here is not stated. What the trackers show is uneven: Ubuntu shipped fixed packages on the day, Debian 12 was still listed as vulnerable at 10:30 UTC the next morning, and Amazon Linux listed the fix as pending. A supplier outside those arrangements starts from the public release.

One provenance detail. The fix commit ends with a trailer, spelled "Assited-by", crediting "Claude:claude-sonnet-5". OpenSSL's AI contribution policy requires an "Assisted-by" trailer on non-trivial AI-assisted commits and says a human must review the output and be accountable for it; the commit also lists two named reviewers. The trailer does not say what the model did. The advisory credits Laurent Gaffie with the report and Ryan Hooper with the fix. Secorizon sells offensive-security services and lists this finding on its advisories page.

Where DTLS is used, and what that does and does not tell you

The advisory names no product. Standards and project documentation show where DTLS is normal. RFC 8827 says WebRTC performs a DTLS handshake to key media and to carry data channels. RFC 7252 defines a DTLS-secured mode for CoAP, the constrained-device protocol. RFC 7350 covers STUN and TURN over DTLS, and the coturn README says its DTLS listeners do not start unless --dtls is given and that TLS and DTLS support need OpenSSL 3.0 or newer. VPN clients use it too: the OpenConnect manual says AnyConnect uses DTLS for its UDP tunnel, while Juniper and GlobalProtect use UDP-encapsulated ESP. "It runs over UDP" is therefore not the test.

What does not follow. TLS over TCP is not affected, per Red Hat's statement. This is a DTLS issue; the advisory's five QUIC issues are separate CVEs, all rated Low. And a package that contains OpenSSL is not a package that speaks DTLS. Red Hat's record, read at 10:35 UTC, has 293 package entries across 38 products, 287 of them marked Affected, including 28 for RHEL 10 and 112 for OpenStack Platform 16.2. Affected there means the code is present. Whether a process terminates or starts DTLS is a separate question that only its owner can answer. The advisory says "the peer", and the commit's tests cover a client and a server, so do not assume that only servers matter.

Finding OpenSSL inside products and containers

OpenSSL's security policy says many affected sites run a copy from a vendor, and that "The most effective way" to be protected is to get an updated version from that vendor. That is the first place to look, and it fails in two ways.

Version numbers mislead in both directions. Ubuntu's fixed packages read 3.0.2-0ubuntu1.30 on 22.04, 3.0.13-0ubuntu3.16 on 24.04 and 3.5.5-1ubuntu3.6 on 26.04. Each looks older than the upstream fix and each is fixed, according to Ubuntu's tracker. Red Hat warns that scanners that only compare versions can report backported packages as vulnerable. In the other direction, bundled copies do not move with the operating system: Ubuntu's security team notes that edk2 embeds OpenSSL 1.1.1j, 3.0.9 or 3.5.1 depending on the release, and that nodejs on 22.04 embeds 1.1.1m. It marks nodejs on 22.04 Vulnerable and edk2 Needs evaluation.

# Distribution packages. Fixed builds keep older version numbers, so read the changelog.
dpkg -l 'libssl*' openssl
rpm -qa 'openssl*'

# Processes that have OpenSSL mapped right now (Linux).
grep -l -E 'libssl|libcrypto' /proc/[0-9]*/maps 2>/dev/null

# A bundled or static copy often carries its version string. No hit does not prove no OpenSSL.
strings -a /path/to/binary | grep -E 'OpenSSL [0-9]+\.[0-9]+\.[0-9]+'

# Runtimes that ship their own copy.
node -p process.versions.openssl
python3 -c 'import ssl; print(ssl.OPENSSL_VERSION)'

For container images, run the package query inside each image, or generate a software bill of materials for it and search for openssl, libssl and libcrypto. Then check the base image's distribution tracker rather than comparing version numbers. At 10:30 UTC on 30 September, Debian's tracker listed trixie (security) 3.5.7-1~deb13u3 as fixed and bookworm (security) 3.0.22-1~deb12u1 as vulnerable, and Amazon Linux's page listed openssl as Pending Fix on Amazon Linux 2, 2023 and 2027 Preview. Both can change within hours.

The order worth doing

The question this leaves

Two parties read the same advisory and disagreed on how hard the flaw is to trigger and what it reveals. The party best placed to close that gap is the one that wrote the advisory, and it has not. Until it does, a score is one party's assumption, and the useful facts are the ones you can check on your own estate. So: for each DTLS service you run, who can name the OpenSSL build behind it, and who is obliged to patch it?