Issue summary: Receiving a DTLS record for a future epoch while a handshake is in progress causes OpenSSL…

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.

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.

1. Enable DTLS cookie verification (HelloVerifyRequest) — This forces attackers to complete a stateless cookie exchange before the server allocates handshake state, preventing spoofed-source attacks and adding friction. Set 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.
2. Rate-limit new DTLS handshakes per source IP — Configure your firewall or load balancer to cap new UDP session initiation rates to DTLS ports. This directly limits the attacker's ability to open thousands of concurrent connections needed to exhaust memory.
3. Set process-level memory limits (cgroups/ulimits) — Ensure DTLS-serving processes run under cgroups or ulimit constraints so that memory exhaustion kills the process rather than the host. Combine with a process supervisor for automatic restart.
4. Patch to fixed OpenSSL version — Upgrade to OpenSSL 4.0.2, 3.6.4, 3.5.8, 3.4.7, 3.0.22, 1.1.1zi, or 1.0.2zr. This is the definitive fix. Apply within the noisgate MEDIUM remediation window of 365 days.

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

Sources

1. OpenSSL Vulnerabilities Page
2. OpenSSL 3.5 Series Release Notes
3. CyberPress — OpenSSL Patches Nine Vulnerabilities
4. CybersecurityNews — Multiple OpenSSL Flaws
5. Tenable Plugin 339518 — OpenSSL 3.0.x < 3.0.22
6. Canadian Centre for Cyber Security — OpenSSL Advisory AV26-058
7. TheHackerWire — CVE-2026-54874 Info
8. LinuxCompatible — OpenSSL 4.0.2 Patches