AI tool found 6 Curl vulnerabilities Mythos and Codex missed

What happened

The HTML source is raw; let me grep out the actual article body text from the fetched content. Now I have all the article content. Let me write the article following the exact specifications.

An AI-native security startup called Aisle reported on September 4, 2026 that its vulnerability-management system uncovered six previously unknown bugs in Curl, the ubiquitous open-source networking and file-transfer library. The six findings were accepted by Curl's maintainers, assigned Common Vulnerabilities and Exposures numbers, patched, and shipped in Curl 8.22.0, released September 2. The result drew attention partly because of what came first: Curl founder Daniel Stenberg had written on Mastodon that Anthropic's Mythos, OpenAI's Codex Security, and ZeroPath had found no additional vulnerabilities in the project, while Aisle simultaneously reported 29 candidate issues, six of which cleared Curl's security review bar.

This piece is for security engineers, open-source maintainers, and developers who depend on Curl in production, as well as anyone evaluating AI-assisted vulnerability tooling. It covers how Aisle's approach differs from general-purpose AI coding tools, what the six confirmed CVEs actually represent, what builders should verify in their own environments, and what the episode does not yet settle about the relative performance of these systems.

How it works

Aisle submitted a batch of candidate security reports to the Curl project. Stenberg and the maintainer team reviewed each one, accepted six as genuine vulnerabilities, issued CVEs, and incorporated the fixes into the Curl 8.22.0 release on September 2. Curl's own advisory database classifies all six CVEs as low severity, and the project's release notes list them among 10 total security vulnerabilities addressed in that version. The accepted findings arrived in the same window that Stenberg publicly noted that Mythos, Codex Security, and ZeroPath had reported no additional vulnerabilities, a contrast that Stenberg described not as an indictment of those tools but as evidence that finding real bugs in mature, hardened code has become the new normal for capable systems.

Stenberg welcomed the results, writing on Mastodon that he is grateful when AI engines scan Curl to find flaws, because finding them means they can be fixed. He characterized the current moment as the "high quality chaos era," distinguishing it from an earlier period when AI tools produced large volumes of false positives and low-signal noise reports that maintainers had to sift through at significant cost.

Anyone running a version of Curl older than 8.22.0 carries these six unpatched vulnerabilities. Curl is embedded in an enormous range of software: Linux distributions, embedded systems, mobile SDKs, web servers, API clients, CI pipelines, and container base images all commonly ship or call Curl. Because all six CVEs are rated low severity by Curl's advisory database, the immediate risk profile is not catastrophic, but low severity in Curl's maintainer judgment still means confirmed security vulnerabilities in code that handles network data, and that classification can shift when issues are chained with other weaknesses in a specific deployment context.

Why it matters

Organizations that consume Curl indirectly, through a system library or a packaged dependency, should not assume that their distribution has already applied the Curl 8.22.0 patches. The patching timeline varies by Linux distribution, container registry, and embedded vendor. Any builder who has frozen a base image or pinned a library version without checking the Curl advisory should audit their dependency chain and confirm which version is actually running in production.

The first action is straightforward: determine what version of Curl is running in every environment you control, then compare it against 8.22.0. On Linux systems, the version is typically visible through the package manager or by running the Curl binary with the version flag. Container images should be inspected at the layer level, since base images often bundle their own Curl installation independently of any application-level dependency. If the installed version predates 8.22.0, update it through the appropriate package manager or rebuild the container image from a patched base.

Who is affected

The second action is methodological. The Curl episode illustrates that agentic security tools can surface real bugs in production code that general-purpose AI models miss during standard scans. If your security review process relies solely on tools like Codex Security or Mythos for vulnerability discovery in C codebases, the Curl result is a prompt to evaluate whether a specialized, system-level scanning approach offers meaningfully better coverage for your highest-risk dependencies. Curl's maintainers found that engineering-level cooperation with Aisle, including curated reports and direct communication, was part of what made the findings actionable.

Aisle's disclosed rationale is that its system does not depend on expensive frontier models to find vulnerabilities. The company's stated position is that even small models can recognize a vulnerability when handed the right snippet of code with the right leading context. The system tests whether models with adequate intelligence and high throughput, deployed systematically across an entire codebase, can surface real bugs without hand-scoped snippets prepared in advance by a human analyst. According to Aisle, the answer in the Curl case was yes.

The broader mechanism Aisle describes combines vulnerability discovery and triage with patch generation and verification. Rather than delivering a raw report, the platform claims to produce a developer-reviewable remediation and supporting validation alongside each candidate finding, an approach intended to reduce the labor that security teams and maintainers must spend converting alerts into merged fixes. Greg Kroah-Hartman, the maintainer of the Linux stable kernel, noted publicly that he is seeing similar results for Linux, adding that he has no clear explanation for what Aisle is doing differently. Jim Fuller, a Red Hat senior principal software engineer specializing in security, speculated that Aisle combines tool awareness, knowledge of tooling limitations, and engineering effort beyond a simple scanner run.

What to watch next

The Curl result is a single data point from one project and one testing sequence. Six confirmed low-severity CVEs is a meaningful outcome, but it does not establish a general performance ranking among Aisle, Mythos, and Codex Security across different codebases, programming languages, or operational environments. Aisle submitted 29 candidate issues in total; 23 did not receive CVEs, and those reports have not been publicly characterized as false positives, duplicates, ordinary bugs, or still-under-review submissions. The distinction between "findings" and "confirmed vulnerabilities" matters, and the full breakdown has not been released.

It is also not clear how the six CVEs were distributed across Curl's attack surface, whether they cluster in a particular subsystem, protocol handler, or memory management path, or whether they represent issues that more targeted manual review would have found first. The broader question of whether Aisle's approach is repeatable at similar quality across other mature C projects, interpreted languages, or different dependency ecosystems remains unanswered by the Curl episode alone. Stenberg himself framed the result as a positive development for open-source security rather than a comparative verdict on any specific AI product.