CVE-2026-75806: DTLS 1.2 AEAD Cipher Suite DoS Vulnerability

CVE-2026-75806 Overview

CVE-2026-75806 is a denial of service vulnerability in OpenSSL affecting DTLS 1.2 associations that use AEAD cipher suites. The record layer passes the record length to the cipher implementation before verifying that the record is long enough to contain the mandatory explicit initialization vector (IV) and authentication tag. When a record is shorter than this overhead, the cipher rejects the length and the record layer raises a fatal internal_error alert rather than treating the record as an authentication failure. An unauthenticated attacker who can send a single crafted datagram to an existing DTLS 1.2 association can terminate that association without any key material. The issue is tracked under CWE-1284: Improper Validation of Specified Quantity in Input.

Critical Impact
A single unauthenticated UDP datagram can tear down an established DTLS 1.2 session protected by an AEAD cipher suite, causing service disruption for the targeted association.

Affected Products

OpenSSL (versions supporting DTLS 1.2 with AEAD cipher suites)
Applications and appliances embedding vulnerable OpenSSL builds for DTLS transport
TLS 1.2 stacks based on OpenSSL exhibit a related protocol conformance issue (incorrect alert code)

Discovery Timeline

2026-09-29 - CVE-2026-75806 published to the National Vulnerability Database
2026-09-29 - OpenSSL Security Advisory released with fix commits
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-75806

Vulnerability Analysis

In TLS 1.2 and DTLS 1.2, every record protected by an AEAD cipher suite carries an explicit IV followed by ciphertext and an authentication tag. The OpenSSL record layer previously invoked the cipher with the full record length without first checking that the length was at least eivlen + taglen. The cipher implementation rejected the impossible length as an internal failure, and the record layer escalated this to a fatal internal_error alert.

In DTLS 1.2 the protocol expects malformed or unauthenticatable records to be silently discarded. Raising a fatal alert instead terminates the association, so any attacker able to route a datagram to the peer can end the session. In TLS 1.2 the same code path produces an internal_error alert where bad_record_mac would be expected. Because TLS already terminates on undecryptable records, the TLS case is a protocol conformance defect rather than a security issue.

Root Cause

The root cause is missing input validation in ssl/record/methods/tls1_meth.c. The record layer did not enforce the minimum AEAD record size before dispatching decryption. The fix validates reclen[ctr] >= rl->eivlen + rl->taglen and returns early on undersized records, letting the caller handle alerting per protocol rules.

Attack Vector

The attack is network-based, requires no authentication, and requires no user interaction. An attacker who can inject a UDP datagram routable to the targeted DTLS 1.2 endpoint (for example, an off-path attacker on a shared network or an on-path attacker) sends a single record shorter than the AEAD explicit IV plus tag length. The receiver raises a fatal alert and tears down the DTLS association. There is no memory safety, confidentiality, or integrity impact, and the fix is outside the FIPS module boundary.

            != 0) {
            unsigned char *seq;

+           /*
+            * Publicly invalid: the record is shorter than the mandatory
+            * AEAD overhead. Leave alert handling to the caller so TLS
+            * reports bad_record_mac and DTLS silently discards the record.
+            */
+           if (!sending && reclen[ctr] < rl->eivlen + rl->taglen)
+               return 0;
+
            seq = rl->sequence;

            if (rl->isdtls) {

Source: OpenSSL commit 04728a2

Detection Methods for CVE-2026-75806

Indicators of Compromise

Unexpected fatal internal_error alerts (alert code 80) generated by DTLS 1.2 or TLS 1.2 endpoints for AEAD cipher suites.
DTLS 1.2 associations terminating shortly after receipt of small inbound UDP datagrams that do not match legitimate peer traffic patterns.
Bursts of undersized DTLS record datagrams (payload smaller than the negotiated explicit IV length plus AEAD tag length) directed at exposed services.

Detection Strategies

Enable verbose OpenSSL record-layer logging on affected services and alert on internal_error alerts tied to AEAD decryption paths.
Inspect DTLS traffic with network sensors that decode record headers and flag records whose declared length is below the AEAD overhead threshold.
Correlate abrupt DTLS session terminations with source IPs, ports, and packet sizes to identify targeted denial of service activity.

Monitoring Recommendations

Track OpenSSL version and build information across servers, VPN concentrators, WebRTC gateways, and IoT devices to identify unpatched DTLS endpoints.
Monitor availability metrics for DTLS-dependent services such as VoIP, WebRTC media, and IPsec/DTLS VPN tunnels for unexplained session churn.
Feed record-layer telemetry and network flow data into a centralized analytics platform to baseline normal DTLS behavior and detect anomalies.

How to Mitigate CVE-2026-75806

Immediate Actions Required

Inventory all systems and appliances that link against OpenSSL and terminate DTLS 1.2 traffic, prioritizing internet-exposed services.
Apply the OpenSSL security update referenced in the OpenSSL Security Advisory of 2026-09-29 as soon as vendor packages are available.
Restart services after upgrading to ensure long-lived processes load the patched libcrypto and libssl.

Patch Information

The fix adds a length check in ssl/record/methods/tls1_meth.c that rejects records smaller than eivlen + taglen before AEAD processing. Patched commits include 04728a2, 050b275, 3a4589d, and 5af82fe. Consult downstream vendor advisories for backported package versions.

Workarounds

Restrict inbound UDP access to DTLS listeners using firewall rules that limit source addresses to known peers.
Where operationally feasible, prefer TLS over TCP transports until DTLS endpoints are patched, since TCP-based TLS is unaffected by the DoS behavior.
Deploy rate limiting and anti-spoofing controls (BCP 38 style ingress filtering) at network edges to reduce the ability of off-path attackers to inject datagrams into active associations.

bash

# Verify installed OpenSSL version after patching
openssl version -a

# Example: restrict DTLS UDP port to trusted peer subnet (Linux nftables)
nft add rule inet filter input udp dport 443 ip saddr != 203.0.113.0/24 drop