AISLE's Year on the Cyber Frontier

Today, curl released version 8.23.0, fixing 24 previously unknown security vulnerabilities. AISLE found 18 of them, more than any other reporting organization represented in the release.

Over the past year, our AI security research team in Prague discovered more than 500 previously unknown vulnerabilities assigned CVEs across more than 100 codebases. Along the way, AISLE repeatedly matched or outperformed frontier AI security systems in public comparisons on live production software.

The question is no longer whether AI can find real zero-days. It is which systems can do so reliably and at scale without overwhelming the people responsible for fixing them.

Why We Chose curl

curl is one of the world's most mature, hardened, and scrutinized software projects. It has been developed in public for nearly three decades, examined by generations of security researchers, and is estimated by its maintainers to run in roughly 30 billion installations.

Our relationship with curl began in late 2025. This initial work produced five CVEs and 24 credited pull requests. By February 2026, curl was using AISLE's AI directly to review its code continuously.

In May, a Mythos scan claimed five “confirmed security vulnerabilities” in curl. After curl's team reviewed them, one became a low-severity CVE, three were false positives, and one was an ordinary bug. In June, AISLE led all security organizations with 6 of the 18 CVEs fixed in curl 8.21.0, including the oldest curl security vulnerability reported to date, which had survived 25 years in the codebase.

On August 24, Daniel Stenberg reported that Mythos and OpenAI's Codex Security had found no additional vulnerabilities. We then let AISLE's AI loose on the curl codebase. The next day, Daniel posted the comparison plainly: “Mythos: 0 / Aisle: 29.” Six AISLE findings became CVEs in curl 8.22.0. Follow-on analysis continued, and another 18 AISLE zero-day findings were disclosed today. The dedicated technical account documents the full audit and each new CVE.

On release day, Daniel Stenberg published “A curl audit by Aisle”, calling it curl’s fifth official external audit. He wrote that AISLE had found more curl CVEs than any other group or individual in the project’s history, and that AISLE researchers had already authored several dozen curl commits.

We Chose Reality as the Benchmark

CVEs are not a perfect unit of scientific measurement. Projects apply different standards, and severity matters more than volume. But they have one unusually valuable property that most AI evaluations do not: AISLE does not award them to itself. The evaluators are the most knowledgeable and skeptical people on the codebases in question, with every reason to reject incomplete or unconvincing findings.

From the beginning, our mission was to secure the software foundations of technological civilization before strong AI systems become ubiquitous. That mission shaped a deliberate research choice. We pointed AISLE at current production code from some of the world's most hardened software projects rather than optimizing around toy problems, CTF challenges, or benchmarks with known answers. Maintainers rejected wrong reports and, when a finding met a project's security threshold, reproduced it, fixed it, and decided whether it merited a CVE.

I described that choice in January, after OpenSSL published a release in which AISLE had discovered 12 vulnerabilities, amounting to every CVE in that release. Live targets made our “benchmark” external and, at times, intellectually adversarial. OpenSSL and curl maintainers do not hand out CVEs as participation trophies. Their acceptance, patches, and public credits are about as close to ground truth as security research gets.

Bruce Schneier later concluded that AI vulnerability finding was changing cybersecurity “faster than expected.” The public record now shows that he was indeed correct. The UC Berkeley Vulnerability Initiative independently tracks AI-attributed CVEs and rebuilds its dataset daily. Its current leaderboard places AISLE first or tied for first in five of eight measures, including CVE volume, vulnerability-class breadth across CWE categories, and MITRE Top-25 reach. It does not rank us first in everything: Anthropic leads in critical-vulnerability count, while other teams lead in average severity and estimated exploit probability. That mixed result is precisely why the comparison is useful. A European research startup is competitive with frontier labs on independently tracked, real-world outcomes.

By our count, AISLE researchers discovered and were credited with roughly 1% of all CVEs published so far in 2026 for open-source software worldwide. That share comes from one AI security startup in Prague, measured against the entire global open-source ecosystem.

This Was Not a One-Off

The OpenSSL pattern continued across three consecutive releases between September 2025 and April 2026. OpenSSL disclosed 23 zero-days, of which AISLE discovered 20 and generated accepted fixes for 10. The January release contained all 12 findings discussed above. In April, OpenSSL credited AISLE with reporting and fixing a vulnerability 63 days before Anthropic independently reported the same issue. We had repeatedly demonstrated both discovery and remediation.

FreeBSD provided another direct public comparison. After Anthropic showcased a 17-year-old NFS remote-code-execution vulnerability found by Mythos, AISLE found three additional vulnerabilities in the same release cycle: a root RCE reachable through a rogue DHCP server, a remotely triggerable heap overrun, and stack corruption in libnv. On the public record, AISLE and Anthropic finished three to three on Anthropic's showcase codebase during that release window.

This was not a controlled experiment, nor does it establish which system is universally more capable. It shows something narrower but still useful: AISLE repeatedly surfaced independently validated zero-days in the same hardened environments being examined by frontier labs.

These findings affected real systems. In NASA's CryptoLib, AISLE found a three-year-old command injection in software securing spacecraft-to-ground communications. NASA's maintainers fixed it within four days, and Forbes covered the implications. In healthcare, AISLE found 38 CVEs in OpenEMR, including two CVSS 10.0 vulnerabilities. OpenEMR estimates that its software serves more than 100,000 providers and 200 million patients. Every finding was patched, and AISLE was integrated into code review.

Going beyond CVEs, AISLE also found and built an exploit for a one-click RCE spanning Cursor, VS Code, and Google Antigravity, affecting up to 50 million users of agentic coding tools worldwide. A malicious link in a Git commit message could execute code with terminal privileges and no warning. All three vendors fixed it, and we demonstrated the exploit end to end.

To give a sample of the breadth of our discovery push, AISLE found 16 CVEs in Wireshark, 13 across two rounds in FFmpeg, and 8 across MySQL, MariaDB, and PostgreSQL.

With today's curl release, AISLE's public record crosses 500 assigned CVEs across more than 100 codebases. We deliberately avoided Goodharting the metric, which would have meant choosing soft targets simply to maximize our CVE count. The results repeat across hardened codebases in cryptography, operating systems, browsers, developer tools, healthcare, space, media, networking, and databases.

System Over Model

AISLE had no secret model advantage over OpenAI or Anthropic. In my view, our results point to a more interesting lesson: "AI cybersecurity" is not one scalar capability, and model intelligence per token does not determine the outcome by itself.

When we tested small, cheap, and open-weight models on code from Mythos's showcase vulnerabilities, all eight found the core overflow behind the flagship FreeBSD bug once shown the relevant function. A model with just 5.1 billion active parameters even recovered the core reasoning behind a subtler 27-year-old OpenBSD vulnerability.

Model rankings changed sharply by task. Models that found the vulnerable FreeBSD code sometimes insisted the patch was still broken, while models that solved kernel problems failed a trivial Java data-flow exercise. A security system therefore needs more than a model. Without skeptical triage, even an impressive model can produce better-written slop.

The zero-day discovery production function has several inputs, including intelligence per token, throughput, codebase coverage, and security expertise embedded in the system. A brilliant model may reason more deeply about a file. Broad parallel search offers a different advantage because many adequate models can inspect every room while one brilliant model still has to guess where the keys are. Context generation, parallel search, model routing, filtering, reproduction, patching, and maintainer feedback can be just as decisive.

We then tested the idea against a full codebase. For System Over Model, we built and open-sourced nano-analyzer: a deliberately minimal repository scanner in one Python file, with no agentic loop, sandbox, or code execution. It generated context, scanned each file, and skeptically triaged surviving findings.

Cheap models repeatedly distinguished vulnerable from patched versions of Mythos's FreeBSD finding. We then pointed nano-analyzer at roughly 35,000 files and 7.5 million lines in the current FreeBSD kernel, where it surfaced new bugs that maintainers confirmed. One model detected a decades-old kernel bug even though it could not produce valid JSON reliably. This combination captures the jagged frontier rather cleanly.

Models remain important because better models raise the ceiling, and AISLE improves with them. But within AISLE, the model is one component of a compounding system. Axios described this model-agnostic approach as combining proprietary and open models with AISLE's security expertise at a fraction of frontier-model cost.

The public record tells the same story. I assembled that evidence in "Mythos" at Home, and It's Called AISLE, comparing AISLE and Mythos across FreeBSD, OpenSSL, curl, and Berkeley's independent record. The piece also argues that advanced AI cyber defense should remain available in sovereign and air-gapped environments, a mission to which we are deeply committed.

To be explicit, we do not claim that small models match Mythos or Astra at every cyber task, and autonomous exploit construction may depend more heavily on frontier models. On the defensive task we set out to solve, however, a specialized system can operate at the frontier without owning the world's largest model. That task covers finding, validating, and fixing unknown vulnerabilities in real software. These capabilities will continue to diffuse, which is why security by obscurity remains one of the field's oldest bad ideas.

The Bottleneck Moved

Finding vulnerabilities matters only if the ecosystem can validate, disclose, and remediate them. Axios captured the contradiction in March: AI slop was overwhelming maintainers while carefully built systems were surfacing vulnerabilities previously inaccessible to machines.

The practical lesson here is that false positives can destroy trust faster than capability improves. When a tool repeatedly wastes a defender's time, the defender stops using it and never benefits from the next model upgrade. Triage therefore belongs at the center of discovery. For example, in one commercial deployment, AISLE reduced Productboard's alert noise by 99.9%, allowing its security team to focus on findings that required action.

curl made this transition visible. In January, it ended its bug bounty after AI-generated noise drove valid reports below five percent. By April, Daniel Stenberg described “high-quality chaos”: almost every report used AI, volume had doubled again, and the confirmed rate had recovered to roughly 15 to 16 percent. Slop receded, but the report volume remained punishing even though the reports were now of high quality and many received CVEs.

By May, curl was receiving more than one security report per day, and Daniel was spending almost all his working time verifying claims, patching, writing advisories, and coordinating with researchers. False positives waste time, while real vulnerabilities create urgent work.

The bottleneck has now clearly moved downstream. Discovery began scaling faster than maintainer attention, reproduction, prioritization, disclosure, and remediation, a pattern we also see in other domains such as AI-assisted mathematics. A system that merely produces more plausible findings does not solve the problem because, at sufficient volume, it can temporarily make security worse.

The goal is to turn a real finding into safer software while using as little scarce maintainer attention as possible.

Reducing maintainer friction also means absorbing some of the administrative burden of disclosure. To that end, AISLE became a CVE Numbering Authority and later a Researcher CNA under the ENISA Root. These roles let us help process eligible disclosures and reduce handoffs where no more specific CNA has coverage. In September, ENISA engaged AISLE for continuous secure-code review of the reporting platform behind Europe's Cyber Resilience Act. Together, these steps increase the ecosystem's institutional capacity without replacing maintainer judgment.

From Finding to Fix

OpenSSL provides a public example of the workflow we are trying to make routine. On one proposed change, AISLE flagged four potential security issues, including an out-of-bounds read assessed as High severity. The system explained the security implications and proposed repository-native fixes.

The OpenSSL team then discussed AISLE's recommendation and implemented the fix three days later. The vulnerability never shipped and therefore needed no CVE, which is the optimal outcome for us. The issue moved from detection to maintainer review to remediation inside the development workflow.

Our ultimate goal is prevention: catch vulnerabilities before they reach a release. This may not get us the next CVE milestone announcement, but it would raise the world's baseline level of software security.

What Comes Next

I recently argued in The Atlantic that we may have only months or a year to solve the task of securing civilization's software foundation as AI capabilities accelerate. I also believe cybersecurity can meet that challenge if we step up as a field.

AISLE began with a mission to secure the software foundations of technological civilization at the onset of strong AI. Those foundations are OpenSSL, curl, FreeBSD, databases, browsers, healthcare systems, and the long tail of software on which society depends invisibly but indispensably.

Strong AI changes the urgency because vulnerability discovery and exploitation will not remain scarce. Restrictions around any single model may slow access to a particular capability, but they cannot erase the broader diffusion of that capability. Defensive discovery and remediation must scale at least as quickly.

The past year gives us reason for optimism because defenders can sometimes exploit an important asymmetry. An offensive chain may depend on several vulnerabilities, assumptions and mitigations lining up correctly in a brittle chain that can require substantial intelligence to construct. Breaking even one dependency can collapse the path, so defenders do not always need to reproduce an attacker's entire chain to make it fail. As I argued in "Mythos" at Home, defenders can repair the loose bricks before an attacker assembles them into a path through the wall.

Defense still faces an enormous coverage problem because finding enough of the underlying weaknesses is hard. Even so, our experiments suggest that useful defensive discovery and remediation can require less capability than novel, autonomous exploit construction. One fix in OpenSSL, curl or FreeBSD can protect billions as updates propagate.

The work must therefore move earlier. AISLE already reviews proposed changes in OpenSSL and curl, catching problems during development. We combine deep archaeological exploration with continuous hardening by inspecting new code, validating findings, proposing fixes, and helping humans merge them before vulnerable software reaches users.

Five hundred CVEs is an important milestone, but not the destination. It shows that autonomous discovery works against hardened software, at scale, under external scrutiny, and without being locked out of access from any single frontier AI model provider.

The next milestone for AISLE is not one thousand CVEs. It is finding and fixing vulnerabilities before they ever ship.