A loaded gun in a locked display case — the scariest CVE here requires a config almost nobody runs
This Tenable plugin bundles four CVEs fixed in OpenSSL 1.1.1zg (April 7 2026). The headline issue is CVE-2026-28387, a use-after-free / double-free in DANE TLSA-based server authentication that can theoretically reach RCE (CVSS 8.1). The remaining three — CVE-2026-28388, CVE-2026-28389, and CVE-2026-28390 — are all NULL-pointer-dereference crashes (DoS only) in delta CRL and CMS EnvelopedData processing, rated Low by OpenSSL itself. Affected versions span all OpenSSL 1.1.1 releases prior to 1.1.1zg, as well as 3.0 < 3.0.20, 3.3 < 3.3.7, 3.4 < 3.4.5, 3.5 < 3.5.6, and 3.6 < 3.6.2.
Tenable inherits the CVSS 8.1 from CVE-2026-28387 and stamps the whole plugin HIGH, but the vendor severity overstates real-world risk significantly. CVE-2026-28387 requires the *client* application to perform DANE TLSA validation with both PKIX and DANE-TA certificate usages enabled simultaneously — a configuration so rare that RFC 7672 explicitly advises SMTP MTAs to treat PKIX usages as 'unusable'. The three DoS CVEs require the application to call CMS_decrypt() or process delta CRLs on attacker-controlled input, which limits the blast radius to S/MIME gateways or CRL-consuming PKI components. OpenSSL 1.1.1 has been EOL since September 2023; only premium-support customers and OS-vendor backports receive these fixes.
4 steps from start to impact.
Identify OpenSSL 1.1.1 target acting as DANE TLSA client
- Target runs OpenSSL 1.1.1 < 1.1.1zg
- Target application performs DANE TLSA validation
- Both PKIX and DANE-TA certificate usages are enabled
- DANE TLSA adoption is minimal outside a handful of European MTAs
- RFC 7672 recommends SMTP MTAs treat PKIX usages as unusable, so compliant implementations are not vulnerable
- No scanner or fingerprint can remotely detect DANE TLSA client configuration
Publish crafted TLSA DNS records
- Attacker controls DNS responses for the destination domain
- TLSA RRset includes both PKIX and DANE-TA records
- DNSSEC validation (common in DANE-using environments) blocks spoofed records
- Requires either domain ownership or upstream DNS compromise
Client connects and triggers use-after-free
- Client initiates outbound TLS connection to attacker-controlled server
- Client processes the mixed PKIX+DANE-TA TLSA records
- Exploitation of use-after-free for code execution requires heap grooming specific to the target's allocator and OpenSSL build
- Crash (DoS) is far more likely than reliable RCE
- No public PoC or weaponized exploit exists
CMS/CRL DoS path (alternative, lower impact)
- Target application calls CMS_decrypt() on untrusted input, OR processes untrusted delta CRLs
- Attacker can deliver crafted CMS/CRL data to the application
- Most TLS server deployments never call CMS_decrypt() — this affects S/MIME gateways, CMS-based protocols, or PKI infrastructure specifically
- Crash is easily recoverable with process restart
SSL_dane_enable(), SSL_dane_tlsa_add(), or Postfix/Exim DANE settings. If no application uses DANE TLSA client validation, CVE-2026-28387 does not apply to your environment. Complete this audit within the noisgate 365-day remediation window.CMS_decrypt() is only called on authenticated or trusted CMS messages. S/MIME gateways should validate sender identity before CMS decryption.- WAF / IDS signatures — these CVEs are triggered in TLS handshake internals (DANE) or encrypted CMS payloads, not in HTTP request bodies. No WAF can inspect or block the attack.
- Network segmentation alone — CVE-2026-28387 targets outbound TLS connections from the vulnerable client, so blocking inbound traffic does not help.
- Upgrading to 1.1.1zg on public OpenSSL — 1.1.1zg is only available via premium support or OS-vendor backports. You cannot download it from openssl.org without a support contract.
The supporting signals.
| In-the-Wild Exploitation | None observed. Not listed on CISA KEV. No campaigns reported. |
|---|---|
| Proof of Concept | No public PoC exists for any of the four CVEs. The DANE TLSA chain is complex to reproduce. |
| EPSS | CVE-2026-28387: 0.67% (49th percentile) — below the median exploitation probability |
| KEV Status | Not listed. No CISA KEV entry as of 2026-09-17. |
| CVSS Vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H (8.1) — the AC:H is doing heavy lifting; real-world complexity is even higher than CVSS captures |
| Affected Versions | OpenSSL 1.1.1 – 1.1.1zf, 3.0.0 – 3.0.19, 3.3.0 – 3.3.6, 3.4.0 – 3.4.4, 3.5.0 – 3.5.5, 3.6.0 – 3.6.1 |
| Fixed Versions | 1.1.1zg (premium support only), 3.0.20, 3.3.7, 3.4.5, 3.5.6, 3.6.2. Distro backports: check RHEL, Ubuntu, SUSE advisories. |
| Exposure Data | OpenSSL 1.1.1 remains widely deployed per Censys/Shodan (~millions of hosts), but DANE TLSA client usage is negligible — Shodan DANE TLSA tags show <10,000 servers globally advertising DANE, and client-side is unmeasurable. |
| Disclosure Date | 2026-04-07 (coordinated release with OpenSSL advisory) |
| Reported By | OpenSSL project internal and community contributors. No specific researcher credited publicly for CVE-2026-28387. |
Sources.
Why this verdict
- DANE TLSA prerequisite eliminates >99.9% of the attack surface. The headline CVE requires client-side DANE TLSA with dual PKIX+DANE-TA usages — a configuration almost no enterprise deploys, and one that RFC 7672 explicitly discourages for SMTP.
- Three of four CVEs are DoS-only NULL derefs rated Low by the vendor. These require the application to process attacker-controlled CMS or delta CRL data, limiting scope to S/MIME gateways and PKI infrastructure.
- No PoC, no exploitation, sub-median EPSS. At 0.67% EPSS (49th percentile), the exploitation probability is below average. No weaponized tooling exists.
- Role multiplier: OpenSSL is ubiquitous in high-value roles (edge appliances, identity providers, hypervisors), but the DANE TLSA code path is *not triggered* in standard TLS server or client operation. The chain does NOT succeed against a typical web server, load balancer, IdP, or hypervisor — only against a DANE TLSA-validating client. The CMS DoS path could theoretically hit S/MIME gateways or PKI/CA infrastructure, but impact is DoS (recoverable crash), not compromise. The floor does not trigger because the vulnerable code path is not exercised in canonical high-value deployments.
- AC:H in CVSS underrepresents real complexity. The attacker must control DNS (or the destination domain's TLSA records) AND the target must have the rare dual-usage config. This is multiple independent low-probability conditions compounding.
Why not higher?
Despite OpenSSL's ubiquity, the DANE TLSA prerequisite is not a standard TLS configuration — it is a specialized DNS-based authentication extension used by a tiny fraction of deployments. Elevating to HIGH would require evidence that a material fraction of enterprise OpenSSL installations enable dual-usage DANE TLSA validation, and no such evidence exists. The three DoS CVEs are vendor-rated Low and cannot justify HIGH on their own.
Why not lower?
The theoretical impact of CVE-2026-28387 is full RCE via use-after-free in a network-facing context with no authentication required. While the preconditions are extremely narrow, the consequences if met are severe. The CMS DoS CVEs also have a non-trivial attack surface in S/MIME-processing environments. Dropping to LOW would understate the residual risk for the small population of DANE-enabled deployments.
Crowdsourced verification payload.
Run this script on each target host to check the installed OpenSSL version. Requires shell access (no root needed). Example: bash check_openssl_cve2026.sh
#!/bin/bash
# OpenSSL 1.1.1zg vulnerability check
# Checks for CVE-2026-28387, CVE-2026-28388, CVE-2026-28389, CVE-2026-28390
# Run on target host. No root required.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
OPENSSL_BIN=$(command -v openssl 2>/dev/null)
if [ -z "$OPENSSL_BIN" ]; then
echo "UNKNOWN - openssl binary not found in PATH"
exit 2
fi
VERSION_STRING=$($OPENSSL_BIN version 2>/dev/null)
if [ $? -ne 0 ]; then
echo "UNKNOWN - failed to execute openssl version"
exit 2
fi
echo "Detected: $VERSION_STRING"
# Check if this is OpenSSL 1.1.1
if echo "$VERSION_STRING" | grep -qE 'OpenSSL 1\.1\.1'; then
# Extract the letter suffix (e.g., 'zf', 'zg', 'w')
SUFFIX=$(echo "$VERSION_STRING" | sed -n 's/.*OpenSSL 1\.1\.1\([a-z]*\).*/\1/p')
# 1.1.1zg and later are patched
# Compare lexicographically: zg, zh, zi... are patched
if [ -z "$SUFFIX" ]; then
# Base 1.1.1 with no suffix - vulnerable
echo "VULNERABLE - OpenSSL 1.1.1 (no patch suffix) is affected"
exit 1
fi
# zg = patched. Anything before zg = vulnerable.
# Letters: a-z = 1.1.1a through 1.1.1z, then za-zf = vulnerable, zg+ = patched
if echo "$SUFFIX" | grep -qE '^z[g-z]'; then
echo "PATCHED - OpenSSL 1.1.1$SUFFIX is >= 1.1.1zg"
exit 0
else
echo "VULNERABLE - OpenSSL 1.1.1$SUFFIX is below 1.1.1zg"
exit 1
fi
# Check if this is OpenSSL 3.0.x
elif echo "$VERSION_STRING" | grep -qE 'OpenSSL 3\.0\.'; then
MINOR=$(echo "$VERSION_STRING" | sed -n 's/.*OpenSSL 3\.0\.\([0-9]*\).*/\1/p')
if [ "$MINOR" -ge 20 ] 2>/dev/null; then
echo "PATCHED - OpenSSL 3.0.$MINOR >= 3.0.20"
exit 0
else
echo "VULNERABLE - OpenSSL 3.0.$MINOR < 3.0.20"
exit 1
fi
# Check 3.3.x, 3.4.x, 3.5.x, 3.6.x
elif echo "$VERSION_STRING" | grep -qE 'OpenSSL 3\.[3456]\.'; then
BRANCH=$(echo "$VERSION_STRING" | sed -n 's/.*OpenSSL 3\.\([0-9]*\)\.\([0-9]*\).*/\1/p')
PATCH=$(echo "$VERSION_STRING" | sed -n 's/.*OpenSSL 3\.\([0-9]*\)\.\([0-9]*\).*/\2/p')
case "$BRANCH" in
3) FIXED=7 ;;
4) FIXED=5 ;;
5) FIXED=6 ;;
6) FIXED=2 ;;
*) echo "UNKNOWN - unrecognized branch 3.$BRANCH"; exit 2 ;;
esac
if [ "$PATCH" -ge "$FIXED" ] 2>/dev/null; then
echo "PATCHED - OpenSSL 3.$BRANCH.$PATCH >= 3.$BRANCH.$FIXED"
exit 0
else
echo "VULNERABLE - OpenSSL 3.$BRANCH.$PATCH < 3.$BRANCH.$FIXED"
exit 1
fi
else
echo "UNKNOWN - not an affected OpenSSL branch ($VERSION_STRING)"
exit 2
fi