OpenSSL’s June 9 Advisory Covers 16 CVEs Across Seven Release Branches

OpenSSL published a security advisory on June 9, 2026, covering 16 CVE identifiers and 18 individual vulnerabilities. The most serious reported issue is CVE-2026-45447, a heap use-after-free in PKCS7_verify() with a CVSS v3.1 score of 9.8, or Critical. Under the right conditions, it could allow remote code execution.

The flaw affects seven release branches, from OpenSSL 1.0.2 through 4.0. Services that accept and verify PKCS#7 or S/MIME signed messages from untrusted sources need urgent attention. Running OpenSSL for TLS alone doesn't establish exposure to this particular bug; the application has to reach the affected verification path.

How the PKCS7 flaw works

The June 9 OpenSSL security advisory describes a problem with the handling of signed messages. If a message contains a SignedData.digestAlgorithms field represented as an empty ASN.1 SET, OpenSSL incorrectly frees a BIO object owned by the calling application. A BIO is an OpenSSL object used to handle input and output.

The application still holds a reference to that object and doesn't know its memory has been released. Accessing it again creates a use-after-free. Attempting to free it again can also corrupt memory. Depending on the heap layout and the attacker's control over the process's memory, the result can range from a crash to heap corruption or arbitrary code execution.

This gives the flaw a potential network attack path in services that verify untrusted signed messages. Relevant examples include mail servers processing S/MIME email, enterprise applications checking signed API payloads, and code-signing verification pipelines. Exposure depends on whether those applications use the affected PKCS7 API path.

The CMS API is not affected by CVE-2026-45447. That distinction matters when assessing an application's risk. Support for signed messages alone isn't enough to establish that it uses the vulnerable code, and the advisory includes separate CMS findings that still need review.

Affected branches and fixed releases

The affected versions span both current releases and branches that have been out of standard support for years. The fixed targets are:

OpenSSL 1.1.1 had been out of standard support for almost three years by the time of this advisory. For 1.0.2, the gap was about six and a half years. Both remain affected by the flaw.

Fixes for those two legacy branches are available through OpenSSL's premium extended support program. Organizations relying on upstream OpenSSL releases without an extended support contract face a choice between obtaining that support and moving to a supported branch. The existence of a fix doesn't mean it is freely available for every affected version.

The practical problem is finding every copy that needs attention. A host's installed package is only part of the inventory. Containers, embedded devices, and vendor appliances also need checking, especially where base images or firmware have not been maintained. A quick apt-get upgrade on a server isn't a complete response to that wider dependency problem.

AI-assisted discovery and its limits

According to SecurityWeek's coverage, Thai Duong at Calif.io discovered CVE-2026-45447 in collaboration with Claude AI and Anthropic Research. Alex Gaynor of Anthropic is separately credited with reporting approximately six of the vulnerabilities patched in the same advisory.

That is a useful example of AI-assisted security research, though it doesn't show that automated analysis can replace specialist review. Duong is an experienced cryptography researcher. The finding came from a collaboration involving that expertise, rather than evidence that a tool could independently audit the library.

The discovery suggests that tools for auditing foundational C libraries are improving. It also shows how difficult these audits remain: a use-after-free in a long-standing verification path affected seven major branches before being found. Less closely reviewed libraries may contain similar defects, but this advisory doesn't establish how many or where they are.

Other CVEs to review

Most findings in the advisory are rated Low or Moderate. Several Moderate-severity issues deserve attention alongside CVE-2026-45447:

• CVE-2026-34182 affects CMS AuthEnvelopedData processing in OpenSSL 3.0 through 4.0. Applications using CMS-based encrypted or authenticated envelopes should review their exposure.
• CVE-2026-34183 affects OpenSSL 3.4 through 4.0. The official advisory provides the details needed to assess deployment-specific impact.
• CVE-2026-35188 affects only OpenSSL 3.6 and 4.0. Its version range is narrower, and the same release updates address it alongside the PKCS7 flaw.

The remaining Low-severity findings span nearly every branch, including several that affect 1.1.1 and 1.0.2. A review focused only on the highest CVSS score would miss other reasons to update, particularly for applications that use different OpenSSL APIs.

Priorities for the next 72 hours

Patch planning should start with known exposed services while the broader inventory proceeds. The highest priority for CVE-2026-45447 is an application that accepts untrusted signed data and passes it through the affected PKCS7 verification path.

1. Inventory OpenSSL versions across hosts and containers. Run openssl version on managed hosts, or use Ansible, Chef, or Puppet to collect version information. For containers, docker exec <container> openssl version and image-manifest scanning can help identify versions needing review. Include workloads built from older base images.
2. Identify services that process PKCS#7 or S/MIME. Check mail servers, enterprise email gateways, code-signing services, and applications that validate signed documents or messages. Confirm the API path rather than assuming all signed-message processing has the same exposure.
3. Install the applicable fixed release. The upstream targets are 4.0.1, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. As of June 14, distribution security packages were expected to be available already or within the following day or two. Check the relevant distribution's security repository for availability rather than treating that expectation as confirmation.
4. Resolve the support gap for legacy branches. For 1.1.1 and 1.0.2 deployments without an extended support contract, treat this advisory as a reason to schedule migration urgently. The legacy fixes are 1.1.1zh and 1.0.2zq, available under premium extended support.
5. Contact appliance and embedded-system vendors. Routers, load balancers, VPN concentrators, and network-monitoring appliances may use pinned OpenSSL versions and require firmware updates. Request affected-version details and a patch timetable promptly, since vendor update cycles can take longer than a standard package update.

OpenSSL's security review and disclosure practices have improved substantially since Heartbleed in 2014. Publishing a documented advisory with fixed releases available on disclosure day is a useful part of that progress. Deployment remains the operator's responsibility, with an additional dependency on vendors where the library is bundled into a product.

Known exposed services shouldn't wait for a perfect organization-wide inventory before being patched. The inventory still needs to be completed, particularly for older containers and appliances that won't be updated by patching the host operating system.