CVE-2026-45447

What it actually does

This vulnerability is a use-after-free in OpenSSL PKCS#7 signature verification. A specially crafted PKCS#7 or S/MIME signed message with an empty ASN.1 SET in the SignedData digestAlgorithms field can cause PKCS7_verify() to incorrectly free a BIO object owned by the calling application. If the application later reuses or frees that BIO, the process may crash, corrupt heap memory, or, in application-specific circumstances, allow remote code execution. Applications using OpenSSL PKCS#7 APIs to process signed PKCS#7 or S/MIME content are in scope; applications using CMS APIs for the same processing path are not affected. The OpenSSL FIPS modules are not affected because the vulnerable code is outside the FIPS module boundary.

Why it matters to the business

Organizations that operate mail gateways, document-processing systems, secure message processors, certificate/signature validation services, or other software that accepts signed PKCS#7 or S/MIME content could experience service crashes, message-processing outages, or potentially full compromise of the affected application process. The vulnerability is network-reachable in many deployments where signed messages are accepted from users or external parties, and the CVSS severity is high. Although it is not currently listed in CISA KEV and no exploit maturity is reported, affected systems should be prioritized because memory-corruption flaws in widely used cryptographic libraries can have broad downstream operational impact.

How an attack unfolds

An attacker crafts a PKCS#7 or S/MIME signed message whose SignedData digestAlgorithms field is present but encoded as an empty ASN.1 SET. The attacker submits that message to an application that verifies PKCS#7 signatures using OpenSSL PKCS7_verify(). During verification, OpenSSL mishandles ownership of a caller-provided BIO and frees it prematurely. After PKCS7_verify() returns, the application may continue using or later free the same BIO, triggering a use-after-free. In the most common outcome, the affected process crashes, producing a denial of service. In applications where attacker-controlled data influences allocator state or subsequent BIO usage, the same condition may lead to heap corruption and potentially remote code execution.

How to fix it

Upgrade OpenSSL to a vendor-supported version that includes the fix as soon as fixed packages are available from the operating system, appliance, container image, or application vendor. Because no exact fixed versions were provided in the input, track the OpenSSL advisory and downstream vendor security advisories for the corrected release applicable to each deployed package. Rebuild and redeploy statically linked applications, containers, appliances, and language runtimes that bundle OpenSSL rather than relying on the system library. As a mitigation, disable or restrict processing of untrusted PKCS#7 and S/MIME signed messages where feasible, route such content through isolated processing sandboxes, and prefer unaffected CMS APIs instead of legacy PKCS#7 APIs when application changes are possible. The OpenSSL FIPS modules themselves do not require remediation for this issue, but applications using vulnerable non-FIPS PKCS#7 code paths still do.

How to confirm the fix worked

Inventory applications and packages that link to OpenSSL and determine whether they process PKCS#7 or S/MIME signed content through PKCS7_verify(). Confirm deployed OpenSSL package versions against vendor advisories once fixed versions are published. Validate dynamic linkage using package managers, software composition analysis, container image scans, and runtime library inspection. For custom or third-party applications, review code or vendor documentation for use of PKCS7_verify(), PKCS7_* APIs, or S/MIME verification paths. After remediation, retest PKCS#7 and S/MIME verification workflows with benign signed messages and, in a controlled test environment only, malformed PKCS#7 inputs to confirm the process no longer crashes. Also verify that services were restarted or redeployed so the fixed libcrypto is actually loaded.

Typical attack path

1. Identify an internet-facing or remotely reachable application that accepts PKCS#7 or S/MIME signed content.
2. Confirm or infer that the application uses OpenSSL PKCS#7 APIs, especially PKCS7_verify(), rather than CMS APIs.
3. Create a malformed signed PKCS#7 or S/MIME message with SignedData digestAlgorithms encoded as an empty ASN.1 SET.
4. Send the crafted message through the normal processing path, such as email ingestion, message upload, API submission, or signature validation workflow.
5. Trigger OpenSSL to incorrectly free a caller-owned BIO during PKCS#7 verification.
6. Cause the application to reuse or free the BIO after verification, resulting in process crash, heap corruption, or potentially code execution depending on application behavior.

How to detect it

To determine whether exploitation may have already occurred, review logs from applications that process PKCS#7 or S/MIME signed content, including mail gateways, secure message processors, document-signing systems, API upload services, and signature validation components. Look for malformed signed-message processing errors immediately followed by process crashes, segmentation faults, heap corruption messages, abnormal restarts, or core dump creation. Correlate inbound S/MIME emails, PKCS#7 attachments, or signature-verification API requests with crash timestamps. On Linux and Unix-like systems, inspect syslog, journald, application logs, kernel logs, coredumpctl output, crash directories, and service manager restart events for references to libcrypto, OpenSSL, PKCS7_verify(), BIO_free(), double free, use-after-free, malloc corruption, or segmentation faults. On Windows, review Application Event Logs, Windows Error Reporting artifacts, mail/security gateway logs, and crash dumps for faulting modules such as libcrypto DLLs. Preserve suspicious PKCS#7, .p7s, .p7m, .p7b, and S/MIME payloads for offline ASN.1 inspection; a notable suspicious structure is a SignedData digestAlgorithms field that is present but encoded as an empty SET. Because successful exploitation may only appear as a crash, absence of a unique log message does not rule out attempted exploitation.

• PKCS7_verify
• BIO_free
• digestAlgorithms
• empty ASN.1 SET
• SignedData digestAlgorithms
• use-after-free
• double free
• malloc(): memory corruption
• malloc(): corrupted top size
• free(): invalid pointer
• corrupted double-linked list
• segmentation fault
• SIGSEGV
• libcrypto.so
• libcrypto.dll
• .p7s
• .p7m
• .p7b
• application/pkcs7-signature
• application/pkcs7-mime
• smime.p7s
• smime.p7m

What your security team should do

• Prioritize internet-facing mail, document, messaging, certificate, and signature-validation services that accept PKCS#7 or S/MIME content from untrusted sources.
• Ask application and appliance vendors whether their products use OpenSSL PKCS7_verify() and whether patched builds are available.
• Deploy fixed OpenSSL packages or vendor updates promptly when available, and restart affected services to load the corrected library.
• Identify statically linked binaries, containers, and embedded products that bundle OpenSSL and require rebuilds rather than only operating system package updates.
• Temporarily disable, block, or sandbox untrusted PKCS#7 and S/MIME processing where business operations allow.
• Add monitoring for crashes or abnormal restarts in services that perform PKCS#7 or S/MIME verification.
• Review historical logs for malformed S/MIME or PKCS#7 submissions followed by crashes, allocator errors, segmentation faults, or libcrypto/OpenSSL faulting modules.
• Treat suspicious crashes in exposed PKCS#7/S/MIME processing services as potential exploitation attempts and preserve payloads, core dumps, and relevant logs for forensic analysis.