On April 7, 2026, OpenSSL, the cryptographic backbone of the internet, published a security advisory patching 7 new security vulnerabilities. Five were discovered by AISLE’s autonomous AI system. This is the third consecutive OpenSSL security release in which AISLE discovered and responsibly disclosed vulnerabilities, following our discovery of three of four CVEs in September 2025 and all twelve in January 2026. More important than the raw count, half of those findings shipped with AISLE-authored fixes accepted into OpenSSL itself.

Among the seven patched issues, one is a distinct first: CVE-2026-28386, an out-of-bounds read in the AES-CFB-128 assembly path on x86-64 systems with AVX-512 support, was independently discovered by both AISLE and Anthropic. We reported it to the OpenSSL team on January 6, 2026, and developed the fix that OpenSSL directly used. Anthropic's Alex Gaynor (likely using Mythos) independently reported the same vulnerability on March 10, 63 days later. The official advisory records both reports, with AISLE as the original reporter and fix author, and Anthropic as a co-reporter.

As far as I know, this is the first time AISLE and Anthropic have independently converged on the same zero-day vulnerability. The timeline is recorded in the official advisory, and it is worth reading in the context of the flurry of activity around the Mythos release.

The discoveries

AISLE's autonomous AI system discovered five of the seven CVEs announced in the April 2026 advisory:

CVE-2026-28386: Out-of-bounds read in AES-CFB-128 on x86-64 with AVX-512/VAES support. Processing partial cipher blocks at a memory page boundary can crash the process. Discovered by Stanislav Fort and Pavel Kohout, fix developed by AISLE's AI system. Independently reported 63 days later by Alex Gaynor (Anthropic). OpenSSL assessed this as Low severity given the narrow conditions for exploitation, though NVD scored it CVSS 9.1, Critical.

CVE-2026-28387: Use-after-free and potential double-free in the DANE TLSA client code under an uncommon server configuration. Can corrupt memory or potentially enable code execution. Discovered by Igor Morgenstern.

CVE-2026-28388: NULL pointer dereference when processing a malformed delta CRL missing the required CRL Number extension. Discovered and fixed by Igor Morgenstern.

CVE-2026-28389: NULL pointer dereference in CMS EnvelopedData with KeyAgreeRecipientInfo. Also independently reported by researchers from Praetorian, Seoul National University, Tencent Xuanwu Lab, and others.

CVE-2026-28390: NULL pointer dereference in CMS EnvelopedData with KeyTransportRecipientInfo using RSA-OAEP. Also independently reported by researchers from Tencent Xuanwu Lab and others.

All findings were responsibly disclosed and resolved through OpenSSL's coordinated security process.

Three releases, one pattern

The individual findings are all Low severity by OpenSSL's assessment, although any CVE in OpenSSL is already a very high bar. What matters here is the long-term pattern.

In September 2025, we at AISLE reported our first three OpenSSL CVEs, including two Moderate-severity issues: a 15-year-old memory corruption in CMS password-based encryption and a timing side-channel in SM2 on 64-bit ARM. That was the proof of capability of the AISLE technology, the first real-life demonstration that our AI system could find genuine, previously unknown vulnerabilities in one of the most heavily audited and secure codebases in existence.

In January 2026, we discovered all twelve CVEs in a single coordinated release, including a High-severity stack buffer overflow (CVE-2025-15467, CVSS 8.8) potentially remotely exploitable without valid key material. Three of the bugs dated back to 1998–2000, having been in the codebase for 25+ years. That was the result that Bruce Schneier wrote about, noting that "AI vulnerability finding is changing cybersecurity, faster than expected."

This April release is the third consecutive chapter, with five of seven CVEs, in a field where Anthropic, OpenAI, Google, and a myriad of startups and independent researchers, are also hunting in the same codebase.

Autonomous Vulnerability Management From Detection to Fix

Across these three releases, AISLE discovered 20 OpenSSL CVEs. Our platform generated the fixes accepted into the official releases for 10 of them. Half of all our findings shipped as AISLE-authored patches.

That last number in my view deserves a special emphasis. Most vulnerability research, including most AI-driven research, stops at discovery. Find the bug, file the report, move on. Writing a production-ready patch for OpenSSL is a different kind of problem. The fix has to respect the project's coding conventions, handle all affected branches, avoid introducing regressions, and pass review by extremely judicious maintainers who have spent years or decades with the codebase.

Our system handles discovery, triage, and patch generation as a single loop. When the OpenSSL advisory says "fix developed by" an AISLE researcher, that means the patch running in production was generated by our AI system and accepted by the maintainers as-is or with minor adaptation. That is not something most teams in this space, human or AI-driven, currently do.

Beyond retroactive discovery, AISLE PRO is now deployed live on OpenSSL pull requests, where maintainers invoke it to catch security issues before they can make it into a release and have a chance of becoming CVEs. Throughout 2025, this already prevented several vulnerabilities from shipping, including a double-free in the OCSP implementation and a use-after-free in RSA OAEP label handling.

OpenSSL lists AISLE as an in-kind supporter alongside IBM. Our reports are not one-shot disclosures but rather one side of a continuous effort to secure the critical software infrastructure of the world. They reflect an ongoing relationship with the project and a system that keeps producing validated results as the codebase evolves and "competition" (albeit with a shared and noble goal) intensifies.

CVE-2026-28386 is, as far as I know, the first OpenSSL vulnerability, and zero-day in general, independently discovered by both AISLE and Anthropic. The timeline recorded in the official advisory is straightforward. AISLE reported on January 6 and developed the fix. Anthropic reported on March 10, sixty-three days later.

We can't draw sweeping conclusions from a single co-discovery. Both teams clearly have strong capabilities, and Anthropic's commitment to open source security through Project Glasswing is genuinely positive for the ecosystem. More serious players in this space means more vulnerabilities found and fixed before attackers can exploit them. That is unambiguously good.

But the data point is consistent with something I've argued before: in AI-powered security, the moat is the system, not the model. Anthropic has access to the most capable frontier model in the world. We operate a multi-model system built around deep security domain expertise and continuous engagement with the projects we analyze. On this vulnerability, in this codebase, the purpose-built system found it first, found it two months earlier, and wrote the fix, in addition to the other 4 CVEs not co-discovered by Anthropic.

This is consistent with the jagged frontier we've documented: cybersecurity capability doesn't scale smoothly with model size or cost. What matters most is the security expertise, engineering, and sustained focus wrapped around the models.

Looking ahead

This is the first OpenSSL release where multiple AI-driven research teams independently reported vulnerabilities. Anthropic, Praetorian, Tencent Xuanwu Lab, and others are now hunting in the same codebase we've been working in since mid-2025. The attack surface of critical infrastructure is far too large for any single team, and the fact that others are entering the space is genuinely good for the overall security of the ecosystem.

Twenty zero-days in OpenSSL, three consecutive security releases, ten fixes accepted into the official codebase. AI can find vulnerabilities in critical infrastructure, the evidence settles that in the affirmative. The harder problem, and the one we care about most as a team, is sustaining the pace while maintaining the trust of the people who build and secure the software.

The same system that produces these results is available as a product. AISLE's platform handles the full remediation pipeline, from discovery through triage, patch generation, and verification, so that security teams get actionable fixes rather than a list of problems. The OpenSSL work is a clear proof of what that pipeline can do against the hardest targets. If your organization depends on software you need to trust, reach out.

AISLE researchers contributing to these discoveries include Stanislav Fort, Pavel Kohout, Igor Morgenstern, and Joshua Rogers. Our appreciation goes to the OpenSSL team for their continued collaboration and professionalism.