OpenSSL Stack Overflow Enables Remote Code Execution

A critical stack buffer overflow in OpenSSL allows attackers to crash applications or potentially execute arbitrary code by sending crafted cryptographic messages. CVE-2025-15467, disclosed January 27, carries a CVSS score of 9.8 and affects any application parsing untrusted CMS or PKCS#7 content.

What makes this vulnerability notable beyond its severity: it was discovered entirely by AI. Security firm AISLE's autonomous system identified CVE-2025-15467 alongside 11 other OpenSSL flaws, marking the largest coordinated security release in the project's history.

The Technical Breakdown

The vulnerability exists in OpenSSL's handling of Cryptographic Message Syntax (CMS) AuthEnvelopedData structures. When processing messages using AEAD ciphers like AES-GCM, OpenSSL copies the initialization vector from ASN.1 parameters into a fixed-size stack buffer—without checking whether the IV fits.

An attacker can supply a CMS message with an oversized IV, triggering a stack-based out-of-bounds write. The overflow occurs before any authentication or tag verification, meaning no valid encryption keys are required to trigger it.

JFrog security researchers have confirmed remote code execution is achievable through exploitation. Real-world attacks would need to bypass standard mitigations—stack canaries, ASLR, and DEP—likely by chaining CVE-2025-15467 with an information leak. On systems with weaker protections, exploitation is more straightforward.

Vulnerable OpenSSL functions include CMS_Decrypt, PKCS7_decrypt, and EVP_CIPHER_asn1_to_param. Command-line tools openssl cms and openssl smime are also affected.

Who's Exposed

OpenSSL 3.0 through 3.6 are vulnerable. Versions 1.1.1 and 1.0.2 are not affected—those older releases don't include the vulnerable code path.

Any service that processes untrusted S/MIME messages or CMS content using AEAD ciphers faces exposure. This includes email servers handling encrypted attachments, document signing systems, and applications implementing S/MIME encryption. The vulnerability is particularly dangerous for internet-facing services accepting messages from unknown senders.

Red Hat notes that their Enterprise Linux builds include stack protections that mitigate the code execution risk, though denial-of-service via crash remains possible.

Fortinet has issued advisory FG-IR-26-076 confirming they're investigating impact across their product line. FortiOS, FortiMail, FortiWeb, FortiProxy, and numerous other Fortinet appliances are under assessment. Given how many security products depend on OpenSSL, expect similar advisories from other vendors in coming days.

AI Found All Twelve

The disclosure marks a watershed moment for AI-driven vulnerability research. AISLE's autonomous analysis system discovered all 12 vulnerabilities in this coordinated OpenSSL release—plus 3 additional flaws disclosed in 2025, accounting for 13 of 14 OpenSSL zero-days discovered last year.

Some bugs dated back decades. One flaw, CVE-2026-22796, predates OpenSSL itself—it was inherited from SSLeay, Eric Young's original SSL implementation from the 1990s. Human researchers and existing automated tools missed it for over 25 years.

The vulnerabilities span eight different OpenSSL subsystems, including CMS, QUIC, and post-quantum signature algorithms. In five cases, AISLE's system directly proposed patches that were accepted into the official release after human review.

OpenSSL Foundation CTO Tomas Mraz praised the collaboration: "Independent research is one of the most important sources of the security of the OpenSSL library and open source projects overall. We appreciate the high quality of these reports and their constructive collaboration with us throughout the remediation process."

The timing is notable. Just four days earlier, curl shut down its bug bounty program specifically because AI-generated reports were flooding the queue with noise. Same technology, opposite outcomes—AI that floods security teams with garbage versus AI that finds bugs humans can't.

Patch Immediately

OpenSSL has released fixes across all affected version branches:

• OpenSSL 3.6 users should upgrade to 3.6.1
• OpenSSL 3.5 users should upgrade to 3.5.5
• OpenSSL 3.4 users should upgrade to 3.4.4
• OpenSSL 3.3 users should upgrade to 3.3.6
• OpenSSL 3.0 users should upgrade to 3.0.19

Linux distributions are already shipping updates. Debian, Red Hat, Ubuntu, and SUSE have all published security advisories with patched packages available.

If immediate patching isn't possible, the temporary workaround is avoiding untrusted CMS or PKCS#7 content with AEAD ciphers. For most organizations, that's not a realistic mitigation—it requires knowing exactly where CMS processing occurs in your infrastructure and restricting input sources.

A proof-of-concept exploit is already circulating in open sources. The window between disclosure and active exploitation tends to be short for vulnerabilities of this severity.

Why This Matters

OpenSSL is downloaded over 15 million times annually and embedded in operating systems, cloud platforms, and critical infrastructure across finance, healthcare, government, and technology sectors. When OpenSSL has a bad day, much of the internet has a bad day.

CVE-2025-15467 represents exactly the kind of memory corruption bug that leads to widespread exploitation. Network-reachable, no authentication required, potentially gains code execution—threat actors build ransomware initial access around vulnerabilities like this.

The AI discovery angle adds another dimension. Security teams should expect more AI-found vulnerabilities emerging in foundational libraries. Whether that represents net security improvement depends on whether defenders patch faster than attackers exploit—a race that's played out countless times before, usually without a clear winner.

Organizations running custom OpenSSL deployments or vendor products dependent on OpenSSL should treat this as an emergency patch cycle. Check with vendors, update infrastructure components, and verify the fix deployed successfully. The alternative is waiting to see whether your systems become proof-of-concept for the next security conference talk.