CVE-2026-84782 · Issue summary: The DTLS retransmission logic does not correctly han…

01 · The Real Story

Heartbleed's smaller, clumsier cousin—it can only swing at the DTLS door, and it doesn't get to pick what falls out

CVE-2026-84782 is an out-of-bounds read in OpenSSL's DTLS handshake retransmission logic. When a DTLS handshake write is suspended mid-message because the underlying UDP transport cannot accept more data (WANT_WRITE), the retransmission timer can fire and resend a previously queued message starting from a stale buffer offset. This causes OpenSSL to read past the handshake message boundary, leaking adjacent heap memory as plaintext handshake data to the remote peer—or crashing the process when the read walks into unmapped memory. Every maintained OpenSSL branch is affected: 4.0.x, 3.6.x, 3.5.x, 3.4.x, and the premium-support branches 3.0.x, 1.1.1, and 1.0.2. The OpenSSL FIPS module is not affected because the vulnerable code sits outside its boundary.

The vendor's HIGH / 8.2 score is technically correct *for a DTLS endpoint*—the CVSS vector (AV:N/AC:L/PR:N/UI:N) reflects that any unauthenticated network peer can trigger it with no user interaction. But this score ignores the most important real-world filter: DTLS is a niche protocol. The overwhelming majority of OpenSSL deployments serve HTTPS, SMTPS, IMAPS, and other TCP-based TLS traffic that is completely unaffected. DTLS exposure is concentrated in VPN gateways (Cisco AnyConnect, OpenConnect, Citrix), WebRTC SFU/MCU servers, CoAP IoT endpoints, and a handful of real-time communications stacks. Additionally, the trigger requires a specific race between a suspended write and the retransmission timer—a condition the CVSS AC:L rating glosses over. We downgrade to MEDIUM 6.5 because the exposed population is a small fraction of the installed base and the impact caps at DoS plus uncontrolled heap disclosure (not RCE).

"DTLS-only scope shrinks the blast radius; most OpenSSL installs are unaffected"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a DTLS endpoint

The attacker scans for services accepting DTLS connections on UDP ports. Common targets include VPN concentrators (UDP/443, UDP/8443), WebRTC media servers (UDP/10000-60000), and CoAP endpoints (UDP/5684). Shodan or Censys ssl.version:dtls queries surface these hosts. The attacker needs only network reachability to the UDP port.

Conditions required:

Target runs OpenSSL with DTLS enabled
UDP port is reachable from attacker's network position

Where this breaks in practice:

Most OpenSSL deployments use TLS over TCP—DTLS endpoints are a small minority
Enterprise VPN gateways often sit behind DDoS scrubbers or are restricted to corporate IP ranges
WebRTC endpoints typically require a prior signaling session (STUN/TURN allocation) before DTLS handshake

Detection/coverage: Shodan (ssl.version:dtls), Censys, or internal asset inventory filtered on UDP-listening OpenSSL services

STEP 02

Initiate DTLS handshake under load

The attacker begins a standard DTLS ClientHello exchange with the target server. To trigger the vulnerable code path, the server's outbound transport must become congested enough to suspend a handshake write mid-message (returning WANT_WRITE). The attacker can assist this by flooding the server with concurrent DTLS handshakes or by exploiting a naturally loaded link, creating backpressure on the server's UDP send path.

Conditions required:

Server's transport layer must become congested enough to suspend a write
Retransmission timer must fire while the write is still suspended

Where this breaks in practice:

Requires a race condition between transport congestion and the retransmission timer—not deterministic
Modern kernel UDP buffers are large; triggering WANT_WRITE on a healthy server takes significant concurrent load
Rate-limiting on the DTLS listener reduces the attacker's ability to create the required backpressure

Detection/coverage: IDS rules for anomalous DTLS handshake volume (e.g., Suricata dtls.handshake_type threshold rules)

STEP 03

Receive leaked heap data or trigger crash

When the race condition succeeds, the server retransmits a handshake message starting from the wrong buffer offset. The attacker receives plaintext data that extends past the original message boundary—this is adjacent heap memory content. The leaked data is uncontrolled: it could contain session keys, partial certificate data, other clients' handshake fragments, or unrelated heap allocations. Alternatively, if the stale offset points into unmapped memory, the server process crashes (DoS).

Conditions required:

Race condition from step 2 succeeded
Heap layout places interesting data adjacent to the handshake buffer (for info disclosure)

Where this breaks in practice:

Attacker cannot choose what leaks—unlike Heartbleed, there is no length control
Each successful trigger leaks only a small window of adjacent heap—repeated attempts needed for meaningful exfiltration
Crash outcome is more common than useful info disclosure, destroying the connection and resetting heap state

Detection/coverage: Crash monitoring (core dumps, process restarts); anomalous DTLS retransmission patterns in packet captures

STEP 04

Exploit leaked material or sustain DoS

If the attacker recovers usable keying material (session keys, pre-master secrets), they can attempt to decrypt captured DTLS sessions (requires prior passive capture). More commonly, the attacker sustains repeated crashes to deny service—particularly impactful against VPN concentrators serving thousands of remote workers. No code execution is achieved; the impact ceiling is information disclosure plus denial of service.

Conditions required:

For info disclosure: leaked data must contain actionable secrets
For DoS: attacker must sustain the crash cycle against process restart logic

Where this breaks in practice:

TLS 1.3 / DTLS 1.3 forward secrecy limits value of leaked session keys
VPN appliances typically auto-restart crashed processes within seconds
Sustained DoS requires continuous attack traffic, which is visible to network monitoring

Detection/coverage: SIEM correlation on repeated OpenSSL process restarts; NetFlow/GreyNoise anomaly detection on DTLS traffic spikes

03 · Compensating Control

MEDIUM 6.5→IGNORE 0.0

SEVERITY REDUCED

Disable DTLS if not operationally required — Most OpenSSL-based services only need TLS over TCP. If your application does not use DTLS, compile OpenSSL with no-dtls or configure the application to reject DTLS connections. This completely eliminates the attack surface. Audit within the noisgate 365-day remediation window for MEDIUM severity, but prioritize this quick win immediately if feasible.

MEDIUM 6.5→LOW 4.0

SEVERITY REDUCED

Rate-limit inbound DTLS handshakes at the network edge — The trigger requires transport congestion during handshake writes. Rate-limiting new DTLS ClientHello messages at the firewall or load balancer (e.g., iptables hashlimit on UDP/443, F5 DTLS rate class) reduces the attacker's ability to create the backpressure needed to trigger WANT_WRITE. Apply within the MEDIUM remediation window. This degrades but does not eliminate the attack path.

MEDIUM 6.5→IGNORE 0.0

SEVERITY REDUCED

Patch OpenSSL to fixed version — Upgrade to 4.0.3, 3.6.5, 3.5.9, or 3.4.8 on community branches; 3.0.23, 1.1.1zj, or 1.0.2zs on premium support. This is the definitive fix. Per the noisgate remediation SLA for MEDIUM, deploy within 365 days. However, if your environment exposes DTLS on VPN concentrators, treat those specific hosts at an elevated priority (target 90 days).

MEDIUM 6.5→MEDIUM 5.5

Enable crash monitoring and auto-restart for DTLS services — Configure process supervisors (systemd Restart=always, Kubernetes liveness probes, appliance HA failover) to immediately restart crashed DTLS processes. This limits the DoS window to seconds per crash. Pair with SIEM alerting on repeated restarts to detect active exploitation attempts. Operational resilience measure—does not prevent the heap leak.

What doesn't work

TLS cipher suite hardening — this is a DTLS handshake-layer bug in retransmission logic, not a cipher or protocol negotiation flaw. Changing cipher suites has no effect.
Certificate pinning or mutual TLS — the vulnerability triggers during the handshake itself, before client authentication completes. mTLS does not prevent the attacker from initiating the handshake.
WAF rules — DTLS is UDP-based and encrypted; HTTP-layer WAFs do not inspect DTLS traffic. Even network IPS has limited visibility into DTLS handshake internals to detect the stale-offset condition.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None confirmed. Not listed in CISA KEV. No GreyNoise tags or observed scanning campaigns as of 2026-09-30. OpenSSL advisory states no known exploitation.
Proof-of-concept	No public PoC. Checked pocindex.io, GitHub (`CVE-2026-84782`), ExploitDB, and nuclei templates—no exploit code published. Laurent Gaffie (Secorizon) reported the bug on 2026-08-17 but has not released PoC code.
EPSS	Not yet scored. CVE was disclosed 2026-09-29; FIRST EPSS model has not yet computed a probability. Expect initial score within 7-14 days.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H` → 8.2 HIGH. Network-reachable, no auth, no interaction. Confidentiality is Low (uncontrolled heap leak, not arbitrary read). Availability is High (process crash). No integrity impact.
Affected versions	OpenSSL 4.0.0–4.0.2, 3.6.0–3.6.4, 3.5.0–3.5.8, 3.4.0–3.4.7, 3.0.0–3.0.22, 1.1.1–1.1.1zi, 1.0.2–1.0.2zr. All branches with DTLS support.
Fixed versions	4.0.3, 3.6.5, 3.5.9, 3.4.8 (community). Premium support: 3.0.23, 1.1.1zj, 1.0.2zs. FIPS module is not affected.
Exposure surface	DTLS is niche vs. TLS. Primary exposed services: VPN concentrators (Cisco AnyConnect DTLS on UDP/443), WebRTC SFU/MCU servers, CoAP/LwM2M IoT gateways. Shodan `ssl.version:dtls` shows a fraction of the TLS-exposed population.
Disclosure timeline	Reported 2026-08-17 by Laurent Gaffie (Secorizon). Fix developed by Ryan Hooper. Coordinated disclosure 2026-09-29 alongside 13 other OpenSSL CVEs.
Reporter	Laurent Gaffie of Secorizon. Known for protocol-level vulnerability research (Responder toolkit author, prior OpenSSL and Windows authentication research).
Advisory context	Part of a 14-CVE batch (4 High, 3 Medium, 3 Low, 4 Unrated). CVE-2026-84783 (use-after-free in X.509 extension cache, CVSS 7.5, OpenSSL 4.0 only) is the other notable HIGH in the same advisory.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (6.5/10)

Why this verdict

DTLS-only scope eliminates >90% of the target population. The vast majority of OpenSSL installations serve TLS over TCP (HTTPS, SMTPS, LDAPS, database TLS). DTLS is limited to VPN gateways, WebRTC servers, and IoT CoAP endpoints. The vendor's 8.2 scores the bug as if every OpenSSL instance is exposed—in reality, most are not.
Race condition adds real friction not captured by AC:L. Exploitation requires the server's UDP send path to be congested enough to suspend a write (WANT_WRITE) while the retransmission timer simultaneously fires. This is not deterministic and requires significant concurrent load or favorable network conditions.
No PoC, no exploitation, no KEV. Disclosed 24 hours ago with no public exploit code, no observed scanning, and no CISA KEV listing. Laurent Gaffie has not released weaponized tooling. The theoretical attack requires protocol-level DTLS expertise to implement.
Impact ceiling is DoS + uncontrolled heap leak, not RCE. The attacker cannot execute code, escalate privileges, or pivot laterally. Information disclosure is limited to whatever happens to sit adjacent to the handshake buffer in heap memory—the attacker has no Heartbleed-style length control.
Role multiplier: VPN gateways (high-value network edge). VPN concentrators using DTLS (Cisco AnyConnect, OpenConnect, Citrix) are legitimate high-value targets. Chain succeeds on these endpoints. Blast radius: service-level DoS (loss of remote access) + potential session key leak from heap. However, this is not domain takeover, fleet compromise, or supply-chain pivot—the HIGH floor requires catastrophic outcomes, and DoS + limited C:L disclosure falls short. Forward secrecy in DTLS 1.2/1.3 further limits the value of any leaked keying material.
Role multiplier: WebRTC SFU servers (typical role). WebRTC servers use DTLS-SRTP. Chain succeeds but requires signaling access first (ICE candidates). Blast radius: single-server DoS, potential leak of SRTP keys for active sessions. Not fleet-scale.
Role multiplier: IoT CoAP/LwM2M gateways (mixed role). Some OT/ICS deployments use DTLS for device management. Chain succeeds if gateway is reachable. Blast radius: device management disruption, not safety-critical unless the gateway is a single point of failure. Insufficient evidence that ≥1% of the installed base is in this configuration to trigger the OT floor.

Why not higher?

The DTLS-only scope is the decisive factor. If this bug affected TLS broadly (like Heartbleed did), the vendor's HIGH 8.2 or even CRITICAL would be warranted given OpenSSL's ubiquity. But DTLS is a niche protocol; most enterprises have zero or single-digit DTLS endpoints. The impact ceiling of DoS + uncontrolled heap leak—with no path to code execution—does not meet the catastrophic outcome threshold (domain takeover, fleet compromise, supply-chain pivot) required to floor the verdict at HIGH despite friction.

Why not lower?

The vulnerability IS remotely exploitable with no authentication on affected DTLS endpoints. VPN gateways are real high-value targets, and sustained DoS against a VPN concentrator serving thousands of remote workers has genuine operational impact. The heap disclosure, while uncontrolled, could in theory leak session secrets. Laurent Gaffie is a skilled researcher with a track record of protocol-level exploitation—a weaponized PoC could shift this upward. Dropping below MEDIUM would understate the risk to the minority of deployments that do expose DTLS.

06 · Verification

Crowdsourced verification payload.

Run this script on each host that may serve DTLS connections (VPN gateways, WebRTC servers, IoT gateways). Execute as any user with read access to the OpenSSL binary. Example: bash check_cve_2026_84782.sh or bash check_cve_2026_84782.sh /usr/local/ssl/bin/openssl to specify a custom OpenSSL path. No elevated privileges required.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_84782.sh — Detect CVE-2026-84782 (OpenSSL DTLS OOB read)
# Usage: bash check_cve_2026_84782.sh [/path/to/openssl]
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

OPENSSL_BIN="${1:-openssl}"

if ! command -v "$OPENSSL_BIN" &>/dev/null; then
  echo "UNKNOWN — cannot find openssl binary at '$OPENSSL_BIN'"
  exit 2
fi

VERSION_STR=$("$OPENSSL_BIN" version 2>/dev/null) || { echo "UNKNOWN — failed to run openssl version"; exit 2; }
echo "Detected: $VERSION_STR"

# Extract version number (e.g., 3.6.4, 4.0.2, 1.1.1zi)
VER=$(echo "$VERSION_STR" | grep -oP 'OpenSSL\s+\K[0-9]+\.[0-9]+\.[0-9]+[a-z]*')
if [[ -z "$VER" ]]; then
  echo "UNKNOWN — could not parse version from: $VERSION_STR"
  exit 2
fi

# Split into major.minor.patch
MAJOR=$(echo "$VER" | cut -d. -f1)
MINOR=$(echo "$VER" | cut -d. -f2)
PATCH_RAW=$(echo "$VER" | cut -d. -f3)
PATCH_NUM=$(echo "$PATCH_RAW" | grep -oP '^[0-9]+')
PATCH_SUFFIX=$(echo "$PATCH_RAW" | grep -oP '[a-z]+$' || true)

VULN=0

check_branch() {
  local req_major=$1 req_minor=$2 req_patch=$3
  if (( MAJOR == req_major && MINOR == req_minor )); then
    if (( PATCH_NUM < req_patch )); then
      VULN=1
    fi
    return 0
  fi
  return 1
}

# 4.0.x — fixed in 4.0.3
check_branch 4 0 3 || \
# 3.6.x — fixed in 3.6.5
check_branch 3 6 5 || \
# 3.5.x — fixed in 3.5.9
check_branch 3 5 9 || \
# 3.4.x — fixed in 3.4.8
check_branch 3 4 8 || \
# 3.0.x — fixed in 3.0.23
check_branch 3 0 23 || \
# 1.1.1 — fixed in 1.1.1zj (letter-suffix comparison)
if (( MAJOR == 1 && MINOR == 1 )); then
  # 1.1.1xx where suffix < zj is vulnerable
  if [[ "$PATCH_NUM" == "1" ]]; then
    if [[ -z "$PATCH_SUFFIX" || "$PATCH_SUFFIX" < "zj" ]]; then
      VULN=1
    fi
  fi
# 1.0.2 — fixed in 1.0.2zs
elif (( MAJOR == 1 && MINOR == 0 )); then
  if [[ "$PATCH_NUM" == "2" ]]; then
    if [[ -z "$PATCH_SUFFIX" || "$PATCH_SUFFIX" < "zs" ]]; then
      VULN=1
    fi
  fi
fi

# Also check: is DTLS compiled in?
DTLS_SUPPORT="unknown"
if "$OPENSSL_BIN" s_server -help 2>&1 | grep -qi dtls; then
  DTLS_SUPPORT="yes"
elif "$OPENSSL_BIN" ciphers -v 'ALL' 2>/dev/null | grep -qi dtls; then
  DTLS_SUPPORT="yes"
else
  DTLS_SUPPORT="no (DTLS may be compiled out — not exploitable)"
fi
echo "DTLS support: $DTLS_SUPPORT"

if (( VULN == 1 )); then
  echo "VULNERABLE — $VERSION_STR is affected by CVE-2026-84782"
  exit 1
else
  echo "PATCHED — $VERSION_STR is not affected by CVE-2026-84782"
  exit 0
fi

Peer Review

What defenders are saying.

Submit a review attribution: handle + country only

0 flags selected · stored anonymously