On June 9, 2026, the OpenSSL Project published what may be its most consequential security advisory of the year. Sixteen CVE entries. Eighteen vulnerabilities in total. One of them rated critical—a heap use-after-free capable of remote code execution that touches every major OpenSSL release branch still in active use, from the long-end-of-lifed 1.0.2 all the way to the current 4.0 line. If you operate any infrastructure that handles TLS, parses S/MIME email, or processes PKCS#7 signed data, this is not a “patch when convenient” situation. This is a patch-your-servers weekend.
I’ve been running hosting infrastructure long enough to remember when OpenSSL advisories were one-line affairs with a quick apt-get upgrade to close them out. This one is different. Not because the underlying flaw is technically exotic—it’s a use-after-free, a bug class as old as C itself—but because of how broadly it reaches across the version tree, and what it tells us about the state of cryptographic library maintenance across the industry.
What the Advisory Actually Contains
The June 9 OpenSSL Security Advisory contains sixteen CVE identifiers covering eighteen individual vulnerabilities. Most are rated Low or Moderate. But leading the list is CVE-2026-45447—a heap use-after-free in the PKCS7_verify() function that earns a CVSS v3.1 score of 9.8 (Critical).
Here’s the technical sketch: when OpenSSL processes a PKCS#7 or S/MIME signed message, and that message’s SignedData.digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL incorrectly frees a BIO object that belongs to the calling application. The application doesn’t know the BIO has been freed. When it subsequently accesses or frees that same BIO, you get a use-after-free—and depending on heap layout and attacker control, you can end up with process crashes, heap corruption, or in the worst case, arbitrary code execution.
The attack vector matters here. We’re talking about network-accessible RCE for any service that accepts and verifies PKCS#7 or S/MIME signed messages from untrusted sources. Think mail servers processing signed email. Think enterprise applications validating signed API payloads. Think code signing verification pipelines. If those pipelines call the PKCS7 API path (rather than the CMS API—which is not affected), they’re exposed.
Seven Branches. That’s the Problem.
What sets this advisory apart from most OpenSSL patches is the breadth of affected versions. CVE-2026-45447 affects:
- OpenSSL 4.0 (current)
- OpenSSL 3.6
- OpenSSL 3.5
- OpenSSL 3.4
- OpenSSL 3.0 (LTS)
- OpenSSL 1.1.1 (EOL September 2023)
- OpenSSL 1.0.2 (EOL December 2019)
Let me dwell on those last two lines. OpenSSL 1.1.1 reached end of life almost three years ago. OpenSSL 1.0.2 has been unsupported since December 2019—six and a half years. And yet both branches are vulnerable to this bug, and both are almost certainly still running in production somewhere in your stack or your vendors’ stacks right now.
I know this because I’ve seen it. Embedded devices shipping with 1.0.2 in 2026. Vendor appliances that haven’t been updated since they left the factory floor. Containerized workloads built on base images nobody updated after Docker Hub rotated them. In fifteen years of operating hosting environments, the single most reliable thing I’ve learned about software dependencies is that organizations dramatically underestimate how many places a given library is actually running.
The patched targets from OpenSSL are: 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. For the legacy 1.1.1 and 1.0.2 lines, fixes exist but only under OpenSSL’s premium extended support program—1.1.1zh and 1.0.2zq respectively. If you’re on those branches without a support contract, you have two real options: pay for it, or migrate off the branch. The window for “we’ll deal with it later” closed a long time ago.
How This Bug Was Found—and What That Signals
Here’s the detail that caught my attention in the SecurityWeek coverage: CVE-2026-45447 was discovered by Thai Duong at Calif.io working in collaboration with Claude AI and Anthropic Research. Separately, Alex Gaynor of Anthropic is credited with reporting approximately six of the newly patched vulnerabilities in this same advisory.
I want to be careful not to oversell this. AI-assisted code analysis is a real and growing technique, but it doesn’t replace deep human expertise—Duong is a cryptography researcher with decades of credibility in this space. What it does suggest is that the tooling for auditing foundational C libraries is improving. Use-after-free bugs in OpenSSL’s PKCS7 verification path aren’t new territory; the fact that one this significant was still hiding there in 2026, across all major version branches, tells you something about how hard this kind of audit historically has been.
It also raises a question I’ve been sitting with: if an AI-assisted pass found a 9.8-severity bug in one of the most scrutinized open-source projects on the planet, how many similar bugs are sitting in less-scrutinized libraries that we’re equally dependent on? The answer is almost certainly uncomfortable.
The Secondary CVEs Worth Your Attention
Beyond CVE-2026-45447, the advisory includes several Moderate-severity findings worth understanding:
- CVE-2026-34182: Affects CMS AuthEnvelopedData processing in OpenSSL 3.0 through 4.0—relevant for anyone using CMS-based encrypted or authenticated envelopes.
- CVE-2026-34183: Affects OpenSSL 3.4 through 4.0. Review the official advisory for deployment-specific impact.
- CVE-2026-35188: Affects only 3.6 and 4.0—narrower blast radius, but if you’re on those branches, it ships in the same patch that fixes the critical.
The remaining Low-severity CVEs span nearly every branch. Several affect 1.1.1 and 1.0.2, reinforcing the message that if you’re still on those branches, you’re accumulating vulnerability debt faster than you can track it.
What to Do Right Now
If you’re an infrastructure operator, here’s my checklist for the next 72 hours:
- Inventory your OpenSSL versions. Run
openssl versionon every host you manage. Better yet, use your configuration management system—Ansible, Chef, Puppet—to sweep for it. Don’t forget containers.docker exec <container> openssl versionor scanning your image manifests will surface surprises. - Prioritize services that process PKCS#7 or S/MIME. Mail servers, enterprise email gateways, code signing services, any application that validates signed documents or messages. These are your highest-risk exposure points for CVE-2026-45447 specifically.
- Patch to the fixed versions. Target 4.0.1, 3.6.3, 3.5.7, 3.4.6, or 3.0.21 depending on your branch. Most Linux distributions will have packages available now or within the next day or two via their security repos.
- If you’re on 1.1.1 or 1.0.2 without a support contract, treat this as a migration trigger. The patches exist but are behind a paywall. Use this as organizational leverage to move off the EOL branch. This is your moment—you have a CVSS 9.8 CVE to put in the ticket.
- Check your vendor appliances and embedded systems. Routers, load balancers, VPN concentrators, network monitoring appliances. These often ship with pinned OpenSSL versions and require firmware updates from the vendor. File the inquiry now—vendor patch cycles are slow and you want to be in their queue.
The Bigger Picture
OpenSSL has come a long way since Heartbleed in 2014. The project’s security posture, code review process, and disclosure practices have matured significantly. This advisory actually demonstrates that maturity: sixteen CVE entries, clearly documented, with fixed versions available on publication day. That’s how it should work.
But the breadth of this vulnerability—spanning seven major release branches, including two that have been end-of-life for years—is a reminder that cryptographic library debt accumulates quietly and settles loudly. The code behind PKCS7_verify() has been in the OpenSSL tree for a very long time. The fact that a use-after-free at CVSS 9.8 survived in that codebase until 2026, and required a collaboration between a seasoned researcher and AI-assisted analysis to surface it, should give everyone responsible for production systems pause.
We are collectively running more legacy cryptographic infrastructure than we admit, on more systems than we’ve fully inventoried, with update cadences that lag behind the threat landscape. This advisory won’t be the last one to hit all seven branches. Treat it as the fire drill that finally motivates a complete audit of what OpenSSL version is actually running where in your environment.
Patch your servers. Then do the inventory. In that order.