CVE-2026-63072 · OpenSSL CMS Key Unwrapping Heap Buffer Overflow via AES-WRAP-PAD

01 · The Real Story

Someone slipped a slightly-too-big package into the mailroom, and the robot arm knocks over one shelf before stopping — but it can't open the safe

CVE-2026-63072 is a heap buffer overflow in OpenSSL's CMS (Cryptographic Message Syntax) key-unwrapping logic. When an application calls CMS_decrypt() on a crafted message, the AES-WRAP-PAD unwrap primitive writes — and then zeroes — eight bytes past the end of the allocated output buffer. The trigger is trivial: flip a single OID byte in a legitimate CMS message to select the padded key-wrap variant, and the integrity-failure path over-writes. Affected versions span OpenSSL 1.1.1 through 1.1.1zh, 3.0.0–3.0.21, 3.4.0–3.4.6, 3.5.0–3.5.7, 3.6.0–3.6.3, and 4.0.0–4.0.1. The fix ships in 1.1.1zi, 3.0.22, 3.4.7, 3.5.8, 3.6.4, and 4.0.2.

The CVSS 7.5 HIGH label overstates the real-world risk, and OpenSSL's own project rates this Moderate — a rare case where the vendor is *more conservative* than the number. Why? Because the write is fixed-size (8 bytes), fixed-value (zeroes), and only reachable through the CMS_decrypt() API on untrusted input — a code path exercised almost exclusively by S/MIME email gateways, PKI enrollment endpoints, and a handful of CMS-consuming document pipelines. The vast majority of OpenSSL deployments use the library for TLS and never touch CMS at all. The impact ceiling is a deterministic crash (DoS); OpenSSL explicitly does not claim RCE for this write, and independent analysis from Trail of Bits agrees: the eight-byte zero write corrupts adjacent heap metadata and triggers an allocator abort, but provides no attacker-controlled data injection.

"Narrow CMS code path + zero-only write = reliable crash, not compromise. Patch in cycle."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a CMS-consuming endpoint

The attacker identifies a service that accepts and decrypts CMS-formatted messages from untrusted sources. Common candidates are S/MIME email gateways, PKI/CMP enrollment services, or document-processing pipelines that call CMS_decrypt(). The attacker needs no credentials — only the ability to deliver a CMS blob to the target.

Conditions required:

Target application calls CMS_decrypt() on attacker-supplied input
Target runs a vulnerable OpenSSL version (1.1.1–1.1.1zh, 3.0.0–3.0.21, 3.4–3.4.6, 3.5–3.5.7, 3.6–3.6.3, 4.0–4.0.1)

Where this breaks in practice:

Most OpenSSL deployments use TLS only and never invoke CMS_decrypt() — estimated <5% of the install base
S/MIME gateways that auto-decrypt inbound mail are a shrinking population; most modern email security stacks handle S/MIME at the client, not the gateway

Detection/coverage: Nessus plugin 339486 checks installed OpenSSL version. Qualys QID available. openssl version on the host is sufficient for version-based detection.

STEP 02

Craft the malicious CMS message

The attacker takes any legitimate CMS EnvelopedData message (or constructs one from scratch) and modifies the key-wrap algorithm OID from id-aesNNN-wrap to id-aesNNN-wrap-pad — a single-byte flip. No valid wrapped key is required; the integrity-failure path in AES-WRAP-PAD is what triggers the overflow. The crafted message is trivial to produce with openssl cms and a hex editor.

Conditions required:

Knowledge of the CMS EnvelopedData ASN.1 structure (public specification, RFC 5652)

Where this breaks in practice:

The modification is trivial — near-zero friction at this step

Detection/coverage: Deep-content inspection for CMS messages with id-aesNNN-wrap-pad OID in inbound mail or API payloads could flag anomalies, but no production-grade signature exists in major IDS rulesets as of October 2026.

STEP 03

Deliver the message to the target

The attacker delivers the crafted CMS message via the application's normal input channel — an email with S/MIME attachment to the gateway, an HTTP POST to a CMP endpoint, or a file upload to a document-processing API. No authentication is needed if the endpoint accepts untrusted CMS blobs by design.

Conditions required:

Network reachability to the CMS-consuming endpoint
Endpoint accepts CMS from untrusted sources without pre-validation

Where this breaks in practice:

Email gateways typically sit behind MX records and accept inbound mail, so reachability is often given for that vector
CMP/EST enrollment endpoints are less commonly exposed externally

Detection/coverage: Standard mail-flow logging captures the inbound message. WAF rules could inspect Content-Type for application/pkcs7-mime but rarely do.

STEP 04

Trigger the heap overflow and crash

When the target calls CMS_decrypt(), OpenSSL queries the expected unwrapped key length, allocates a buffer of that size, then calls the AES-WRAP-PAD unwrap. On the integrity-failure path, the unwrap writes and cleanses up to inlen bytes — 8 bytes more than allocated. The eight zero bytes overwrite adjacent heap metadata, causing a deterministic allocator abort or segfault. The service process crashes.

Conditions required:

The application does not sandbox or fork-per-message (a crash kills the service)

Where this breaks in practice:

Many email gateways fork or use worker pools — a crash kills one worker, not the entire service; automatic restart limits the blast radius to a brief outage
The write is fixed-value zeroes — no attacker control over the overwritten data, so no pivot to RCE

Detection/coverage: Process crash monitoring, core-dump analysis showing a heap corruption in crypto/cms/cms_kari.c or cms_kemri.c. ASAN builds catch it instantly.

03 · Compensating Control

MEDIUM 5.5→LOW 2.5

SEVERITY REDUCED

Disable or restrict CMS_decrypt() on untrusted input at the application layer — If your application calls CMS_decrypt() and the CMS messages come from untrusted sources, add input validation to reject messages using id-aesNNN-wrap-pad OIDs before passing them to OpenSSL. Alternatively, restrict CMS processing to authenticated/trusted senders only. This eliminates the attack path entirely. No mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window, but prioritize this control for any internet-facing CMS endpoints.

MEDIUM 5.5→LOW 3.0

SEVERITY REDUCED

Deploy worker-pool isolation for CMS-processing services — Ensure that S/MIME gateways and CMS-consuming services use forked workers or containerized microservices so that a single crash does not take down the entire service. Most modern email gateways (Postfix+OpenSSL, Exchange transport agents) already fork per connection. Verify this architecture exists in your deployment. This does not prevent the crash but limits blast radius to a single message.

MEDIUM 5.5→IGNORE 0.0

SEVERITY REDUCED

Patch OpenSSL to the fixed version — Upgrade to OpenSSL 3.0.22, 3.4.7, 3.5.8, 3.6.4, 4.0.2, or 1.1.1zi depending on your branch. Apply distro-provided packages (RHSA-2026:67165, Debian 3.0.22-1~deb12u1, etc.) via your normal patch cycle. At MEDIUM severity, the noisgate remediation SLA is ≤365 days, but given the trivial trigger and broad version footprint, targeting your next quarterly patch window is prudent.

MEDIUM 5.5→MEDIUM 5.5

Enable ASAN or heap-hardening in development/staging builds — Compile OpenSSL with AddressSanitizer (-fsanitize=address) in CI/CD and staging to catch this and similar heap overflows before they reach production. This does not protect production hosts but accelerates detection of the vulnerable code path in your build pipeline.

What doesn't work

WAF rules on TLS content — The vulnerability is in CMS message processing, not in the TLS handshake. A WAF inspecting HTTP headers or TLS parameters will never see the malicious CMS payload, which travels inside an S/MIME attachment or a CMP request body.
Network segmentation alone — If the CMS-consuming service is an email gateway, it must be reachable from the internet by design. Segmentation does not reduce exposure for this component.
Disabling AES-WRAP-PAD at the OpenSSL config level — OpenSSL does not provide a configuration knob to selectively disable the AES-WRAP-PAD unwrap primitive in CMS. The vulnerable code path is hardwired into the CMS implementation.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. Not listed in CISA KEV. No GreyNoise or Shadowserver scanning activity reported as of 2026-10-08. No known campaigns targeting this CVE.
Proof-of-concept availability	Version checker only. 0xBlackash/CVE-2026-63072 is a bash script that identifies vulnerable OpenSSL versions — not a functional exploit. No entries on pocindex.io, ExploitDB, or Metasploit. Crafting the trigger is trivial (single OID byte flip), but no weaponized PoC circulates publicly.
EPSS score	0.00916 (0.9%) — 58th percentile. Low exploitation probability over the next 30 days.
CISA KEV status	Not listed as of 2026-10-08.
CVSS vector interpretation	`CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` — unauthenticated remote DoS with no confidentiality or integrity impact. The vector is fair for the reachable subset of deployments, but does not account for the narrow code-path exposure (CMS_decrypt only).
Affected version ranges	OpenSSL 1.1.1–1.1.1zh, 3.0.0–3.0.21, 3.4.0–3.4.6, 3.5.0–3.5.7, 3.6.0–3.6.3, 4.0.0–4.0.1. OpenSSL 1.0.2 and the FIPS module are not affected.
Fixed versions	1.1.1zi, 3.0.22, 3.4.7, 3.5.8, 3.6.4, 4.0.2. Distro backports: Debian Bookworm `3.0.22-1~deb12u1`, Trixie `3.5.7-1~deb13u2+`, Sid `3.6.4-1+`. RHEL: RHSA-2026:67165 / RHSA-2026:67154.
Scanning / exposure data	OpenSSL is present on virtually every Linux server and many appliances. However, the vulnerable code path (`CMS_decrypt` on untrusted input) is exercised by a small fraction — primarily S/MIME email gateways and PKI enrollment endpoints. Shodan reports millions of OpenSSL-backed TLS services; the CMS-exposed subset is not independently enumerable.
Disclosure & credit	Disclosed 2026-08-25 by the OpenSSL project. Found by Bhabani Sankar Das and Filipe Casal of Trail of Bits. Fix developed by Daniel Kubec.
Vendor severity	OpenSSL project rates Moderate. Red Hat rates Moderate. The CVSS 7.5 HIGH label comes from the NVD vector, not from the vendor's own assessment.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (5.5/10)

Why this verdict

Narrow code-path exposure: The vulnerability lives in CMS_decrypt(), not in the TLS handshake or record layer. Fewer than 5% of OpenSSL deployments process CMS messages from untrusted sources. The CVSS vector's AV:N/AC:L/PR:N assumes universal reachability, which is false for this API.
Fixed-size, fixed-value write caps the impact at DoS: The eight-byte zero write corrupts heap metadata and crashes the process. OpenSSL and independent researchers explicitly rule out RCE. There is no attacker-controlled data in the write, no integrity or confidentiality impact, and no privilege escalation path.
Vendor agrees this is Moderate, not HIGH: OpenSSL's own severity policy — which considers exploitability context, not just the CVSS vector — rates this Moderate. Red Hat concurs. The NVD 7.5 HIGH is a mechanical artifact of the vector components, not a considered risk judgment.
No exploitation pressure: EPSS 0.9%, no KEV listing, no in-the-wild exploitation, no weaponized PoC. The only public GitHub repo is a version-detection script, not an exploit. Crafting the trigger is easy, but nobody is bothering — the payoff is a crash, not a shell.
Role multiplier: OpenSSL is deployed across every tier — workstations, app servers, domain controllers, hypervisors, CI/CD, backup agents, edge appliances, databases. However, the *vulnerable code path* (CMS_decrypt on untrusted CMS blobs) is exercised almost exclusively by S/MIME email gateways and PKI enrollment endpoints. On a domain controller, OpenSSL handles TLS — it does not call CMS_decrypt() on inbound data. On a CI/CD runner, same story. The high-value role where the chain actually succeeds is the S/MIME gateway, and the blast radius there is a service crash (DoS), not domain takeover, fleet compromise, or supply-chain pivot. A DoS of one email gateway worker is operationally inconvenient but does not meet the HIGH floor threshold of 'domain / fleet / supply-chain / safety impact.' Therefore, no floor override applies.

Why not higher?

The CVSS 7.5 HIGH and the CWE-787 (Out-of-bounds Write) classification might suggest a more dangerous vulnerability, but the write is constrained: 8 bytes, always zeroes, no attacker data control. RCE is ruled out by OpenSSL and by independent analysis. The affected code path is narrow — CMS_decrypt on untrusted input — meaning the vast majority of the billions of OpenSSL instances worldwide are simply not reachable via this bug. Upgrading to HIGH would require either a plausible RCE path or a realistic scenario where the DoS causes cascading fleet-level impact, and neither exists.

Why not lower?

Despite the narrow code path, the vulnerability *is* trivially triggerable — a single OID byte flip — and requires no authentication. For the small but real population of S/MIME gateways and PKI endpoints that do call CMS_decrypt() on untrusted data, this is a reliable remote DoS with no workaround short of patching. Dropping to LOW would understate the risk for those specific deployments. The broad affected version range (spanning five major branches back to 1.1.1) also means that unpatched stragglers will persist for years.

06 · Verification

Crowdsourced verification payload.

Run this script on each target host where OpenSSL is installed. It requires no special privileges — just the ability to invoke openssl version. Example: bash check_cve_2026_63072.sh. It checks the installed OpenSSL version against known-fixed releases and reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_cve_2026_63072.sh — Detect CVE-2026-63072 (Heap Buffer Overflow in CMS Key Unwrapping)
# Run on the target host. No root required.
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -euo pipefail

VERSION_STRING=$(openssl version 2>/dev/null || true)
if [ -z "$VERSION_STRING" ]; then
  echo "UNKNOWN — openssl binary not found in PATH"
  exit 2
fi

# Extract version number, e.g. "3.0.21" from "OpenSSL 3.0.21 ..."
VER=$(echo "$VERSION_STRING" | grep -oP '(?<=OpenSSL )\S+')
if [ -z "$VER" ]; then
  echo "UNKNOWN — could not parse version from: $VERSION_STRING"
  exit 2
fi

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

version_lt() {
  ! version_gte "$1" "$2"
}

# Determine branch and check against fixed version
case "$VER" in
  1.0.2*)
    echo "PATCHED — OpenSSL $VER (1.0.2 branch is not affected by CVE-2026-63072)"
    exit 0
    ;;
  1.1.1*)
    if version_gte "$VER" "1.1.1zi"; then
      echo "PATCHED — OpenSSL $VER (fixed in 1.1.1zi)"
      exit 0
    else
      echo "VULNERABLE — OpenSSL $VER (fix: upgrade to >= 1.1.1zi)"
      exit 1
    fi
    ;;
  3.0.*)
    if version_gte "$VER" "3.0.22"; then
      echo "PATCHED — OpenSSL $VER (fixed in 3.0.22)"
      exit 0
    else
      echo "VULNERABLE — OpenSSL $VER (fix: upgrade to >= 3.0.22)"
      exit 1
    fi
    ;;
  3.1.*|3.2.*|3.3.*)
    echo "VULNERABLE — OpenSSL $VER (3.1/3.2/3.3 branches are EOL and have no fix; migrate to a supported branch)"
    exit 1
    ;;
  3.4.*)
    if version_gte "$VER" "3.4.7"; then
      echo "PATCHED — OpenSSL $VER (fixed in 3.4.7)"
      exit 0
    else
      echo "VULNERABLE — OpenSSL $VER (fix: upgrade to >= 3.4.7)"
      exit 1
    fi
    ;;
  3.5.*)
    if version_gte "$VER" "3.5.8"; then
      echo "PATCHED — OpenSSL $VER (fixed in 3.5.8)"
      exit 0
    else
      echo "VULNERABLE — OpenSSL $VER (fix: upgrade to >= 3.5.8)"
      exit 1
    fi
    ;;
  3.6.*)
    if version_gte "$VER" "3.6.4"; then
      echo "PATCHED — OpenSSL $VER (fixed in 3.6.4)"
      exit 0
    else
      echo "VULNERABLE — OpenSSL $VER (fix: upgrade to >= 3.6.4)"
      exit 1
    fi
    ;;
  4.0.*)
    if version_gte "$VER" "4.0.2"; then
      echo "PATCHED — OpenSSL $VER (fixed in 4.0.2)"
      exit 0
    else
      echo "VULNERABLE — OpenSSL $VER (fix: upgrade to >= 4.0.2)"
      exit 1
    fi
    ;;
  *)
    echo "UNKNOWN — unrecognized OpenSSL version: $VER"
    exit 2
    ;;
esac