Heap Use-After-Free in OpenSSL PKCS7verify()

Heap Use-After-Free in OpenSSL PKCS7verify() (CVE-2026-45447) Severity: High

Issue summary: A specially crafted PKCS#7 or S/MIME signed message could trigger a use-after-free during PKCS#7 signature verification.

Impact summary: A use-after-free may result in process crashes, heap corruption, or potentially remote code execution.

When processing a PKCS#7 or S/MIME signed message, if the SignedData digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may incorrectly free a caller-owned BIO during PKCS7verify(). A subsequent use of the BIO by the calling application results in a use-after-free condition.

In the common case this occurs when the application later calls BIOfree() on the BIO originally passed to PKCS7verify(). Depending on allocator behavior and application-specific BIO usage patterns, this may result in a crash or other memory corruption. In some application contexts this may potentially be exploitable for remote code execution.

Applications that process PKCS#7 or S/MIME signed messages using OpenSSL PKCS#7 APIs may be affected. Applications using the CMS APIs for this processing are not affected.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.

OpenSSL 4.0, 3.6, 3.5, 3.4, 3.0, 1.1.1, and 1.0.2 are vulnerable to this issue.

OpenSSL 4.0 users should upgrade to OpenSSL 4.0.1 OpenSSL 3.6 users should upgrade to OpenSSL 3.6.3. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.7. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.6. OpenSSL 3.0 users should upgrade to OpenSSL 3.0.21. OpenSSL 1.1.1 users should upgrade to OpenSSL 1.1.1zh (premium support customers only). OpenSSL 1.0.2 users should upgrade to OpenSSL 1.0.2zq (premium support customers only).

This issue was reported by Thai Duong (Calif.io in collaboration with Claude and Anthropic Research). on 27th April 2026. The fix was developed by Igor Ustinov.

Issue summary: During processing of a crafted CMS EnvelopedData message with KeyTransportRecipientInfo a NULL pointer dereference can happen.

Impact summary: Applications that process attacker-controlled CMS data may crash before authentication or cryptographic operations occur resulting in Denial of Service.

When a CMS EnvelopedData message that uses KeyTransportRecipientInfo with RSA-OAEP encryption is processed, the optional parameters field of RSA-OAEP SourceFunc algorithm identifier is examined without checking for its presence. This results in a NULL pointer dereference if the field is missing.

Applications and services that call CMSdecrypt() on untrusted input (e.g., S/MIME processing or CMS-based protocols) are vulnerable.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.

Issue summary: A type confusion vulnerability exists in the signature verification of signed PKCS#7 data where an ASN1TYPE union member is accessed without first validating the type, causing an invalid or NULL pointer dereference when processing malformed PKCS#7 data.

Impact summary: An application performing signature verification of PKCS#7 data or calling directly the PKCS7digestfromattributes() function can be caused to dereference an invalid or NULL pointer when reading, resulting in a Denial of Service.

The function PKCS7digestfromattributes() accesses the message digest attribute value without validating its type. When the type is not VASN1OCTETSTRING, this results in accessing invalid memory through the ASN1TYPE union, causing a crash.

Exploiting this vulnerability requires an attacker to provide a malformed signed PKCS#7 to an application that verifies it. The impact of the exploit is just a Denial of Service, the PKCS7 API is legacy and applications should be using the CMS API instead. For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS#7 parsing implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointer dereference in the PKCS12itemdecryptd2iex() function.

Impact summary: A NULL pointer dereference can trigger a crash which leads to Denial of Service for an application processing PKCS#12 files.

The PKCS12itemdecryptd2iex() function does not check whether the oct parameter is NULL before dereferencing it. When called from PKCS12unpackp7encdata() with a malformed PKCS#12 file, this parameter can be NULL, causing a crash. The vulnerability is limited to Denial of Service and cannot be escalated to achieve code execution or memory disclosure.

Exploiting this issue requires an attacker to provide a malformed PKCS#12 file to an application that processes it. For that reason the issue was assessed as Low severity according to our Security Policy.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Issue summary: Writing large, newline-free data into a BIO chain using the line-buffering filter where the next BIO performs short writes can trigger a heap-based out-of-bounds write.

Impact summary: This out-of-bounds write can cause memory corruption which typically results in a crash, leading to Denial of Service for an application.

The line-buffering BIO filter (BIOflinebuffer) is not used by default in TLS/SSL data paths. In OpenSSL command-line applications, it is typically only pushed onto stdout/stderr on VMS systems. Third-party applications that explicitly use this filter with a BIO chain that can short-write and that write large, newline-free data influenced by an attacker would be affected. However, the circumstances where this could happen are unlikely to be under attacker control, and BIOflinebuffer is unlikely to be handling non-curated data controlled by an attacker. For that reason the issue was assessed as Low severity.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the BIO implementation is outside the OpenSSL FIPS module boundary.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Heap Buffer Over-read in ASN.1 Content Parsing

Issue summary: A signed integer overflow when sizing the destination buffer for Unicode output in ASN1mbstringncopy() can lead to a heap buffer overflow.

Issue summary: When CMS password-based decryption (RFC 3211 / PWRI key unwrap) processes attacker-supplied CMS data, an attacker-chosen stream-mode KEK cipher can trigger a heap out-of-bounds read in kekunwrapkey().

Issue summary: A specially crafted password-encrypted CMS message can trigger a NULL pointer dereference during CMS decryption.

Issue summary: During processing of a crafted CMS EnvelopedData message with KeyAgreeRecipientInfo a NULL pointer dereference can happen.

Impact summary: Applications that process attacker-controlled CMS data may crash before authentication or cryptographic operations occur resulting in Denial of Service.

When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier is examined without checking for its presence. This results in a NULL pointer dereference if the field is missing.

Applications and services that call CMSdecrypt() on untrusted input (e.g., S/MIME processing or CMS-based protocols) are vulnerable.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.

Issue summary: When a delta CRL that contains a Delta CRL Indicator extension is processed a NULL pointer dereference might happen if the required CRL Number extension is missing.

Impact summary: A NULL pointer dereference can trigger a crash which leads to a Denial of Service for an application.

When CRL processing and delta CRL processing is enabled during X.509 certificate verification, the delta CRL processing does not check whether the CRL Number extension is NULL before dereferencing it. When a malformed delta CRL file is being processed, this parameter can be NULL, causing a NULL pointer dereference.

Exploiting this issue requires the X509VFLAGUSEDELTAS flag to be enabled in the verification context, the certificate being verified to contain a freshestCRL extension or the base CRL to have the EXFLAGFRESHEST flag set, and an attacker to provide a malformed CRL to an application that processes it.

The vulnerability is limited to Denial of Service and cannot be escalated to achieve code execution or memory disclosure. For that reason the issue was assessed as Low severity according to our Security Policy.

The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.

A flaw was found in OpenSSL. The crehash script does not properly sanitize shell meta-characters to prevent command injection. Some operating systems distribute this script in a manner where it is automatically executed. This flaw allows an attacker to execute arbitrary commands with the privileges of the script on these operating systems.

A flaw was found in OpenSSL. It is possible to trigger an infinite loop by crafting a certificate that has invalid elliptic curve parameters. Since certificate parsing happens before verification of the certificate signature, any process that parses an externally supplied certificate may be subject to a denial of service attack.

Applications that use the functions DHcheck(), DHcheckex() or EVPPKEYparamcheck() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.

Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications when using the "-check" option.

The OpenSSL SSL/TLS implementation is not affected by this issue.

The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

http://www.openwall.com/lists/oss-security/2023/07/19/4 http://www.openwall.com/lists/oss-security/2023/07/19/5 http://www.openwall.com/lists/oss-security/2023/07/19/6 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=1fa20cf2f506113c761777127a38bce5068740eb https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=8780a896543a654e757db1b9396383f9d8095528 https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=9a0a4d3c1e7138915563c0df4fe6a3f9377b839c https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fc9867c1e03c22ebf56943be205202e576aabf23 https://www.openssl.org/news/secadv/20230719.txt

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

OpenSSL Security Advisory [31st July 2023] ==========================================

Excessive time spent checking DH q parameter value (CVE-2023-3817) ==================================================================

Severity: Low

Issue summary: Checking excessively long DH keys or parameters may be very slow.

Impact summary: Applications that use the functions DHcheck(), DHcheckex() or EVPPKEYparamcheck() to check a DH key or DH parameters may experience long delays. Where the key or parameters that are being checked have been obtained from an untrusted source this may lead to a Denial of Service.

The function DHcheck() performs various checks on DH parameters. After fixing CVE-2023-3446 it was discovered that a large q parameter value can also trigger an overly long computation during some of these checks. A correct q value, if present, cannot be larger than the modulus p parameter, thus it is unnecessary to perform these checks if q is larger than p.

An application that calls DHcheck() and supplies a key or parameters obtained from an untrusted source could be vulnerable to a Denial of Service attack.

The function DHcheck() is itself called by a number of other OpenSSL functions. An application calling any of those other functions may similarly be affected. The other functions affected by this are DHcheckex() and EVPPKEYparamcheck().

Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications when using the "-check" option.

The OpenSSL SSL/TLS implementation is not affected by this issue.

The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.

OpenSSL 3.1, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Due to the low severity of this issue we are not issuing new releases of OpenSSL at this time. The fix will be included in the next releases when they become available. The fix is also available in commit 6a1eb62c2 (for 3.1), commit 9002fd073 (for 3.0) and commit 91ddeba0f (for 1.1.1) in the OpenSSL git repository. It is available to premium support customer in commit 869ad69a (for 1.0.2).

This issue was reported on 20th July 2023 by Bernd Edlinger. The fix was developed by Tomas Mraz.

General Advisory Notes ======================

URL for this Security Advisory: https://www.openssl.org/news/secadv/20230731.txt

Note: the online version of the advisory may be updated with additional details over time.

For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html

OpenSSL 1.1.1 will reach end-of-life on 2023-09-11. After that date security fixes for 1.1.1 will only be available to premium support customers. -----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAmTH1M4ACgkQ2cTSbQ5g RJGhtAf9E3HklBKezKOXvAbsPmCqcjySMVTV/JrBjrDn14UIRjZmhVoHd5QGusN2 ReRtA3bRL41UQYdLKDkdYjp9XmlDDFb5hKO3G7P0ldtDaw21TkIQeI/90OKjgsQu A+vpf/TcE1a1Pbz8cIRKYBjIaS3z9yIDW4eB0gytWxsqMxze+9IOYNuAbDa0KsqO PFTUiHr5xu01wsdVdHeUMpZ01E8tGbVwgyY7tvCUAUJcjjLcTb9+gXQLn6cmVRJt 6kU8jsamkiYpL1MoKI5yQvYx0nXZUxXbH1ICPltytC4pBsMEypCCnJTkcJKhRRNt 76Z4/x3XDqMzapYMPimIRifdzPV9FQ== =Ve/V -----END PGP SIGNATURE-----

Excessive time spent in DH check / generation with large Q parameter value

A flaw was found in OpenSSL. The issue in CVE-2022-1292 did not find other places in the crehash script where it possibly passed the file names of certificates being hashed to a command executed through the shell. Some operating systems distribute this script in a manner where it is automatically executed. On these operating systems, this flaw allows an attacker to execute arbitrary commands with the privileges of the script.

In situations where an attacker receives automated notification of the ...

ECDSA remote timing attack

A vulnerability was found in OpenSSL 1.0.2. When an application encounters a fatal protocol error and then calls SSLshutdown() twice, OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. This difference in behaviour can be detected by a remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Also the application must call SSLshutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). AEAD ciphersuites are not impacted. This issue does not impact OpenSSL 1.1.1 or 1.1.0.

Upstream bug: https://www.openssl.org/news/secadv/20190226.txt

Upstream Patch: https://github.com/openssl/openssl/commit/e9bbefbf0f24c57645e7ad6a5a71ae649d18ac8e

Issue summary: Processing some specially crafted ASN.1 object identifiers or data containing them may be very slow.

Impact summary: Applications that use OBJobj2txt() directly, or use any of the OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no message size limit may experience notable to very long delays when processing those messages, which may lead to a Denial of Service.

A security vulnerability has been identified in all supported versions

of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems.

Policy processing is disabled by default but can be enabled by passing the -policy' argument to the command line utilities or by calling the X509VERIFYPARAMset1policies()' function.

Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks.

Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether.

Policy processing is disabled by default but can be enabled by passing the -policy' argument to the command line utilities or by calling the X509VERIFYPARAMset1policies()' function.

Certificate policy check not enabled

A timing based side channel exists in the OpenSSL RSA Decryption implementation which could be sufficient to recover a plaintext across a network in a Bleichenbacher style attack. To achieve a successful decryption an attacker would have to be able to send a very large number of trial messages for decryption. The vulnerability affects all RSA padding modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.

For example, in a TLS connection, RSA is commonly used by a client to send an encrypted pre-master secret to the server. An attacker that had observed a genuine connection between a client and a server could use this flaw to send trial messages to the server and record the time taken to process them. After a sufficiently large number of messages the attacker could recover the pre-master secret used for the original connection and thus be able to decrypt the application data sent over that connection.

A type confusion vulnerability was found in OpenSSL when OpenSSL X.400 addresses processing inside an X.509 GeneralName. When CRL checking is enabled (for example, the application sets the X509VFLAGCRLCHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or cause a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, of which neither needs a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. In this case, this vulnerability is likely only to affect applications that have implemented their own functionality for retrieving CRLs over a network.

A use-after-free vulnerability was found in OpenSSL's BIOnewNDEF function. The public API function BIOnewNDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally by OpenSSL to support the SMIME, CMS, and PKCS7 streaming capabilities, but it may also be called directly by end-user applications. The function receives a BIO from the caller, prepends a new BIOfasn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions. For example, if a CMS recipient public key is invalid, the new filter BIO is freed, and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up, and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then calls BIOpop() on the BIO, a use-after-free will occur, possibly resulting in a crash.

An OOB read flaw was found in the RFC 3161 Public Key Infrastructure Time-Stamp Protocol code of OpenSSL. An attacker could use this flaw to cause the openssl binary to crash when specially-crafted time-stamp file is parsed via the "openssl ts" command.

Upstream commit:

master: https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca37365e8c7403a 1.0.1: https://github.com/openssl/openssl/commit/6adf409c7432b90c06d9890787fe56c48f2a16e7

ASN.1 strings are represented internally within OpenSSL as an ASN1STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1STRINGset() function will additionally NUL terminate the byte array in the ASN1STRING structure. However, it is possible for applications to directly construct valid ASN1STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1STRING array. This can also happen by using the ASN1STRINGset0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1STRING structures). It can also occur in the X509get1email(), X509REQget1email() and X509get1ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).

An issue was discovered in openfortivpn 1.11.0 when used with OpenSSL 1.0.2 or later. tunnel.c mishandles certificate validation because an X509checkhost negative error code is interpreted as a successful return value.