Summary: OpenSSL’s January 27, 2026 coordinated update fixed twelve zero-days that AISLE’s autonomous analyzer found, including a CMS parser overflow scored CVSS 9.8 by NIST. Five official fixes used AISLE’s patch proposals directly, and the article urges teams to prioritize crypto dependency updates and add AI-discovered vulnerabilities to threat models.
A coordinated security update that OpenSSL shipped on January 27, 2026 closed out twelve zero-day vulnerabilities — zero-day in the strict sense that maintainers knew nothing of their existence until disclosure. The story behind the patch count is the real news: one autonomous AI analyzer, built by a company named AISLE, found every one of the twelve. The most severe of them carries a NIST CVSS score of 9.8, and the oldest of the flawed code paths dates back to 1998 — older than the OpenSSL project itself.
Bruce Schneier needed only one line to sum the episode up: “AI vulnerability finding is changing cybersecurity, faster than expected.”
All Twelve CVEs Trace Back to a Single Autonomous Analyzer
Autonomous vulnerability discovery is what AISLE builds, and the hunting run opened in August 2025: an AI analyzer kept running nonstop, sweeping through code paths and edge conditions that no amount of human review could ever check exhaustively. Every one of the 12 CVEs in the coordinated release traces back to that system, with researchers Stanislav Fort, Petr Šimeček, Tomas Dulka, and Luigino Camastra named on the work. Each report arrived with reproduction steps, a root cause analysis, and a patch proposal — and in 5 of the 12 cases, the official release took the AI’s proposed fix as-is. Another 6 findings were fixed and merged before ever shipping, leaving no need for a CVE number at all.
Widen the window to cover all of 2025, and this one line of work accounts for 13 of the 14 CVEs OpenSSL assigned that year. OpenSSL CTO Tomáš Mráz framed it this way: “One of the most important sources of the security of the OpenSSL Library… is independent research,” pairing that with thanks for “the high quality of the reports and their constructive collaboration.” Executive Director Matt Caswell made the same point from his side: keeping widely deployed cryptography secure depends on maintainers and researchers coordinating closely.
CVSS 9.8: The Overflow Hiding in the CMS Parser
At the top of the severity list sits CVE-2025-15467, a stack buffer overflow in the CMS AuthEnvelopedData parsing path. OpenSSL’s own rating was High; NIST scored it CVSS v3 9.8 (Critical). Exploiting it does not require valid key material, and proof-of-concept exploits were circulating online shortly after disclosure. The other eleven break down into one moderate finding (missing PBMAC1 parameter validation in PKCS#12) and ten rated low, covering QUIC cipher-handling crashes, memory corruption in line buffering, memory exhaustion driven by TLS 1.3 certificate compression, an OCB-mode encryption flaw along hardware-accelerated paths, and silent truncation of ML-DSA post-quantum signatures — more than eight subsystems caught up in it.
What startles most is the timeline: three of the bugs sit in code dating to 1998–2000, and one of them predates OpenSSL entirely, inherited from Eric Young’s SSLeay implementation of the 1990s.
Millions of Fuzzing Hours, Two Decades of Audits — and They Still Missed
This was never code sitting in the dark. Fuzzers have pounded OpenSSL for millions of CPU-hours, and for more than twenty years auditors — Google’s teams among them — have been over it extensively. The edge cases the AI analyzer surfaced were buried in protocol-parsing branches and required reasoning that cuts across subsystems, landing precisely in the overlap where fuzzing struggles to trigger and human audits cannot enumerate every case. Over on Schneier’s post, commenters attribute the system to “AISLE and Claude Opus 4.6” (AISLE itself has not confirmed the model); whichever model runs underneath, the transferable lesson is the process — always running, with discovery as the stated goal, and reports that carry fixes ready to act on.
Who Gains the Edge: Defenders or Attackers?
Which side does AI-powered bug hunting favor? Schneier’s answer is that it cuts both ways. The optimistic case hands the advantage to defenders: bugs get eliminated before release, and patch proposals arrive together with the findings. Skeptics push back: an attacker needs only one unpatched flaw, the window before a patch ships remains exploitable, and finding some vulnerabilities promises nothing about complete coverage. Both arguments hold. What operations teams can be sure of, though, is that the time coefficient has changed: the stretch between “vulnerability found” and “exploit circulating online” keeps contracting, and patching SLAs have to compress with it.
Three Concrete Actions for Developers
First action: move OpenSSL and every cryptographic dependency up the priority list — twelve CVEs closed in a single release, so every older unpatched version is now a battlefield with a map published. Second: for systems that lean hard on CMS, PKCS#12, QUIC, or ML-DSA code paths, check version and configuration before anything else, and most of all wherever untrusted input gets parsed. Third: write “AI-discovered vulnerabilities” into your threat model — a twenty-year record of a code path never blowing up is no longer proof that it is safe.