OpenSSL CVE-2026-45447: who it really affects

OpenSSL’s June 2026 batch fixed CVE-2026-45447 — a heap use-after-free in `PKCS7_verify()`. It was found with a researcher and AI (Claude, Anthropic); a public PoC already exists.

The gist: when a program verifies a specially crafted PKCS#7 signature (an empty `digestAlgorithms` set), OpenSSL frees a buffer the caller still uses. The result is a crash, and in the worst case attacker code execution.

Important: this is not a bug in setting up a TLS connection. The vulnerable path is PKCS#7 / S-MIME signature verification, not how a browser opens your HTTPS site.

Severity is high: trackers give CVSS around 8.1–8.8, some sources up to 9.8. Check the OpenSSL advisory for the authoritative score.

A plain site that just serves pages over HTTPS does not call `PKCS7_verify()` on attacker data. So “I run OpenSSL” does not by itself mean “this CVE is exploitable against me from outside”.

It triggers where an application verifies a signature from an untrusted source:

• mail systems and gateways doing S/MIME verification
• verifying signed documents, packages, updates or tokens via OpenSSL
• some SSO / federation flows where an inbound object carries a PKCS#7 signature
• custom services that call `PKCS7_verify()` on input data

Noted separately: applications using OpenSSL’s CMS APIs (not the PKCS7 path) and the FIPS module are not affected.

Update to the fixed build in your branch:

• OpenSSL 3.6.x → 3.6.3 or newer
• OpenSSL 3.5.x → 3.5.7 or newer
• OpenSSL 3.4.x → 3.4.6 or newer
• OpenSSL 3.0.x → 3.0.21 or newer
• OpenSSL 4.0.x → 4.0.1 or newer
• OpenSSL 1.1.1 and 1.0.2 — open-source support has ended; fixes (1.1.1zh, 1.0.2zq) are premium-support only. Plan a move to a supported 3.x branch.

OpenSSL is a library, not a standalone service: update it via the distro package or base image, then restart everything linked against it (web server, mail, apps).

From outside, little about OpenSSL is visible — and this is exactly where a “match” must not be confused with “confirmed”.

• The OpenSSL version is not sent in the TLS handshake — the certificate doesn’t reveal it
• Sometimes the version leaks in a banner: Apache with `ServerTokens Full` (`Server: Apache/2.4.x OpenSSL/3.0.x`), or mail server greetings. nginx does not expose it by default
• If the version is visible and in the vulnerable range, that is a signal to look (`probable`), not proof this CVE is exploitable against you

There is no safe external probe that tells a vulnerable `PKCS7_verify()` from a patched one. So for this CVE signalfort honestly stays at `probable` from outside and shows where to look on the host, rather than painting a false “confirmed”. More on statuses: how to tell if a CVE affects you.

What signalfort does on your perimeter: finds hosts, spots a version leak in banners, keeps TLS hygiene (expiry, chain, weak parameters) and prioritises by KEV / EPSS / PoC availability. Start with a free check.

Shared hosting and managed services: updating OpenSSL is on the provider. If unsure, open a ticket referencing CVE-2026-45447 and ask which OpenSSL build your account runs.

Your own VPS / dedicated server: update the package (`openssl`, `libssl`) from the distro repo, then restart the web server, mail and apps; check `openssl version -a`.

Docker: rebuild images on a fresh base — an old layer carries old OpenSSL; redeploy the containers.

Mail gateways and S/MIME, signature-verification services: the risk here is above the rest — patching is the priority, and review which sources you even accept signed objects from.

Don’t forget stage/preview/old subdomains — inventory and alerts on new hosts: new subdomains and shadow IT.

• Don’t assume “I run nginx / a normal site, so it doesn’t affect me”: OpenSSL is linked into many services, and the package needs the patch regardless
• Don’t confuse a `probable` from a banner version with “we can be hacked via this CVE”
• Don’t run the public PoC against your own or anyone’s live services
• Don’t leave 1.1.1 / 1.0.2 on the perimeter without an upgrade plan, hoping “they won’t bother”

Confirm the system really runs the new build: `openssl version -a`, and for services that they were restarted and are linked against the updated library (`ldd` on the service binary).

Check containers and environments that are updated less often than production separately.

If you accept PKCS#7 / S-MIME from external sources, review those services’ logs for crashes and anomalies around the disclosure dates.

signalfort helps with perimeter exposure and version matches, but does not replace a software inventory and incident analysis on the servers themselves.