Like leaving the garden hose running in a side shed nobody visits, while the vendor screams about a burst main
CVE-2026-54874 is a memory-amplification denial-of-service in OpenSSL's DTLS handshake path. When a DTLS handshake is in progress, OpenSSL buffers incoming records destined for a future epoch. The bug is that it retains the entire ~16 KB read buffer per record instead of just the payload bytes. An unauthenticated remote peer can send many small forged records, causing the endpoint to retain roughly 1.7 MB per connection — an approximately 1,200× memory amplification factor. Affected versions span nearly every supported branch: OpenSSL 4.0.0–4.0.1, 3.6.0–3.6.3, 3.5.0–3.5.7, 3.4.0–3.4.6, 3.0.0–3.0.21, 1.1.1 before 1.1.1zi, and 1.0.2 before 1.0.2zr.
The NVD-style CVSS score of 7.5 HIGH overstates the real-world risk. OpenSSL's own advisory rates this Low severity — and they're closer to correct. The flaw is confined to DTLS, a protocol with a dramatically smaller internet footprint than TLS. Most enterprises don't expose DTLS services at all; the main consumers are VPN concentrators (e.g., Cisco AnyConnect DTLS mode), WebRTC infrastructure, and some IoT/CoAP deployments. The impact ceiling is availability loss — no code execution, no data leakage, no integrity compromise. A 1,200× amplification factor sounds scary in isolation, but 1.7 MB per connection means an attacker needs thousands of concurrent connections to exhaust even a modestly provisioned server, and connection-rate limiting or DTLS cookie verification blunts this further.
4 steps from start to impact.
Identify a DTLS endpoint
- Target must expose a DTLS service built on a vulnerable OpenSSL version
- DTLS exposure is a tiny fraction of TLS exposure — most enterprises have zero public DTLS endpoints running raw OpenSSL
- VPN appliances typically use their own DTLS implementations, not stock OpenSSL
Initiate DTLS handshake
- Network reachability to the DTLS port (UDP)
- DTLS cookie exchange (HelloVerifyRequest) may be enabled, requiring the attacker to use a real source IP — prevents spoofed-source amplification
- Rate limiting on new handshakes is common on production DTLS servers
Send many small future-epoch records
- Handshake must be in progress (achieved in step 2)
- Server must be running a vulnerable OpenSSL version
- 100-record queue limit caps per-connection amplification at ~1.7 MB
- Attacker needs thousands of concurrent connections to exhaust multi-GB server memory
- Server-side connection limits, firewall session caps, and UDP flood protections reduce throughput
Exhaust server memory for DoS
- Sustained network access to maintain thousands of concurrent UDP sessions
- Target server lacks connection-rate or memory-usage limits
- 4,700+ concurrent connections is achievable but detectable
- Most production deployments have OS-level or application-level connection caps well below this
- cgroups / container memory limits will kill the process before system-wide impact
- Cloud-based DTLS services often auto-scale
SSL_OP_COOKIE_EXCHANGE or use DTLSv1_listen(). Deploy within the noisgate MEDIUM remediation window (365 days), though sooner is better if you have public DTLS endpoints.- TLS-layer WAFs and reverse proxies — these operate on TCP/TLS and do not inspect or proxy DTLS (UDP) traffic. They provide zero protection for this vulnerability.
- Disabling TLS 1.0/1.1 — this CVE is about DTLS, not TLS. Disabling old TLS versions has no effect on DTLS handshake buffering.
- Certificate pinning or mutual TLS — the vulnerable buffering occurs before authentication completes during the handshake, so mTLS does not prevent the memory amplification.
The supporting signals.
| In-the-wild exploitation | None observed. Not listed in CISA KEV. No known campaigns targeting this flaw as of 2026-08-26. |
|---|---|
| Proof of concept | No public PoC. The vulnerability was responsibly disclosed by Amazon Web Services on 2026-05-18 and patched by Matt Caswell. Crafting a PoC is straightforward (send future-epoch DTLS records during handshake) but no repos or scripts have surfaced. |
| EPSS score | Not yet scored (CVE published 2026-08-25). Expected to be low given DoS-only impact, DTLS niche, and no PoC. |
| KEV status | Not listed. No CISA KEV entry as of 2026-08-26. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — Network-reachable, no privileges, availability-only impact. NVD scores 7.5 HIGH; OpenSSL project rates Low. |
| Affected versions | OpenSSL 4.0.0–4.0.1, 3.6.0–3.6.3, 3.5.0–3.5.7, 3.4.0–3.4.6, 3.0.0–3.0.21, 1.1.1 before 1.1.1zi, 1.0.2 before 1.0.2zr |
| Fixed versions | OpenSSL 4.0.2, 3.6.4, 3.5.8, 3.4.7, 3.0.22, 1.1.1zi, 1.0.2zr. Distro backports expected within days for RHEL, Ubuntu, Debian, SUSE. |
| Exposure data | Censys historically shows ~7,000 internet-exposed DTLS endpoints running vulnerable OpenSSL. Shodan shows <16,000 total. This is orders of magnitude smaller than TLS exposure. |
| Disclosure date | 2026-08-25 (public advisory). Reported to OpenSSL on 2026-05-18. |
| Reporter | Amazon Web Services (responsible disclosure). Fix by Matt Caswell (OpenSSL). |
Sources.
- OpenSSL Vulnerabilities Page
- OpenSSL 3.5 Series Release Notes
- CyberPress — OpenSSL Patches Nine Vulnerabilities
- CybersecurityNews — Multiple OpenSSL Flaws
- Tenable Plugin 339518 — OpenSSL 3.0.x < 3.0.22
- Canadian Centre for Cyber Security — OpenSSL Advisory AV26-058
- TheHackerWire — CVE-2026-54874 Info
- LinuxCompatible — OpenSSL 4.0.2 Patches
Why this verdict
- Protocol scope narrows exposure dramatically. DTLS is used by a small subset of OpenSSL deployments. Most enterprise TLS/HTTPS servers are unaffected. The reachable population is <1% of the total OpenSSL installed base.
- Availability-only impact with bounded amplification. The 1,200x factor sounds large but caps at ~1.7 MB per connection. Exhausting 8 GB RAM requires ~4,700 concurrent connections — detectable and throttleable. No confidentiality or integrity impact.
- OpenSSL's own severity rating is Low. The vendor who wrote the code and reviewed the bug rates this Low, not High. The NVD CVSS score mechanically reflects AV:N/PR:N/A:H but ignores practical deployment context.
- Role multiplier: For *VPN concentrators* using DTLS (Cisco AnyConnect, OpenConnect): the chain could succeed and cause VPN service outage — blast radius is service-level, not domain/fleet/data. However, most commercial VPN appliances use their own DTLS stacks, not stock OpenSSL. For *WebRTC infrastructure*: DoS of a media server is disruptive but bounded to that service. For *IoT/CoAP gateways*: DTLS DoS could disrupt sensor telemetry but doesn't enable lateral movement. No high-value role yields domain takeover, fleet compromise, or supply-chain impact — the floor rule for HIGH is not triggered.
- Multiple friction points compound. DTLS cookie verification (HelloVerifyRequest) prevents spoofed-source amplification. Connection-rate limits, firewall UDP session caps, and cgroups/container memory limits all independently reduce the blast radius.
Why not higher?
Upgrading to HIGH would require either active exploitation, a larger blast radius (RCE/data breach), or the DTLS endpoint being a canonical high-value component where DoS equates to fleet-scale impact. None of these conditions hold: no exploitation is observed, the impact is bounded availability loss, and DTLS endpoints represent a tiny sliver of the OpenSSL installed base. The vendor themselves rate this Low.
Why not lower?
Downgrading to LOW would underweight the fact that this is unauthenticated and network-reachable with no user interaction. VPN gateways and WebRTC servers *do* exist in production and a sustained DoS against them has real business impact. The 1,200x amplification factor, while bounded, is non-trivial and the fix spans every supported OpenSSL branch, indicating broad code-level exposure.
Crowdsourced verification payload.
Run this script on each host where OpenSSL is installed (or where a DTLS-serving application links against OpenSSL). It checks the installed openssl binary version against the known fixed versions. Requires no special privileges. Example: bash check_cve_2026_54874.sh
#!/usr/bin/env bash
# check_cve_2026_54874.sh — Check for CVE-2026-54874 (DTLS memory amplification)
# Run on target hosts. No privileges required.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
VERSION_STR=$(openssl version 2>/dev/null || true)
if [ -z "$VERSION_STR" ]; then
echo "UNKNOWN — openssl binary not found in PATH"
exit 2
fi
# Extract version number, e.g. "4.0.1" from "OpenSSL 4.0.1 ..."
VER=$(echo "$VERSION_STR" | grep -oP '\d+\.\d+\.\d+[a-z]*' | head -1)
if [ -z "$VER" ]; then
echo "UNKNOWN — could not parse version from: $VERSION_STR"
exit 2
fi
# Compare using sort -V (version sort)
check_fixed() {
local current="$1" fixed="$2"
if [ "$(printf '%s\n%s' "$fixed" "$current" | sort -V | head -1)" = "$fixed" ]; then
return 0 # current >= fixed
fi
return 1
}
case "$VER" in
4.0.*)
if check_fixed "$VER" "4.0.2"; then
echo "PATCHED — $VERSION_STR (fixed in 4.0.2)"
exit 0
fi
;;
3.6.*)
if check_fixed "$VER" "3.6.4"; then
echo "PATCHED — $VERSION_STR (fixed in 3.6.4)"
exit 0
fi
;;
3.5.*)
if check_fixed "$VER" "3.5.8"; then
echo "PATCHED — $VERSION_STR (fixed in 3.5.8)"
exit 0
fi
;;
3.4.*)
if check_fixed "$VER" "3.4.7"; then
echo "PATCHED — $VERSION_STR (fixed in 3.4.7)"
exit 0
fi
;;
3.0.*)
if check_fixed "$VER" "3.0.22"; then
echo "PATCHED — $VERSION_STR (fixed in 3.0.22)"
exit 0
fi
;;
1.1.1*)
echo "VULNERABLE — $VERSION_STR (check if >= 1.1.1zi with distro backport)"
exit 1
;;
1.0.2*)
echo "VULNERABLE — $VERSION_STR (check if >= 1.0.2zr with distro backport)"
exit 1
;;
*)
echo "UNKNOWN — unrecognized OpenSSL branch: $VERSION_STR"
exit 2
;;
esac
echo "VULNERABLE — $VERSION_STR"
exit 1