Issue summary: OpenSSL CMS decryption sizes the key-unwrap output buffer based on querying the unwrapped…

CVE-2026-63072 is a heap buffer overflow in OpenSSL's CMS (Cryptographic Message Syntax) decryption path. When CMS_decrypt() processes an AES-WRAP-PAD wrapped key, it allocates an output buffer sized by querying the expected unwrapped key length. But the AES-WRAP-PAD unwrap primitive, especially on integrity-failure paths, can write and then zero up to 8 bytes past that allocation. An attacker flips a single OID byte in a legitimate CMS-encrypted message to select the padded variant, and the victim's call to CMS_decrypt() triggers a deterministic 8-byte out-of-bounds heap write. Affected versions span virtually every supported OpenSSL branch: 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, and 1.1.1 through 1.1.1zh.

The NVD slapped a HIGH 7.5 on this, but OpenSSL's own project severity is Moderate, and reality sides with OpenSSL. The CVSS vector (AV:N/AC:L/PR:N/UI:N) is technically valid *if* the target application passes attacker-controlled CMS blobs to CMS_decrypt() — but the overwhelming majority of OpenSSL deployments use it for TLS, not S/MIME or CMS envelope processing. The write is fixed-size (8 bytes) and fixed-value (zeros), which OpenSSL explicitly notes makes RCE implausible; the realistic outcome is heap corruption → crash → denial of service. The NVD HIGH feels like a CVSS-by-vector-math exercise that ignores the narrow reachable population.

Why this verdict

• Narrow code path reachability: The bug lives in CMS_decrypt() → cms_kek_cipher(), not in the TLS handshake or certificate verification. The overwhelming majority of OpenSSL consumers — web servers, load balancers, CLI tools, language runtimes — never call this function. This alone eliminates >90% of the installed base from meaningful exposure.
• Fixed-size zero write limits impact to DoS: The overflow is exactly 8 bytes of zeros. OpenSSL explicitly states no evidence of RCE feasibility. For heap exploitation, you need control over the written value and some heap feng-shui — an 8-byte zero clobber of heap metadata crashes the process but doesn't give you a shell.
• No exploitation activity or PoC: Disclosed <48 hours ago, no PoC published, no KEV listing, no threat intel reports. The trivial-to-describe-but-narrow-to-reach nature of the bug makes mass exploitation unlikely.
• Role multiplier: For *email gateways* and *S/MIME processing servers* that call CMS_decrypt(), this is a legitimate availability risk — a single crafted email can crash the gateway. However, even in that high-value role, the blast radius is process crash (restart in seconds) → transient DoS, not data breach or lateral movement. This keeps the floor at MEDIUM, not HIGH.
• OpenSSL's own assessment agrees: The OpenSSL project rated this Moderate, not High. OpenSSL's security team historically under-rates rather than over-rates, making their Moderate assessment a strong signal.

Why not higher?

To warrant HIGH, the bug would need either a credible RCE path or broad reachability across the OpenSSL installed base. It has neither — the write is fixed-value zeros (no RCE), and the code path is CMS-specific (narrow population). Even for email gateways in the high-value role, the outcome is a restartable crash, not persistent compromise. No exploitation in the wild further undercuts urgency.

Why not lower?

Despite the narrow attack surface, the bug *is* trivially triggerable (single-byte OID flip) for any application that does call CMS_decrypt(), requires no authentication, and produces reliable heap corruption. S/MIME email gateways are a real deployment pattern, and crashing one is a meaningful availability event. The breadth of affected versions (every supported OpenSSL branch including 1.1.1) also prevents a LOW rating.

1. Audit your estate for CMS_decrypt() callers — Before patching 10,000 hosts, identify which applications actually use OpenSSL's CMS API. Run grep -r 'CMS_decrypt\|cms_decrypt' /opt /usr/local or check linked symbols with nm -D /path/to/binary | grep CMS_decrypt. Focus patching effort on those hosts first. No mitigation SLA applies for MEDIUM — go straight to the 365-day remediation window.
2. Validate S/MIME algorithm OIDs before decryption — If you control the application code, reject CMS messages with unexpected key-wrap algorithm OIDs (specifically AES-WRAP-PAD variants: OID 2.16.840.1.101.3.4.1.8/28/48) before passing them to CMS_decrypt(). This blocks the single-byte-flip attack entirely.
3. Enable process restart supervision — Ensure S/MIME-processing services are supervised by systemd, Docker restart policies, or Kubernetes liveness probes with aggressive restart thresholds. This limits DoS window to seconds per crash.
4. Rate-limit inbound S/MIME at the mail gateway — Apply rate limiting on S/MIME-encrypted messages at the MTA layer (Postfix smtpd_client_message_rate_limit, Exchange transport rules) to prevent an attacker from sustaining a crash loop.

Run on each target host as any user. Example: bash check_cve_2026_63072.sh — no root required. The script checks the installed OpenSSL library version against the known-fixed versions.

#!/usr/bin/env bash
# CVE-2026-63072 checker — OpenSSL CMS AES-WRAP-PAD heap overflow
# Run on target host. No privileges required.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

get_openssl_version() {
  if command -v openssl >/dev/null 2>&1; then
    openssl version 2>/dev/null | awk '{print $2}'
  else
    echo ""
  fi
}

VER=$(get_openssl_version)
if [ -z "$VER" ]; then
  echo "UNKNOWN — openssl binary not found in PATH"
  exit 2
fi

echo "Detected OpenSSL version: $VER"

# Compare versions using sort -V
version_gte() {
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

VULN=0

case "$VER" in
  4.0.*)
    version_gte "$VER" "4.0.2" || VULN=1
    ;;
  3.6.*)
    version_gte "$VER" "3.6.4" || VULN=1
    ;;
  3.5.*)
    version_gte "$VER" "3.5.8" || VULN=1
    ;;
  3.4.*)
    version_gte "$VER" "3.4.7" || VULN=1
    ;;
  3.3.*|3.2.*|3.1.*)
    # These branches are EOL and do not receive fixes
    echo "WARNING — EOL branch $VER, no fix available"
    VULN=1
    ;;
  3.0.*)
    version_gte "$VER" "3.0.22" || VULN=1
    ;;
  1.1.1z[i-z]*)
    # 1.1.1zi or later is patched
    echo "PATCHED — $VER (1.1.1zi+ detected)"
    exit 0
    ;;
  1.1.1*)
    # 1.1.1 before 1.1.1zi
    VULN=1
    ;;
  1.0.*|0.*)
    echo "UNKNOWN — ancient OpenSSL $VER, likely vulnerable but EOL"
    exit 2
    ;;
  *)
    echo "UNKNOWN — unrecognized version $VER"
    exit 2
    ;;
esac

if [ "$VULN" -eq 1 ]; then
  echo "VULNERABLE — OpenSSL $VER is affected by CVE-2026-63072"
  exit 1
else
  echo "PATCHED — OpenSSL $VER is not affected by CVE-2026-63072"
  exit 0
fi

Sources

1. OpenSSL Security Advisories
2. OpenSSL commit: Fix heap buffer overflow in AES-WRAP-PAD unwrap
3. CybersecurityNews: Multiple OpenSSL Flaws
4. Ubuntu USN-8678-1
5. Tenable Nessus Plugin 339518
6. GBHackers: OpenSSL Flaws Allow Remote Attackers to Crash Servers
7. OpenCVE: CVE-2026-63072