OpenSSL Fixes High-Severity Vulnerability That Can Lead to Remote Code Execution

OpenSSL has released security updates for a high-severity vulnerability that can cause crashes, heap corruption, or potential remote code execution in some applications.

The flaw is tracked as CVE-2026-45447 and affects OpenSSL’s PKCS7_verify() function. According to the OpenSSL vulnerability advisory, a specially crafted PKCS#7 or S/MIME signed message can trigger a use-after-free during signature verification.

The risk depends on how an application uses OpenSSL. Systems that only use OpenSSL for ordinary TLS connections may not hit the vulnerable code path, but mail gateways, S/MIME tools, document-processing systems, and applications that verify PKCS#7 signatures should receive urgent attention.

What CVE-2026-45447 does

CVE-2026-45447 is a heap use-after-free bug in PKCS7_verify(). The vulnerability occurs when OpenSSL processes a signed message where the SignedData digestAlgorithms field appears as an empty ASN.1 SET.

The NVD record says OpenSSL may incorrectly free a caller-owned BIO object during PKCS#7 verification. If the calling application later uses or frees that same BIO object, the application can hit a use-after-free condition.

That condition can result in a crash or memory corruption. In some application-specific situations, OpenSSL says the flaw may potentially allow remote code execution.

CVE	CVE-2026-45447
Component	OpenSSL PKCS7_verify()
Vulnerability type	Heap use-after-free
Severity from OpenSSL	High
Main attack input	Crafted PKCS#7 or S/MIME signed message
Possible impact	Crash, heap corruption, or potential remote code execution
Affected code path	Applications using OpenSSL PKCS#7 APIs for signature verification
Not affected by this bug	Applications using CMS APIs for the same processing

Affected OpenSSL versions and fixed releases

The vulnerable versions include OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1, and 1.0.2 before the patched releases. The OpenSSL GitHub releases list the June 9, 2026 updates as security patch releases.

Administrators should update to OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6, or 3.0.21. Customers who still receive premium support for legacy branches should move to OpenSSL 1.1.1zh or 1.0.2zq.

The FIPS modules for OpenSSL 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by CVE-2026-45447 because the vulnerable code sits outside the OpenSSL FIPS module boundary.

OpenSSL branch	Vulnerable versions	Fixed version
4.0	4.0.0	4.0.1
3.6	3.6.0 before 3.6.3	3.6.3
3.5	3.5.0 before 3.5.7	3.5.7
3.4	3.4.0 before 3.4.6	3.4.6
3.0	3.0.0 before 3.0.21	3.0.21
1.1.1	1.1.1 before 1.1.1zh	1.1.1zh, premium support customers only
1.0.2	1.0.2 before 1.0.2zq	1.0.2zq, premium support customers only

Why the flaw can be serious

Use-after-free bugs can become dangerous because they involve memory that an application believes it can still use. If an attacker can influence memory layout and input timing, the bug may move beyond a crash and become a code execution primitive.

The NVD description notes that exploitation depends on allocator behavior and application-specific BIO usage patterns. That detail matters because the same vulnerable OpenSSL library can create different levels of risk in different products.

For example, a public-facing service that automatically verifies untrusted S/MIME content faces a different risk profile than an internal tool that never processes attacker-controlled signed messages.

Other OpenSSL issues fixed in the same update

CVE-2026-45447 received the most attention because it can potentially lead to remote code execution. However, the June 9 OpenSSL updates also fixed several other issues across CMS, QUIC, AES-OCB, ASN.1, PKCS#12, CMP, and related code paths.

The release notes list fixes for CMS AuthEnvelopedData processing, QUIC memory growth, NULL pointer dereferences, AES-OCB IV handling, ASN.1 parsing, CMS password-based decryption, and other cryptographic workflows.

Some of these flaws mainly cause denial of service. Others can weaken message integrity, enable forgery in narrow cases, or affect custom applications that use lower-level cryptographic interfaces.

• CMS AuthEnvelopedData issues may allow forged messages in certain workflows.
• QUIC bugs may cause memory growth or crashes in affected configurations.
• AES-OCB handling issues may break expected IV behavior in specific EVP_Cipher() usage.
• ASN.1 parsing bugs can trigger crashes or memory corruption in unusual input paths.
• PKCS#12 and CMP issues may affect systems that import or process attacker-controlled certificate data.

Security agencies warn about broader OpenSSL exposure

The CERT-FR advisory warned that multiple OpenSSL vulnerabilities can lead to remote code execution, denial of service, confidentiality impact, integrity impact, or security policy bypass depending on the affected flaw and configuration.

That broad warning does not mean every OpenSSL installation can be remotely exploited. Exposure depends on version, linked applications, enabled features, and whether the application processes untrusted data through vulnerable APIs.

Security teams should inventory products that bundle OpenSSL, not only the system OpenSSL package. Many applications ship their own copy of the library, which means a fully patched operating system may still leave some software exposed.

What administrators should do now

The safest response is to update OpenSSL and restart affected services that link to the library. Package updates may not protect running processes until those services reload or restart.

The OpenSSL advisory says applications that process PKCS#7 or S/MIME signed messages through PKCS#7 APIs may be affected, while applications using CMS APIs for that processing are not affected by CVE-2026-45447.

Organizations that cannot patch immediately should reduce exposure by disabling or isolating features that process untrusted PKCS#7 or S/MIME content, especially on internet-facing systems and automated mail-processing infrastructure.

• Upgrade to the fixed OpenSSL release for your branch.
• Restart services and applications that load OpenSSL.
• Check containers, appliances, embedded products, and vendor-bundled libraries.
• Prioritize S/MIME, PKCS#7, mail gateway, document signing, and certificate-processing systems.
• Review applications that call OpenSSL PKCS#7 APIs on untrusted input.
• Ask vendors for update timelines where OpenSSL is bundled inside third-party products.

Why patching may take more than one update

OpenSSL often sits inside operating systems, servers, developer tools, security products, VPN software, mail systems, and embedded devices. That makes patching more complex than updating one package.

The CERT-FR notice points users to vendor fixes, which is important because downstream Linux distributions and product vendors may ship patched packages on their own schedules.

Administrators should confirm the actual OpenSSL version used by each application, then verify that the fixed library loads after the update. Vulnerability scanners, software bills of materials, package managers, and vendor advisories can all help close that gap.

CVE-2026-45447 deserves priority because it affects widely deployed OpenSSL branches and can lead to severe outcomes in the right application context. Even so, the most accurate response starts with exposure mapping, not panic. The vulnerable path depends on how software handles PKCS#7 and S/MIME signed messages.

FAQ