An AI-native vulnerability-management startup called Aisle is gaining unusual attention in open-source security circles after its scans uncovered real vulnerabilities in Curl, the widely used command-line file-transfer tool. Six of Aisle’s discoveries were accepted by Curl’s maintainers, assigned CVE numbers, and patched in the project’s latest release. The result is notable because other, better-known AI coding tools had recently scanned the same codebase and, according to Curl’s founder, did not find those flaws.

Curl is one of the most important open-source programs in the world. It is embedded in Linux distributions, operating systems, cars, routers, cloud infrastructure, and countless software applications. The tool handles a huge share of internet data transfers, so any vulnerability in it demands serious attention. Finding a genuine unknown defect in Curl is not like solving a contrived benchmark; it means discovering a mistake that survived years of real-world auditing, fuzzing, and production use. That is why the Curl maintainers’ confirmation of Aisle’s findings carries more weight than a typical AI vendor demo.

Key facts everyone should know

• Aisle reported 29 candidate security issues during its recent analysis of Curl.
• Curl maintainers accepted six of those findings as newly identified vulnerabilities and assigned CVE numbers.
• The six CVEs were patched in Curl 8.22.0, released on September 2.
• Curl’s own advisory database lists the six CVEs as low severity.
• Daniel Stenberg, Curl’s founder, confirmed that other AI tools such as Anthropic’s Mythos, OpenAI Codex Security, and ZeroPath did not surface additional vulnerabilities at the time.
• Greg Kroah-Hartman, stable Linux kernel maintainer, said he is seeing similarly interesting results for Linux.

These facts should not be oversold. Six low-severity CVEs from one project do not prove that Aisle is universally better than every other AI security product. But they do provide real-world evidence that a purpose-built vulnerability-management system can find issues that general-purpose AI models miss when asked to review mature production code.

How Aisle finds vulnerabilities

Aisle does not claim to be built on the world’s most powerful AI model. Instead, the company argues that a well-orchestrated system can outperform a frontier model when the task is finding security bugs across a large codebase. The core idea is that even small models can recognize a vulnerability if they are given the right snippet of code with enough leading context. The challenge is deciding which snippets matter, where to look, and how to validate what the model thinks it has found.

Aisle’s platform reportedly combines agent orchestration, codebase-wide analysis, vulnerability hypotheses, validation loops, and reproduction workflows. It also works to triage candidate findings before presenting them to humans. That means maintainers receive fewer noisy reports and more reports that have already survived a round of automated validation. This kind of systematic approach matters because one of the biggest failures of early AI security scanners was not a lack of intelligence but a lack of focus. They generated enormous numbers of false positives, duplicates, and irrelevant findings, which consumed maintainer time without producing merges.

The startup’s broader pitch is that AI should not stop at discovery. Aisle says it can also generate patch suggestions and verification steps that help developers turn a confirmed bug into a merged fix more quickly. If that workflow holds up in practice, it would reduce one of the biggest bottlenecks in open-source security: not finding the bug, but having a qualified maintainer review, patch, test, and release it.

The maintainers’ perspective

Daniel Stenberg, who created Curl and remains the project’s lead maintainer, was initially skeptical of the flood of AI-generated security reports. Over time, though, he described the current moment as a high-quality chaos era. He expressed gratitude that powerful AI engines are scanning Curl, because finding flaws means they can be fixed. He also noted that Aisle seems to invest real engineering effort in producing curated results. The project’s maintainers are more likely to take every Aisle report seriously because the reports arrive with useful context and fewer false alarms.

Greg Kroah-Hartman, the Linux stable kernel maintainer often called Greg KH, shared a similar reaction on Mastodon. He wrote that he is seeing the same kind of results for Linux and said: I have no idea what Aisle is doing differently, but wow. That comment is significant because Kroah-Hartman deals with an enormous volume of security fixes and has little patience for AI-generated noise. His approval suggests Aisle is providing something beyond generic machine-scanning output.

Jim Fuller, a Red Hat senior principal software engineer focused on security, has speculated that Aisle understands the limitations of its tooling and has worked harder than simply running a scanner. Maintainers have also worked directly with Aisle, meeting, talking, and refining the output. This communication appears to be an important part of the process. A responsible AI security tool should not only find bugs; it should also respect the realities of how open-source maintainers review reports, issue CVEs, and write patches.

A valid result, with important limits

Aisle originally reported 29 candidate issues in Curl, but only six cleared the project’s security review bar and became CVEs. That does not make the other 23 reports worthless. Some may have been ordinary bugs rather than security vulnerabilities, some may have been duplicates, and some may still be under review. But the gap between 29 findings and 6 confirmed CVEs is a reminder that findings and confirmed vulnerabilities are not the same thing.

The fact that the accepted CVEs are low severity is another reason to avoid overstatement. Low severity means the vulnerabilities likely require unusual conditions, limited attacker control, or other mitigating factors. Still, low-severity bugs in a tool as widely deployed as Curl are worth fixing. They can become part of a chain when combined with other weaknesses, and removing them reduces the attack surface.

This outcome also highlights the value of validation by the project’s own maintainers. In most AI security comparisons, the vendor running the test controls whether a finding is counted. Here, Curl’s maintainers made the decisive call. They reviewed Aisle’s evidence, decided which reports represented security vulnerabilities, assigned CVE identifiers, created fixes, and shipped those fixes in a public version of the project. That process is far more credible than a score on a synthetic benchmark or a capture-the-flag exercise.

System versus model

Aisle is using the Curl results to advance what it calls a system-over-model argument. In that view, the quality of an AI security product depends less on the raw intelligence of the underlying model and more on the orchestration around it. A general-purpose model may be excellent at reasoning about code in the abstract, but it can produce inconsistent results when it is asked to scan an entire mature project in one pass. A specialized system may gain an advantage by continuously iterating over code paths, tracking configuration-specific behavior, correlating historical vulnerability patterns, and testing candidate issues before it presents them to a human.

This argument is reasonable. Many AI coding tools are built around a chat interface where a developer asks a question about a small piece of code. That works well for explaining functions or generating examples, but it is not the same as systematically hunting for subtle security flaws across a codebase with thousands or millions of lines of code. A tool designed for vulnerability hunting can incorporate threat models, security rules, and repository history into its scans. It can also keep track of what it has already examined and what it still needs to explore.

The front-end model matters, of course. No amount of orchestration can find a vulnerability if the underlying model cannot recognize unsafe code patterns. But the Curl result is an argument that model capability is not the only constraint. The surrounding system can compensate for some model limitations by giving the model the right context and by checking its conclusions through additional steps.

Why maintainer approval matters

Security tool comparisons have long struggled with the difference between a laboratory success and a production finding. Benchmark datasets contain known flaws, which means AI models can be overfitted to them, either deliberately or accidentally. Synthetic tasks may not reflect the messiness of real code. Vendor-verified results can be biased by the vendor’s own product goals. In the Curl case, none of those problems were central. The code was not chosen by Aisle, the vulnerabilities were not already known, and the evaluators were independent maintainers with a reputation for caution.

Curl’s codebase is also a difficult test. It is written in C, a language with many memory-safety pitfalls, but it has been reviewed by experts for decades. Any surviving bug is likely to be subtle and dependent on unusual usage patterns. The fact that Aisle found six such bugs suggests that its approach can add value even in an environment where traditional code review has already been thorough.

What this means for AI security tools

The Curl episode does not settle the broader question of which AI security tool is best. One successful result must be repeated across other projects, programming languages, and software architectures before it becomes a general pattern. Enterprises and open-source maintainers should still ask hard questions about how a tool handles false positives, how it validates its findings, and how much human review is required before a patch is ready.

But the episode does provide a clear lesson: real-world maintainer verification is the most meaningful signal available when evaluating an AI security product. A tool that can find correct, previously unknown vulnerabilities in a mature open-source project, and present them well enough for overworked maintainers to accept them, deserves attention. That is why the praise from Stenberg, Kroah-Hartman, and others in the open-source security community matters. They have seen countless AI-generated reports, and they are not easily impressed.

For security teams that have become skeptical of AI coding assistants, Aisle’s Curl results are a useful counterexample. The tool still needs to prove that it can perform consistently across many different codebases. But when some of the most respected maintainers in the world say they are seeing real vulnerabilities discovered by an AI system, it is worth investigating how that system works. If it can deliver high-quality, validated findings without burying maintainers in noise, Aisle may become an important part of the open-source security toolkit.

Source: ZDNET News