OpenSSL 1.1.1 < 1.1.1zg Multiple Vulnerabilities

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.

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.

1. Audit for DANE TLSA client usage — Search your codebase and configurations for 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.
2. Disable dual PKIX+DANE-TA certificate usages — If DANE TLSA is in use, configure the client to use only DANE-TA(2) and DANE-EE(3) usages, not PKIX-TA(0) or PKIX-EE(1). This eliminates the vulnerable code path. RFC 7672 already recommends this for SMTP.
3. Restrict CMS processing to trusted input — For CVE-2026-28389/28390, ensure CMS_decrypt() is only called on authenticated or trusted CMS messages. S/MIME gateways should validate sender identity before CMS decryption.
4. Upgrade OpenSSL to a supported branch — OpenSSL 1.1.1 has been EOL since September 2023. Migrate to 3.0.x (LTS, supported until Sept 2026) or 3.4.x/3.5.x for long-term support. This is a strategic remediation item within the noisgate 365-day remediation window.

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

Sources

1. Tenable Plugin 305204
2. OpenSSL 1.1.1 Vulnerability List
3. CVE-2026-28387 — Snyk
4. CVE-2026-28387 — Red Hat
5. CVE-2026-28389 — SentinelOne
6. IBM Security Bulletin (CVE-2026-28387/28388/28389/28390)
7. OpenSSL 1.1.1 EOL Announcement
8. CISA KEV Catalog