OpenSSL Stack Overflow: CVE-2025-15467 Deep Dive

OpenSSL is one of the most widely deployed open-source cryptographic libraries in the world, and a foundation of modern internet security, providing cryptographic primitives for securely handling the encryption and decryption of sensitive data across millions upon millions of systems and applications. Due to its ubiquitous presence in critical software, OpenSSL is under constant scrutiny from both the security research community and the organizations that depend on it, like Google, which continuously battle-tests its cryptographic code at scale.

The AISLE Research Team recently decided to analyze OpenSSL with our autonomous system and found all 12 of the 12 security vulnerabilities in the January 2026 coordinated release. Despite the extensive testing, fuzzing, and code review that OpenSSL continuously undergoes, our autonomous system found issues that had been hidden since as early as 1998. In this post, we focus on a single high-severity issue, CVE-2025-15467, which shows how a flaw in cryptographic parameter parsing can lead to serious security consequences.

CVE-2025-15467: Stack Buffer Overflow in CMS AuthEnvelopedData Parsing

The vulnerability exists in OpenSSL’s handling of Authenticated Encryption with Associated Data (AEAD) parameters during the decryption of Cryptographic Message Syntax (CMS) messages. CMS is used to encode encrypted or authenticated data into a standard format and is widely deployed in secure email systems (S/MIME) that provide message encryption and digital signing, public key infrastructure workflows, document signing solutions, and enterprise data exchange platforms.

The vulnerability arises in the evp_cipher_get_asn1_aead_params function, which is called from CMS_decrypt(). This function is responsible for extracting AEAD parameters, such as initialization vectors (IVs), from ASN.1-encoded CMS structures and preparing them for use by AEAD ciphers such as AES-GCM. An initialization vector (IV) is a non-secret, per-message value that ensures encryption produces different ciphertexts even when the same plaintext and key are used, providing randomness and protecting against certain cryptographic attacks. A flaw in this parsing logic allowed attacker-controlled input to trigger a stack-based buffer overflow during message decryption.

Affected versions: 3.6.0, from 3.5.0 before 3.5.5, from 3.4.0 before 3.4.4, from 3.3.0 before 3.3.6, from 3.0.0 before 3.0.19.

CMS Message Structure

To understand the issue, it helps to know how CMS messages work. A CMS message is a structured container that combines encrypted or authenticated data with the metadata needed to process it, such as the cryptographic algorithms and parameters in use.

In practice, a CMS message includes the protected content, algorithm identifiers (e.g., AES-GCM), cryptographic parameters like IVs and nonces, recipient key information, and optional authenticated attributes. These elements are encoded as a binary ASN.1 structure and, in email systems like S/MIME, Base64-encoded for transport.

The vulnerability arises during decryption of AES-GCM–based CMS messages, where a maliciously crafted message can manipulate parsing logic. CMS messages are widely used by major email clients such as Microsoft Outlook, Apple Mail, and Mozilla Thunderbird, though their cryptographic implementations may differ.

Root Cause Analysis

When parsing AEAD cipher parameters, OpenSSL needs to extract the IV from the ASN.1-encoded data. The entry point to this functionality is evp_cipher_get_asn1_aead_params(), which is responsible for extracting AEAD parameters from an ASN.1 structure:

C/C++
1int evp_cipher_get_asn1_aead_params(EVP_CIPHER_CTX *c, ASN1_TYPE *type,
2    evp_cipher_aead_asn1_params *asn1_params)
3{
4    int i = 0;
5    long tl;
6    unsigned char iv[EVP_MAX_IV_LENGTH]; ---> 16-byte stack buffer
7    [...]
8    i = ossl_asn1_type_get_octetstring_int(type, &tl, NULL, EVP_MAX_IV_LENGTH);// First call 
9    if (i <= 0)
10        return -1;
11    ossl_asn1_type_get_octetstring_int(type, &tl, iv, i); // Second call, overflowing IV
12
13    memcpy(asn1_params->iv, iv, i); --> second overflow
14    [...]
15}
16

In the first call to ossl_asn1_type_get_octetstring_int (line 8), the function performs a so-called “dry run” by passing data = NULL. This call parses the ASN.1 structure for the sole purpose of determining the length of the IV and authentication tag, without actually copying any data. The intention is to calculate how much memory will be required.

In the second call (line 11), the function performs the actual extraction, copying the initialization vector into a fixed-size stack buffer using the length obtained during the first pass.

C/C++
1	int ossl_asn1_type_get_octetstring_int(const ASN1_TYPE *a, long *num,
2    unsigned char *data, int max_len)
3{
4    [...]
5    ret = asn1_type_get_int_oct(atmp->oct, atmp->num, num, data, max_len);
6    [...]
7}
8

C/C++
1static int asn1_type_get_int_oct(ASN1_OCTET_STRING *oct, int32_t anum,
2    long *num, unsigned char *data, int max_len)
3{
4    int ret = ASN1_STRING_length(oct), n;
5
6    if (num != NULL)
7        *num = anum;
8
9    if (max_len > ret)
10        n = ret;
11    else
12        n = max_len;
13
14    if (data != NULL)// condition trigger after the second call
15        memcpy(data, ASN1_STRING_get0_data(oct), n);// --> overflowing data, which is pointing to IV variable with just 16 bytes 
16
17    return ret;
18}
19

The issue lies in the fact that the IV length is derived directly from the attacker-controlled ASN.1 input and is never actually validated against the true size of the data, allowing an oversized length to be specified by the attacker-controlled input during the copy operation and ultimately leading to a stack buffer overflow.

Attack Overview

The vulnerability is reachable through OpenSSL’s CMS decryption path when processing AES-GCM–encrypted EnvelopedData structures. Any application that attempts to decrypt untrusted CMS using OpenSSL’s CMS API is exposed.

An attacker can exploit this vulnerability by crafting a malicious CMS EnvelopedData message, such as those used by standards-based secure email systems (S/MIME), that encodes AES-GCM parameters with an oversized nonce/initialization vector (IV) in its ASN.1 structure.

As illustrated in Figure 1, this scenario represents one possible attack vector in which an attacker delivers a malicious CMS EnvelopedData message through standards-based secure email systems (S/MIME). Other delivery mechanisms that cause an application to invoke OpenSSL’s CMS decryption path on attacker-controlled input may also reach the vulnerable code.

Figure 1: High-level attack flow for exploiting the OpenSSL CMS AES-GCM parsing vulnerability via a malicious S/MIME encrypted email. The overflow is triggered during CMS decryption setup, prior to cryptographic validation.

During CMS decryption operation on the recipient side, OpenSSL parses the attacker-controlled AEAD parameters contained in the CMS structure. At this stage, the encoded IV length is used to copy data into a fixed 16-byte stack buffer, without enforcing the buffer’s maximum size. Since the supplied IV exceeds 16 bytes, a stack-based buffer overflow occurs, even before any cryptographic validation or key checks are performed on the data itself.

It is important to note that this issue affects the CMS decryption path in OpenSSL (for example, CMS_decrypt() or openssl cms -decrypt). Some S/MIME implementations instead rely on the legacy PKCS#7 decryption path, which is an older cryptographic message format that predates CMS and provides similar functionality for signing and encrypting data (for example, PKCS7_decrypt() or openssl smime -decrypt). This legacy path does not invoke the vulnerable code and is therefore not affected by this specific issue.

Conclusions

Exploiting this vulnerability beyond a denial-of-service condition would require overcoming multiple modern exploit mitigations. In typical builds, stack canaries, address space layout randomization (ASLR), and other hardening mechanisms significantly raise the bar for reliable exploitation. Achieving remote code execution would likely require additional vulnerabilities, such as an information disclosure primitive to leak stack canary values or memory addresses.

While these mitigations make exploitation more difficult, the presence of a stack-based buffer overflow in widely deployed cryptographic parsing code remains a serious security concern. The vulnerability can be triggered through a public API using attacker-controlled input and results in immediate memory corruption during parsing. As such, it represents a reliable denial-of-service condition and a potential building block for more advanced exploitation in the presence of complementary vulnerabilities.

CVE-2025-15467: Stack Buffer Overflow in CMS AuthEnvelopedData Parsing

CMS Message Structure

Root Cause Analysis

Attack Overview

Conclusions

Further Reading