CVE-2025-15467 in OpenSSL CMS: Patch Posture & SBOM Response

On January 27, 2026, the OpenSSL Project published a security advisory disclosing CVE-2025-15467, a stack-based buffer overflow in the Cryptographic Message Syntax (CMS) module reachable before authentication. The CVSS v3.1 base score is 9.8, the highest rating OpenSSL has assigned since the Heartbleed disclosure of 2014. Trigger conditions: any application processing a malformed encrypted CMS message through CMS_decrypt, CMS_verify, or SMIME_read_CMS can hit the overflow before any signature verification or key validation runs. The exposure includes mail servers (Postfix, Exim, Sendmail with S/MIME), document signing services, S/MIME-validating browsers, and a long tail of network appliances that use CMS for code signing or configuration encryption. OpenSSL CVEs of this severity are SBOM-driven emergencies because the library lives at the bottom of countless dependency stacks.

What does the vendor advisory say?

The OpenSSL advisory describes CVE-2025-15467 as an overflow in the CMS module's handling of the ContentEncryptionAlgorithmIdentifier parameter. When the parameter contains a specially crafted ASN.1 OID with unbounded length, the parser writes past the end of a fixed-size stack buffer. Because the overflow occurs prior to authentication or signature checking, no valid key material is required to trigger it. The advisory characterizes the outcome as guaranteed denial of service via process crash; remote code execution is "possible depending on platform mitigations including stack canaries and ASLR." OpenSSL labeled the advisory Critical severity — the highest of the project's four severity tiers — and notes that this is the first Critical advisory since CVE-2022-3602 (XMM register memory corruption) in 2022. The CMS module is enabled by default in every standard OpenSSL build, so disabling the feature at compile time is not a practical control for most consumers.

Which versions are affected and which are patched?

CVE-2025-15467 affects OpenSSL 3.0 through 3.0.18; OpenSSL 3.3.0 through 3.3.5; OpenSSL 3.4.0 through 3.4.3; OpenSSL 3.5.0 through 3.5.4; and OpenSSL 3.6.0. The advisory explicitly clarifies that OpenSSL 1.1.1 and 1.0.2 are NOT affected because the vulnerable code was introduced in the 3.0 rewrite of the CMS module. OpenSSL 3.1 and 3.2 reached end-of-life before this advisory and will not receive a backport — consumers on those branches must move to 3.3.6 minimum. Fixed releases shipped January 27, 2026:

• OpenSSL 3.6.1
• OpenSSL 3.5.5
• OpenSSL 3.4.4
• OpenSSL 3.3.6
• OpenSSL 3.0.19 (long-term support branch)

Downstream distribution patched builds:

• Red Hat Enterprise Linux 9: openssl-3.2.2-13.el9_5.4 (RHSA-2026:0145)
• Red Hat Enterprise Linux 8: NOT AFFECTED (RHEL 8 ships openssl-1.1.1k)
• Debian 12: openssl 3.0.19-1~deb12u1
• Debian 13: openssl 3.5.5-1+deb13u1
• Ubuntu 24.04 LTS: openssl 3.0.19-0ubuntu0.24.04.2
• Ubuntu 22.04 LTS: openssl 3.0.19-0ubuntu0.22.04.2
• Alpine Linux 3.19+: openssl 3.6.1-r0
• AWS Linux 2023: openssl 3.0.19-1.amzn2023.0.1
• FreeBSD: openssl 3.0.19 via FreeBSD-SA-26:01.openssl

Embedded systems, network appliances, and air-gapped environments will have a long tail. Track each affected vendor's advisory through their PSIRT.

Is it in CISA KEV and what is the EPSS score?

CVE-2025-15467 is not yet in CISA KEV as of January 28, 2026, the day after disclosure — but the Critical severity rating and pre-auth nature make KEV listing within 30 days highly likely. EPSS at publication was 0.18 and is expected to rise sharply as red-team tooling integrates triggers. CISA published joint advisory AA26-027A within 24 hours of disclosure urging federal civilian executive branch agencies to patch within 7 days regardless of KEV status, citing the lessons from Heartbleed where the long tail of unpatched copies persisted for years.

How do you find vulnerable instances in your SBOM?

OpenSSL is the most-embedded library in production after libxml2 and zlib. Safeguard saved query:

# Identify every artifact containing OpenSSL 3.0..3.6.0 in the affected range
safeguard scan --cve CVE-2025-15467 --component "pkg:generic/openssl"

# Surface mail servers, S/MIME processors, and CMS-using infrastructure
safeguard assets list \
  --filter "vendor=openssl AND product=openssl AND feature IN (smime,cms,document-signing)" \
  --include-cve CVE-2025-15467

For shops on Syft + Grype, the equivalent invocation is grype dir:./ --only-fixed --by-cve CVE-2025-15467. For container estates, scan the entire registry catalog and prioritize images that process external CMS payloads (mail relays, document validators, code-signing services, certain VPN appliances). The most-often-forgotten copies are: vendored OpenSSL inside Go binaries built with cgo, Java services using the BoringSSL/OpenSSL native bridge, and embedded firmware that statically links openssl into a single image.

What is the recommended patch rollout?

OpenSSL recommends:

1. Identify every host, container, language runtime, and embedded firmware artifact carrying affected OpenSSL.
2. For OS-managed copies: pull the patched distro package and restart all services that link OpenSSL. The list is long — defenders frequently miss long-running daemons that loaded the old library at startup. Use lsof | grep libssl.so or lsof -p <pid> | grep ssl to identify them.
3. For container base images: rebuild every base layer (debian:bookworm, redhat/ubi9, alpine:3.19), then trigger downstream rebuilds in CI.
4. For language runtimes with bundled OpenSSL: Node.js — bump to Node 22.13.0 or 20.19.1 (both shipped patched OpenSSL within 72 hours); Python — wait for cpython 3.13.2 or use the system OpenSSL via --with-openssl-system; Ruby — Ruby 3.4.2 bundled the fix; Java — vendors using BoringSSL or native OpenSSL bindings need their own patched builds.
5. For embedded firmware: track each vendor's PSIRT advisory.
6. Re-scan and confirm the SBOM no longer matches the CVE.

Compensating control while patching: disable CMS processing in applications that do not need it. Mail server admins can set smtpd_tls_security_level and similar to disable inbound S/MIME validation if business need permits. Document validation services can route through a sandboxed parser temporarily. None of these are substitutes for the patch but they shrink the trigger surface during the rollout window.

What detections does the vendor or CISA publish?

CISA AA26-027A includes a Snort signature for the malformed CMS payload pattern observable on plaintext SMTP and HTTPS-decrypted flows, and a YARA rule for the post-exploitation in-the-wild implant if one emerges. The vendor-supplied verification check:

# Source: OpenSSL advisory CVE-2025-15467, 2026-01-27
# Verify installed library version
openssl version -a

# Check which version each running process linked
for pid in $(pgrep -d, '.'); do
  echo "PID $pid: $(readlink -f /proc/$pid/exe)"
  lsof -p $pid 2>/dev/null | grep -E 'libssl|libcrypto' | head -2
done

# Distro-specific package check
rpm -q --queryformat '%{NAME}-%{VERSION}-%{RELEASE}\n' openssl openssl-libs    # RHEL
dpkg -l openssl libssl3                                                          # Debian/Ubuntu
apk info -v openssl                                                              # Alpine

For network-layer visibility, ensure your TLS-inspection proxy logs the inner application protocol (SMTP STARTTLS, HTTPS POST /cms-validate) so anomalous request patterns to CMS-processing endpoints are recorded for post-incident review.

How Safeguard Helps

Safeguard's OpenSSL SBOM matcher resolves the library across pkg:deb, pkg:rpm, pkg:apk, pkg:generic, vendored copies inside Go binaries, JNI bindings inside Java services, and Node.js/Python/Ruby runtime bundles. The Critical-severity OpenSSL CVE workflow ships a pre-built policy gate that blocks every CI promotion of an artifact still matching CVE-2025-15467 until the gate is acknowledged or a VEX statement justifies the exception. Griffin AI ranks affected services by CMS reachability — mail servers, document signing services, and code-signing infrastructure rise to the top of the queue; internal cron jobs with no S/MIME usage drop to the bottom. The remediation engine generates per-repository PRs that bump the base image, the language runtime, or the Go OpenSSL wrapper version, plus a service-restart runbook covering the lsof libssl step that operators frequently miss. VEX statements from RHEL 8 and other 1.1.1-pinned distributions are auto-ingested as "not affected" so the dashboard stays focused on real exposure. Pair the OpenSSL advisory workflow with the existing Heartbleed retrospective skill to lift response speed across the OpenSSL Critical class of CVEs.