On January 27, 2026, OpenSSL shipped a coordinated security update fixing twelve zero-day vulnerabilities — “zero-day” here meaning the maintainers had no idea they existed until disclosure. The real headline: all twelve came from the same autonomous AI analyzer built by a company called AISLE. The worst of them carries a NIST CVSS score of 9.8, and the oldest problem code traces back to 1998, predating OpenSSL itself.
Bruce Schneier’s one-line verdict is worth pinning to every security team’s wall: “AI vulnerability finding is changing cybersecurity, faster than expected.”
One Autonomous Analyzer, All Twelve CVEs
AISLE builds autonomous vulnerability-discovery tooling, and the hunt started in August 2025: an AI analyzer running continuously, covering code paths and edge cases that human review cannot exhaustively check. All 12 CVEs in this coordinated release came from it, credited to researchers Stanislav Fort, Petr Šimeček, Tomas Dulka, and Luigino Camastra. Every report included reproduction steps, root cause analysis, and a patch proposal — and for 5 of the 12 CVEs, the AI’s proposed fix was adopted into the official release. Six more findings were fixed and merged before ever shipping, so they never needed a CVE at all.
Counting the whole of 2025, this line of work accounts for 13 of the 14 CVEs OpenSSL assigned that year. OpenSSL CTO Tomáš Mráz put it this way: “One of the most important sources of the security of the OpenSSL Library… is independent research,” adding appreciation for “the high quality of the reports and their constructive collaboration.” Executive Director Matt Caswell likewise stressed that keeping widely deployed cryptography secure requires tight coordination between maintainers and researchers.
CVSS 9.8: The Overflow Buried in the CMS Parser
The highest-severity finding, CVE-2025-15467, is a stack buffer overflow in the CMS AuthEnvelopedData parsing path. OpenSSL rated it High; NIST assigned CVSS v3 9.8 (Critical). Exploitation does not require valid key material, and proof-of-concept exploits appeared online quickly after disclosure. The remaining eleven break down into one moderate issue (missing PBMAC1 parameter validation in PKCS#12) and ten low-severity ones, spanning crashes in QUIC cipher handling, memory corruption in line buffering, memory exhaustion via TLS 1.3 certificate compression, an OCB-mode encryption flaw on hardware-accelerated paths, and silent truncation of ML-DSA post-quantum signatures — more than eight subsystems affected.
The timescale is the startling part: three of the bugs live in code dating to 1998–2000, and one predates OpenSSL entirely, inherited from Eric Young’s SSLeay implementation of the 1990s.
Why Millions of Fuzzing Hours Missed Them
This is not code nobody looked at. OpenSSL has been fuzzed for millions of CPU-hours and audited extensively for over two decades, including by Google’s teams. What the AI analyzer found were edge cases buried in protocol-parsing branches that require cross-subsystem reasoning — precisely the intersection where fuzzing struggles to trigger and human audits struggle to enumerate. Commenters on Schneier’s post attribute the system to “AISLE and Claude Opus 4.6” (AISLE itself has not confirmed the model); whatever runs underneath, the lesson is the process — continuous operation, discovery as the explicit objective, and reports that ship with actionable fixes attached.
A Defender’s Edge, or an Attacker’s?
Who benefits more from AI bug hunting? Schneier’s conclusion: it cuts both ways. Optimists argue defenders gain, because bugs get fixed before release and patch proposals arrive alongside the findings. Skeptics counter that attackers only need one unpatched flaw, patch windows remain exploitable, and finding some vulnerabilities guarantees no coverage. Both arguments hold. For operations teams, though, one constant is clear: the time coefficient has changed. The gap between “vulnerability found” and “exploit circulating online” is shrinking, and your patching SLAs have to compress accordingly.
Three Practical Takeaways for Developers
First, treat OpenSSL and cryptography-dependency upgrades as a high-priority process, not a chore: twelve CVEs were fixed in one release, and every unpatched older version is now a known battlefield. Second, if your systems lean on CMS, PKCS#12, QUIC, or ML-DSA code paths — especially anything parsing untrusted input — verify your version and configuration first. Third, add “AI-discovered vulnerabilities” to your threat model: “this code hasn’t blown up in twenty years” is no longer evidence of safety.
Sources
- AISLE Discovered 12 out of 12 OpenSSL Vulnerabilities — AISLE
- AI Found Twelve New Vulnerabilities in OpenSSL — Schneier on Security
- AI Found 12 of 12 OpenSSL Zero-Days — LessWrong
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.