Today, on January 27th, 2026, the OpenSSL project published details on vulnerabilities affecting the OpenSSL Software Library. Impacted versions include 1.0.2, 1.1.1, and the 3.x series (3.0, 3.3, 3.4, 3.5, and 3.6).
The disclosure covers one high-severity, one moderate-severity, and 10 low-severity issues. The high-severity vulnerability could lead to remote code execution (RCE) and is the first RCE issue to receive this severity designation from OpenSSL since CVE-2022-3602.
While the most realistic real-world impact across these issues is denial of service (DoS), the vulnerabilities are relevant to any environment that parses untrusted Cryptographic Message Syntax (CMS) or PKCS#12 data using affected OpenSSL versions. Tooling that may ingest these formats include S/MIME gateways, certificate import/export services, PKI/CA tooling, or apps that accept uploaded CMS/PKCS#12 files.
Key points and observations
- CVE-2025-15467 (High): A pre-authentication stack buffer overflow in CMS AuthEnvelopedData AEAD parsing affecting OpenSSL 3.0, 3.3, 3.4, 3.5, 3.6. FIPS modules for the 3.x series are not affected by this issue. A crafted CMS message with an oversized IV can trigger a crash and potentially enable code execution.
- CVE-2025-11187 (Moderate): A stack buffer overflow during PKCS#12 MAC verification when PBKDF2 key length is attacker-controlled, leading to denial of service or potentially RCE. This affects OpenSSL 3.4, 3.5, and 3.6. The FIPS modules in the 3.x series are not affected by this issue.
How to know if you are affected
You may be impacted if your application or service:
- Parses untrusted CMS AuthEnvelopedData, commonly used in S/MIME and PKCS#7 workflows (for example, S/MIME-capable mail clients or email security gateways that decrypt inbound encrypted email)
- Verifies MACs on untrusted PKCS#12 files, such as during certificate import
The table below summarizes the affected versions:
| CVE | Affected versions | Vulnerable surface |
|---|---|---|
| CVE-2025-15467 | 3.0, 3.3, 3.4, 3.5, 3.6 | CMS AuthEnvelopedData AEAD params |
| CVE-2025-11187 | 3.4, 3.5, 3.6 | PKCS#12 PBMAC1 MAC verification |
Additional version notes:
- OpenSSL 3.0 and 3.3 are not affected by CVE-2025-11187 because they do not support PBMAC1 in PKCS#12.
- None of the FIPS modules are affected by these vulnerabilities.
If your OS/base image includes a vulnerable OpenSSL build, then any application that uses that OpenSSL to parse untrusted CMS AuthEnvelopedData or PKCS#12 inputs may be affected. If you only use OpenSSL for TLS handshakes (and never accept CMS/PKCS#12 from untrusted sources), these issues are unlikely to be reachable.
If you’re using an application runtime that packages its own OpenSSL version, such as Node.js, you need to upgrade the runtime itself. Upgrading the operating system openssl package is not enough.
Other languages like Go use their own TLS implementation and do not leverage OpenSSL. Consequently, these are not affected. Rust applications need to be handled on a case-by-case basis, since they can either use the rustls implementation or the OpenSSL bindings using the system-wide version.
For provider-specific guidance, refer to the specific security bulletins.
Analysis and exploitation of the vulnerabilities
CVE-2025-15467: CMS AuthEnvelopedData AEAD IV stack overflow
CMS AuthEnvelopedData combines encryption and authentication and is commonly used in S/MIME. When AEAD ciphers such as AES-GCM are selected, the IV is carried in ASN.1 parameters alongside the ciphertext.
The vulnerability resides in evp_cipher_get_asn1_aead_params() (OpenSSL 3.6.0 shown below as a reference).
int evp_cipher_get_asn1_aead_params(EVP_CIPHER_CTX *c, ASN1_TYPE *type,
evp_cipher_aead_asn1_params *asn1_params)
{
int i = 0;
long tl;
unsigned char iv[EVP_MAX_IV_LENGTH];
if (type == NULL || asn1_params == NULL)
return 0;
i = ossl_asn1_type_get_octetstring_int(type, &tl, NULL, EVP_MAX_IV_LENGTH);
if (i <= 0)
return -1;
ossl_asn1_type_get_octetstring_int(type, &tl, iv, i);
memcpy(asn1_params->iv, iv, i);
asn1_params->iv_len = i;
return i;
}The function first calls ossl_asn1_type_get_octetstring_int() to read the ASN.1 octet string length and then uses that returned length as the maximum for a second call that copies into iv[EVP_MAX_IV_LENGTH]. The helper returns the full length even when it exceeds EVP_MAX_IV_LENGTH, so the second call can copy more than the fixed-size stack buffer can hold.
Because this occurs before authentication, a crafted CMS message can crash the process without requiring any valid cryptographic material. The attacker controls both the length and the content copied into the stack buffer, which is why this is the highest-risk of the two vulnerabilities covered in this article.
A denial of service condition can be demonstrated with a specially crafted PEM file:
nick@test-cattle:/tmp$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
nick@test-cattle:/tmp$ openssl cms -decrypt \
-in temp/encDataWithTooLongIV.pem \
-inform PEM \
-recip temp/servercert.pem \
-inkey temp/serverkey.pem -noout
*** stack smashing detected ***: terminated
Aborted (core dumped)While code execution is possible due to the stack-based write primitives, real-world exploitability will be hampered by platform and toolchain mitigations.
CVE-2025-11187: PBMAC1 PBKDF2 key length validation failure
PBMAC1 is used for MAC verification in PKCS#12 and relies on PBKDF2 to derive a key from a password. Again, using OpenSSL 3.6.0 as a reference:
static int PBMAC1_PBKDF2_HMAC(OSSL_LIB_CTX *ctx, const char *propq,
const char *pass, int passlen,
const X509_ALGOR *macalg, unsigned char *key)
{
/* ...snip... */
pbkdf2_param = PBMAC1_get1_pbkdf2_param(macalg);
if (pbkdf2_param == NULL) {
ERR_raise(ERR_LIB_PKCS12, ERR_R_UNSUPPORTED);
goto err;
}
keylen = ASN1_INTEGER_get(pbkdf2_param->keylength);
pbkdf2_salt = pbkdf2_param->salt->value.octet_string;
/* ...snip... */
if (PKCS5_PBKDF2_HMAC(pass, passlen, pbkdf2_salt->data, pbkdf2_salt->length, ASN1_INTEGER_get(pbkdf2_param->iter), kdf_md, keylen, key) <= 0) {
ERR_raise(ERR_LIB_PKCS12, ERR_R_INTERNAL_ERROR);
goto err;
}
ret = keylen;
/* ...snip... */
return ret;
}In OpenSSL 3.4 and later, the PBKDF2 parameters are taken directly from the file. PBMAC1_PBKDF2_HMAC() passes the ASN.1-controlled keylength directly to PKCS5_PBKDF2_HMAC(), which writes the derived key into a fixed stack buffer, key[EVP_MAX_MD_SIZE] (64 bytes). A crafted PKCS#12 file that sets keylength above 64 causes PBKDF2 to overflow the stack during MAC verification. The same code path also dereferences a salt field without verifying that it is an OCTET STRING, which can cause invalid or NULL pointer dereferences.
A denial of service can be reproduced with a crafted PKCS#12 file:
root@cattle-container:~/poc/openssl-3.6.0# LD_LIBRARY_PATH=. ./apps/openssl version
OpenSSL 3.6.0 1 Oct 2025 (Library: OpenSSL 3.6.0 1 Oct 2025)
root@cattle-container:~/poc/openssl-3.6.0# LD_LIBRARY_PATH=. ./apps/openssl pkcs12 \
-in CVE-2025-11187-keylen-8192.p12 \
-info -noout -passin pass:password
MAC: PBMAC1 using PBKDF2, Iteration 2048
Key length: 8192, Salt length: 8
PBKDF2 PRF: hmacWithSHA256
*** stack smashing detected ***: terminated
AbortedAs noted in the advisory from OpenSSL, untrusted PKCS#12 files are less commonly accepted by applications, since they typically contain private keys. As a result, this issue is more likely to manifest as an application crash than as an RCE vector.
Notes on exploitability leading to RCE
Memory corruption vulnerabilities do not automatically translate into reliable code execution. Modern defenses such as ASLR, executable-space protection, stack canaries, SafeSEH, and platform-specific protections (CFG et al.) significantly complicate exploitation.
Across these vulnerabilities:
- CVE-2025-15467 presents the strongest primitive but remains difficult to exploit reliably.
- CVE-2025-11187 is very unlikely to be exploitable beyond crashes.
Because OpenSSL is distributed as source code, real-world exploitability is highly dependent on downstream build configurations, including compiler choice, optimization level, and whether mitigations such as stack canaries or control-flow protections are enabled. Embedded systems and security appliances may omit some of these defenses, which can materially increase the risk of practical remote code execution in those environments.
How Datadog can help
The Datadog Security platform can help teams detect and respond to exploitation attempts targeting your cloud deployments, as well as identify vulnerable packages across your environment.
Identify vulnerable OpenSSL packages with Cloud VM
Cloud Security Vulnerabilities collects packages installed in your infrastructure by continuously scanning container images, creating temporary snapshots of host volumes, and analyzing serverless function dependencies across your entire.
You can use the following search to identify any resources affected by these OpenSSL vulnerabilities in your organization.
Detect with Workload Protection (RCE scenario)
If an attacker manages to achieve code execution, Workload Protection provides out-of-the-box runtime detections for common post-exploitation behavior, including:
- Unfamiliar process created by web application
- Shell process created by Java application
- Interactive shell spawned in container
Detect with Service Checks (DoS scenario)
For denial-of-service scenarios, repeated crashes or restarts of services processing CMS or PKCS#12 inputs can indicate exploitation attempts. Service checks can help identify anomalous service degradation, crash loops, or unexpected terminations tied to vulnerable OpenSSL versions.
References
Notes
- Prior to the public release, CVE-2025-69419 was marked as medium severity. Due to this, our Security Research team investigated the vulnerability and determined it was unlikely to result in code execution due to it being a one byte write before a buffer. With the subsequent downgrade from medium to low, we removed the section of this post covering it.
