Mythos Said There Was Nothing Left in curl. A Startup Found Six CVEs
By Surya Pratap
September 24, 2026
10 min read
AI & Technology
September 24, 2026
10 min read
Zero, then twenty-nineHover to exploreOn 24 August, Daniel Stenberg, who maintains curl, posted two short status lines. Anthropic's Mythos, he wrote, "says it can't find any more." OpenAI's Codex Security "shows an empty list." The next day he posted a scoreboard: Mythos: 0 / Aisle: 29.
Six of those twenty-nine reports became CVEs, and they were fixed in curl 8.22.0 on 2 September. Most coverage has been some version of startup beats OpenAI and Anthropic. That is true as far as it goes. It is also the least useful thing to take from the episode.
Figures in this article come from AISLE's account of the August findings (2 September 2026), curl's own vulnerability table, Daniel Stenberg's write-up of the Mythos scan (11 May 2026), and ZDNET's reporting (4 September 2026). AISLE is a vendor describing its own result; curl's advisory data is the independent check. The reading from section 3 onward is mine.
The timeline is short enough to state in full.
Anthropic and Alpha-Omega ran Mythos over the codebase. It reported five "confirmed security vulnerabilities." curl's security team reviewed them and kept one, rated low severity. Three were false positives describing documented API behaviour, one was "just a bug," and about twenty further non-security bugs came out of the run. Stenberg's verdict: the hype was "primarily marketing," and Mythos was perhaps "a little bit better" than earlier tools, not dramatically so.
Mythos can't find any more. Codex Security: empty list. ZDNET adds that ZeroPath, another AI scanner, had also found nothing new.
By 28 August, curl's count of pending CVEs had gone from three to ten, six of them from AISLE.
curl's table lists the six: an OpenSSL provider use-after-free, an OpenSSL pinning bypass, native CA store connection reuse, a secure-cookie attribute bypass with a tab character, a wolfSSL CA-cache hit overriding a callback, and a domain-scoped public-suffix cookie. All six are rated low. Some reach back a long way — the pinning bypass affects every version since 7.45.0.
AISLE also says it was credited with six CVEs in the June release, 8.21.0, including one it describes as the oldest curl vulnerability ever reported, introduced in March 2001. I have not been able to confirm the attribution for that round against curl's own pages, so I leave it out of the argument below.
Greg Kroah-Hartman, the Linux stable kernel maintainer, added the line that turned this from a curl story into a general one: "I'm seeing the same for Linux as well. No idea what Aisle is doing differently, but wow…"
Here are the two runs on curl with enough published numbers to compare:
Those are not the same measurement. Mythos's five were already labelled as confirmed vulnerabilities, while AISLE's 29 were reports, and some of the other 23 may have been legitimate bugs rather than noise. But the rough point survives the caveat: AISLE did not win on precision. Both systems put about four unconfirmed reports in front of a maintainer for every one that turned into a real finding.
The difference was not that AISLE was right more often. It was that AISLE was still looking after the other tools had stopped.
That changes what the story is about. A frontier model that runs, reports what it found, and then says there is nothing left has told you where its search ended. AISLE's result says curl's bugs had not ended there. The capability that mattered was coverage, not judgement on any single finding.
This is the part that applies to you even if you never touch curl.
When a scanner says it found nothing, you learn what that tool could see from where it looked. You do not learn that the code is clean. That was always true of static analysers and fuzzers, and security engineers already run several of them for exactly that reason. The new risk is that AI scanners explain their results fluently, and "I have reviewed the codebase and found no further vulnerabilities" sounds like a conclusion rather than a coverage boundary.
Two ways to read the same zero
Read as a verdict: the code has no more findings of this kind. Ship it.
Read as a boundary: this tool, with this prompt, this context budget and this search strategy, stopped producing findings. Something with a different strategy may not.
curl in August is a clean case of the second reading being correct — on one of the most fuzzed, most audited C codebases in existence.
If a mature project with a full-time security process can have six real CVEs sitting behind two empty lists, a twelve-month-old SaaS codebase that ran one AI scan before its SOC 2 audit has not established much.
Neither AISLE post publishes an architecture, so anything specific about how they work is speculation and I will not offer it. Two things are on the record, and they are enough.
The first is AISLE's own framing: "Cybersecurity capability is jagged: for well-defined security tasks, smaller models can outperform much larger and more expensive LLMs." That matches what we see building narrow agents. A general model is tuned to be good at everything reasonably often. A system built for one task can spend its whole budget on that task's search space — which subsystems, which configurations, which interactions between TLS backends and connection reuse — and all six August findings live in exactly that kind of corner.
The second is what the maintainer noticed. Stenberg's praise was not about raw capability. He said AISLE "spend proper engineering time to make sure that we get curated results of top quality." Jim Fuller at Red Hat said something similar: it "has worked harder than just running a scanner."
Put those together and the product becomes clear:
It is not a better model. It is a search strategy aimed at one domain, plus human-grade curation before anything reaches the person who has to act on it. Mythos and Codex Security are general tools made available to everyone. AISLE is a system someone engineered for this job and was willing to keep running after the obvious ground was covered.
This episode is about the cleanest public evidence yet for an argument founders keep having with investors: what stops the lab from doing this?
The lab's tool stops where it is general. Mythos and Codex Security are built to work on any repository. That breadth is exactly why they gave up on curl first. Your wedge is the depth they can't justify building for one vertical.
Sell accepted outcomes, not raw output. curl did not care about 29 reports. It cared about six CVEs and the maintainer time it took to reach them. If your product produces findings, drafts or leads, the number your buyer feels is what survives their review, per hour of their time.
Curation is product, not overhead. The same 20% hit rate is a gift when someone has checked it first and a cost when it has not. Stenberg calls the current state of AI security reporting a "high quality chaos era." A product that absorbs that chaos is worth more than one that sends it on.
Pick a ground truth that someone else grades. AISLE's claim is credible because curl's maintainers, not AISLE, decided what counted. Find the equivalent in your domain — an auditor, a regulator, a merged pull request — and report against that instead of your own dashboard.
The uncomfortable half of the same lesson: if your product is a thin wrapper that runs a frontier model once and formats the answer, this is what your competitor looks like.
Four changes, all cheap:
Two general-purpose frontier tools often share blind spots. Pair one of them with a traditional static analyser, a fuzzer on your parsers, or a specialised tool. Diversity of method is what finds the second layer.
Record which tool, which version, which paths, which date. An empty result with no scope is what gets quoted in a security questionnaire as proof of something it never measured.
At one real finding in five, a scan that returns forty items is a week of engineering time. Decide who reviews and how fast before you turn the tool on, or the reports will sit and rot.
Four of curl's six August findings sit in TLS-backend behaviour and the other two in cookie parsing edge cases — configuration interactions, not the obvious request path. In your product the equivalent is usually auth edge cases, multi-tenant boundaries and anything that caches credentials.
AISLE is the source for most of the story. The timeline, the 29 and the framing come from AISLE's own post. curl's table independently confirms the six CVEs and their severities; nothing independent confirms how much compute, time or human effort went into producing them.
The comparison is not controlled. Mythos ran in May, AISLE in late August, on a codebase that changed in between and had already absorbed Mythos's findings. That arguably makes AISLE's result harder, not easier, but it is still not a benchmark.
All six are low severity. That is typical for curl, which rarely has anything else left to find, but it means this episode shows coverage, not the ability to find critical bugs that others missed.
The 20% versus 21% comparison is loose. The two denominators were labelled differently, as section 2 says. I use it to show that precision was not the obvious difference, not to claim the two are equally precise.
Kroah-Hartman's Linux remark is one sentence. "Seeing the same" is a signal worth watching, not a published result.
The easy version of this story is David and Goliath. The more useful version is about what an empty result means.
Two of the best-funded AI systems in the world looked at a heavily audited codebase and said there was nothing left. Both were being accurate about their own search. A narrower system with a different strategy, and people who checked its output before sending it, found six real vulnerabilities within days. Its hit rate was no better. It just kept going and cleaned up after itself.
For a founder building on top of frontier models, that is the moat stated plainly: depth in one domain, and curation before anything reaches a human. For a founder shipping code, it is a warning stated just as plainly.
Treat every "no findings" as the edge of one tool's search, and write down where that edge was.
Sources: AISLE, "AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero", Stanislav Fort, 2 September 2026 — the 24 and 25 August Stenberg quotes, the 29 reports, the pending-CVE count moving from three to ten, and the Kroah-Hartman quote are as published there. curl vulnerability table for 8.21.0 — the six CVE identifiers (CVE-2026-80229, -80230, -80231, -80255, -82208, -82209), their titles, affected version ranges and low-severity ratings. Daniel Stenberg, "Mythos finds a curl vulnerability", 11 May 2026 — the five claimed, one confirmed, three false positives and roughly twenty bugs, and the "primarily marketing" assessment. Steven Vaughan-Nichols, ZDNET, via Yahoo Tech, 4 September 2026 — the ZeroPath detail, the "high quality chaos era" and "curated results" quotes from Stenberg, and Jim Fuller's remark. AISLE's June claims come from AISLE's 8.21.0 post, including the "jagged" quote. The ratio comparison in section 2 and everything from section 3 onward are mine. For another case where an agent's own report was the wrong thing to trust, see your coding agent pinned the commit. For the argument that small models win narrow decisions, see most of what your agent calls an LLM for is a yes or a no.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
