OpenSSL 4.0.1 and 3.6.3: 18 CVEs, one High in PKCS7_verify

On 9 June 2026 the OpenSSL project released 4.0.1, 3.6.3, 3.5.7, 3.4.6 and 3.0.21, plus 1.1.1zh and 1.0.2zq for premium support customers. The advisory fixes 18 CVEs. One is rated High: a use after free in PKCS7_verify() (CVE-2026-45447) where an empty digestAlgorithms SET can cause a caller owned BIO to be freed. Five are Moderate and twelve are Low.

OpenSSL is in nearly every system, so the count looks alarming. But the library is a toolbox, and most of these bugs sit in features many programs never call: CMS, CMP, QUIC, OCSP stapling, AES-OCB. Reachability here means asking which of those your software actually uses.

What's affected

Fixed in 4.0.1, 3.6.3, 3.5.7, 3.4.6 and 3.0.21 (and 1.1.1zh and 1.0.2zq for premium support). The advisory did not analyze 3.1 to 3.3. The High and Moderate entries:

The Low entries include an ASN.1 string copy overflow (CVE-2026-7383), an ASN.1 decoder truncation over 2 GB, PKCS#12 PBMAC1 accepting one byte HMAC keys, several NULL dereferences in OCSP, CMS and CRMF paths, a Bleichenbacher style oracle in CMS_decrypt(), a CMP trust anchor substitution, an out of bounds read in X509_VERIFY_PARAM_set1_email(), and an AES-SIV and AES-GCM-SIV empty ciphertext tag issue.

One detail for FIPS users: of the 18, only CVE-2026-42770, a small subgroup issue in FFC-DH peer validation that can leak a private key, is listed as affecting the FIPS modules. The advisory says the PKCS7_verify issue is outside the FIPS boundary.

How to check if you're exposed

Find every OpenSSL on the machine, not just the system package.

openssl version -a
# which processes load which libssl
lsof -nP 2>/dev/null | grep -E "libssl|libcrypto" | awk '{print $1, $9}' | sort -u
# statically bundled copies in binaries
strings -a /path/to/binary | grep -m1 "OpenSSL [0-9]"
# language runtimes
python -c "import ssl; print(ssl.OPENSSL_VERSION)"
node -p "process.versions.openssl"
# containers
docker run --rm your-image:tag sh -c 'openssl version 2>/dev/null; ldconfig -p | grep -E "libssl|libcrypto"'

Then check feature use, in your own code and in what you ship:

grep -rnE "PKCS7_verify|PKCS7_decrypt|CMS_decrypt|CMS_verify" src
grep -rnE "SSL_set_quic|OSSL_QUIC|ngx_quic|quic" src config 2>/dev/null
grep -rnE "OCSP|ocsp_stapling|SSL_CTX_set_tlsext_status" src config 2>/dev/null
grep -rnE "EVP_aes_(128|192|256)_ocb|aes-.*-ocb" src

A rough guide to reading hits:

• PKCS7_verify in a code path that handles externally supplied signed data (S/MIME, document signing, package signature checks) is the High case.
• QUIC server or HTTP/3 enabled: the two QUIC issues apply, and they affect 3.4 and later only.
• Client side OCSP stapling checks apply only to 4.0 and 3.6 for the double free.
• OCB with the EVP_Cipher() interface is narrow. Most apps use GCM or ChaCha20 Poly1305.

What to do now

1. Patch your distribution packages and rebuild every container image. A base image rebuild is the common fix for services that use the system library.
2. List statically linked and vendored copies: language runtimes, database drivers, Electron, Go with cgo, Python wheels that bundle OpenSSL. Each needs its own vendor update.
3. Do the PKCS7_verify search first. If you verify signed data from outside your trust boundary, patch those services first.
4. If you run QUIC or HTTP/3 on a public listener, patch it before the Low items.
5. If you are on 1.1.1 or 1.0.2 without premium support, treat the whole list as open and plan a move to a supported branch.
6. For FIPS deployments, check your module vendor's update path for CVE-2026-42770 separately from the main library.

How this could have been avoided

A library CVE is rarely preventable at the consumer side, but the damage is. These controls tie to how these bugs work.

• Verify signatures in a narrow, isolated process. The High bug frees a caller owned BIO while verifying PKCS#7 data. A small verifier process that handles untrusted signed blobs contains a crash or heap corruption.
• Keep an inventory of OpenSSL copies. The trouble with this advisory is the number of places the library hides. An SBOM that records the version in each image tells you in minutes where to rebuild.
• Disable features you do not serve. QUIC and HTTP/3 are off by default in most deployments. Leave them off until you need them and the two QUIC CVEs are out of reach.
• Do not accept stapled OCSP responses from arbitrary servers on clients that do not need them. Several issues depend on a hostile OCSP responder.
• Pin to a supported branch. 1.1.1 and 1.0.2 get fixes only with premium support. Staying on 3.x LTS lines means the free fix arrives with the advisory.

Why it matters

A vulnerability count tells you little about risk. Eighteen CVEs, one High, and for a typical web service behind a TLS terminating proxy the real exposure may be one or two items. For a mail gateway that validates S/MIME, it may be the High one plus the CMS cluster.

Matching a version number gives you a list. Reachability analysis checks whether your code calls the affected function, and turns that list into an order. That matters most for a library that sits in the base layer of every image you own.

The other lesson is about speed to rebuild. Patched packages exist the same day. The slow part is finding all the copies.

Try it yourself

Produce an inventory of OpenSSL versions across your images or hosts with the commands above, then write a one line statement per service: "uses CMS: yes or no, serves QUIC: yes or no." The services with two yeses go first. A machine readable statement of which CVEs do not apply to a product can be published as VEX.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• OpenSSL Security Advisory, 9 June 2026
• OpenSSL release announcement, 9 June 2026