A poisoned signed package turns signature verification into a memory corruption trap
The RHSA-2026:1503 update for RHEL 9 fixes two OpenSSL flaws. The serious one, CVE-2025-15467, allows remote code execution or denial of service via an oversized Initialization Vector when processing CMS/PKCS#7 data. Every RHEL 9 system with openssl-libs before the advisory fix is affected; the bug lives in the CMS parsing code, not the TLS handshake. CVE-2025-69419 is also fixed but receives less attention.
Tenable flags the plugin as Critical, while Red Hat classifies the advisory as Important. In reality, the severity depends on whether anything on the host actually feeds untrusted CMS data to OpenSSL. Default RHEL services rarely do; the exposed population is limited to mail gateways, S/MIME verification, file/doc processing pipelines and custom apps that call CMS_verify or CMS_decrypt on attacker-controlled input.
4 steps from start to impact.
Deliver malicious CMS/PKCS#7 payload
- Attacker can send untrusted CMS/PKCS#7 data to a RHEL 9 service
- Service uses vulnerable openssl-libs before RHSA-2026:1503
- CMS parsing is not part of standard TLS termination
- Email/file upload pipelines must explicitly use OpenSSL CMS functions
Application passes data to vulnerable OpenSSL CMS function
CMS_verify, CMS_decrypt, or SMIME_read_CMS on the attacker-supplied data. The vulnerable code path is reached before signature validation completes. No authentication is required beyond the ability to submit CMS data.- Application must be built against affected OpenSSL 3.x on RHEL 9
- CMS parsing enabled in the code path
- Many RHEL applications ship OpenSSL but never expose CMS entry points
- Custom or niche apps are more likely than base OS daemons
Oversized IV triggers heap corruption during cipher context setup
- Attacker controls the IV length field
- Process layout permits deterministic overwrite
- ASLR/PIE/NX and compiler stack cookies make reliable RCE harder
- SELinux enforcing on RHEL 9 can contain post-exploitation but not the initial crash/corruption
Run code in the service's security context
- Successful RCE exploitation
- Service account privileges allow useful post-exploitation
- Containerized or systemd service isolation may limit blast radius
- SELinux can block many post-exploitation primitives
- WAF and TLS inspection don't help — CMS payloads are often delivered inside encrypted SMTP or file uploads, and this is not a web request flaw.
- Disabling TLS/SSL won't mitigate — the vulnerable code is in CMS parsing, independent of transport encryption.
The supporting signals.
| In-the-wild status | No known exploitation; not in CISA KEV as of reassessment |
|---|---|
| PoC availability | No public PoC observed on pocindex.io or GitHub repos named for CVE-2025-15467 |
| EPSS | No EPSS record for CVE-2025-15467 at reassessment; too new |
| KEV status | Not listed in CISA Known Exploited Vulnerabilities |
| CVSS vector / interpretation | Red Hat advisory uses Important severity; Tenable plugin risk factor Critical. Treat as remote, unauthenticated in CMS-exposed services |
| Affected versions | RHEL 9 openssl-libs before RHSA-2026:1503 fixed packages; OpenSSL 3.x CMS code |
| Fixed versions | RHSA-2026:1503 packages; verify with dnf updateinfo or Red Hat advisory |
| Scanning/exposure | Local package check only; internet exposure not quantifiable via Shodan/Censys because CMS not advertised |
| Disclosure date | 2026-01-29 (OSV); Tenable plugin published 2026-01-28 |
| Reported by | Not attributed in available advisory data |
Sources.
Why this verdict
- Friction audit: CMS parsing is not reached by default TLS services; most RHEL 9 hosts never call
CMS_verify/CMS_decrypton untrusted data. - Role multiplier: high-value deployments — secure email gateways, S/MIME verification, code-signing verification — do process untrusted CMS and can turn this into RCE; that keeps the floor at HIGH.
- Exploitation status: no known in-the-wild use, no KEV listing, and no public PoC; treat as high risk but not an active campaign.
- Compounding narrowing: attacker must find a CMS-consuming app, not just any TLS service; that reduces exposed population below the full RHEL install base.
Why not higher?
Even though OpenSSL is ubiquitous, this is not a TLS handshake or certificate verification flaw. The default attack surface on stock RHEL 9 is minimal because few base daemons parse CMS. ASLR/SELinux and lack of public exploit keep it below CRITICAL.
Why not lower?
A remote unauthenticated attacker who can reach a CMS-processing app gets memory corruption with RCE/DoS potential. OpenSSL is a dependency in security-sensitive paths; ignoring this because 'it's just CMS' would miss mail gateways and document processors that are high-value targets.
Crowdsourced verification payload.
Run on each RHEL 9 host as root or via configuration management. Invoke with bash check_openssl_rhel9.sh; no arguments. It checks whether installed openssl-libs and openssl changelogs contain the fix IDs; returns exit 0 (PATCHED), 1 (VULNERABLE), 3 (UNKNOWN).
#!/bin/bash
# Check for RHSA-2026:1503 (CVE-2025-15467, CVE-2025-69419)
pkg_list="openssl-libs openssl"
installed=0
found=0
for pkg in $pkg_list; do
if rpm -q --quiet "$pkg"; then
installed=$((installed+1))
if rpm -q --changelog "$pkg" | grep -qE 'CVE-2025-15467|CVE-2025-69419'; then
found=$((found+1))
fi
fi
done
if [ "$installed" -eq 0 ]; then
echo "UNKNOWN"
exit 3
fi
if [ "$found" -ge 1 ]; then
echo "PATCHED"
exit 0
else
echo "VULNERABLE"
exit 1
fi