A critical vulnerability (CVE-2025-15467, CVSS 9.8) dropped on January 27, 2026. It affects OpenSSL 3.0, 3.3, 3.4, 3.5, and 3.6 – and it’s nasty.
An attacker can trigger a stack buffer overflow by sending a malformed encrypted message. The kicker? The overflow fires before OpenSSL validates anything. No encryption keys needed. No authentication. Just a crafted message.
If your infrastructure processes S/MIME email (the standard for encrypted/signed email) or untrusted CMS content, patch now.
The Summary
OpenSSL’s CMS module (Cryptographic Message Syntax – a standard for securely packaging encrypted data) parses encrypted messages. When handling certain encryption modes (AEAD ciphers like AES-GCM), it extracts an Initialization Vector (IV) – essentially a random value that makes each encryption unique. OpenSSL expects this to be 12-16 bytes and allocates a fixed 16-byte buffer on the stack (temporary memory used during function execution).
The bug: OpenSSL blindly trusts the message’s claimed IV length and copies it without checking. Send an oversized IV, overflow the buffer, corrupt adjacent memory. This type of flaw – a stack buffer overflow – can crash the application or, worse, let attackers hijack program execution.
Why Security Teams Should Care
This isn’t just another buffer overflow. Three factors make it particularly dangerous:
- Pre-authentication exploitation: Most crypto bugs require passing some validation first. Here, the overflow happens during initial parsing – before any cryptographic verification. An attacker doesn’t need valid keys or a legitimate-looking payload.
- Low attack complexity: CVSS rates this 9.8 with attack complexity “Low” and no privileges required. The attack surface includes any service parsing external CMS or PKCS#7 content (PKCS#7 is an older but still widely-used standard for signed and encrypted data, now largely superseded by CMS).
- Wide deployment: OpenSSL 3.x runs on countless mail servers, web servers, and embedded systems. The vulnerable code path affects S/MIME email processing, encrypted file handling, and any application calling the affected APIs.
Technical Details
According to analysis published by JFrog Security Research, the vulnerable function is evp_cipher_get_asn1_aead_params() in crypto/evp/evp_lib.c.
What’s AEAD?
Authenticated Encryption with Associated Data – a modern encryption approach (like AES-GCM) that provides both confidentiality and integrity in one operation. It’s widely used because it’s efficient and secure when implemented correctly.
The vulnerable code path
- Application calls CMS_decrypt() to process an incoming message
- OpenSSL parses the structure, identifies it uses AEAD encryption
- Extracts the IV from ASN.1-encoded parameters
- Copies IV to a 16-byte stack buffer – without length validation
- Oversized IV overflows into adjacent stack memory
The fix is straightforward: validate that IV length ≤ EVP_MAX_IV_LENGTH before copying. This pattern – trusting attacker-controlled length fields, remains one of the most common sources of memory corruption in C code.
Real-World Impact
Guaranteed: Denial of service. The corruption crashes the process.
Possible: Remote code execution. Depends on platform mitigations. Red Hat notes their Enterprise Linux builds include stack protections that “mitigate the risk of code execution though a denial-of-service condition remains possible.” Ubuntu’s security team states that “compiler hardening in Ubuntu would reduce a stack buffer overflow to a denial of service only.”
Systems without modern protections face higher RCE risk. These protections include stack canaries (secret values that detect when a buffer overflow corrupts the stack) and ASLR (Address Space Layout Randomization, which makes memory addresses unpredictable so attackers can’t reliably jump to malicious code). JFrog confirms they reproduced the overflow, exploitation details remain unpublished.
Affected Versions and Patches
Per OpenSSL’s advisory:
| Vulnerable | Fixed |
|---|---|
| 3.6.0 | 3.6.1 |
| 3.5.0 – 3.5.4 | 3.5.5 |
| 3.4.0 – 3.4.3 | 3.4.4 |
| 3.3.0 – 3.3.5 | 3.3.6 |
| 3.0.0 – 3.0.18 | 3.0.19 |
Not affected: OpenSSL 1.1.1 and 1.0.2. FIPS modules (the government-certified cryptographic builds used in regulated environments) are also unaffected because CMS is outside the FIPS boundary.
EOL warning: OpenSSL 3.1 (EOL March 2025) and 3.2 (EOL November 2025) likely contain this vulnerability but won’t receive patches. Upgrade to a supported branch.
Threat Status (as of January 29, 2026)
- Public PoC: None available
- CISA KEV: Not listed
- Active exploitation: No corroborated reports
Given the detailed technical information now public and the straightforward nature of the bug, assume capable attackers can weaponize this quickly.
Discovery: AI Finds 12 OpenSSL Zero-Days
Interesting backstory: CVE-2025-15467 was one of 12 vulnerabilities discovered by AISLE, a security research organization using AI-driven vulnerability discovery. Stanislav Fort, AISLE’s co-founder and chief scientist, reported this issue to OpenSSL on December 14, 2025. The fix was developed by Igor Ustinov.
OpenSSL CTO Tomas Mraz confirmed: “This release is fixing 12 security issues, all disclosed to us by Aisle.” According to AISLE, all 12 were initially identified by their AI system and validated by human researchers – a notable example of AI-augmented security research finding real bugs in critical infrastructure.
How Can Orca Help?
The challenge for security teams isn’t awareness – it’s visibility and prioritization. Which of your assets actually run vulnerable OpenSSL versions? Which ones are internet-facing? Which ones process untrusted encrypted content?
The Orca Cloud Security Platform can help customers identify assets running affected OpenSSL versions across cloud environments and understand exposure context: internet accessibility, whether the vulnerable component is in the active attack path, and asset criticality. This context helps teams prioritize based on actual risk rather than treating every OpenSSL 3.x installation as equally urgent.
