curl's Zero-Findings Week Became Six CVEs. The Zero Was Never About the Code.

What actually happened between Daniel Stenberg's August 24 post and curl 8.22.0, and why an empty findings list from an AI security tool means less than almost everyone reading it assumes.

On August 24, 2026, at 06:52 UTC, Daniel Stenberg posted a short status note nine days out from a curl release. Three CVEs pending, two low and one medium. Then a parenthetical: "Mythos says it can't find any more. Zeropath finds no vulnerabilities. Codex security shows an empty list."

That parenthetical went around the internet as proof that frontier AI security tools had declared curl clean. Nine days later curl 8.22.0 shipped with nine CVEs, six of them found by a different system in the days right after the post.

Both halves of that are true. The story almost everyone built on top of them is not.

The zero was a weekly delta, and Stenberg said so

Under the follow-up thread, someone pushed back that the numbers were wrong, that Mythos should be scored 1 rather than 0. Stenberg's answer: "correct. These numbers are for analyses done this week."

Read that again, because it dissolves the headline. The zeros were not "we scanned curl and it's clean." They were "we ran this week's pass on a codebase these tools have already been over, and this week's pass surfaced nothing new."

Every one of those scanners was already part of curl's routine tooling. Stenberg wrote in May: "Primarily AISLE, Zeropath and OpenAI's Codex Security have been used to scrutinize the code with AI. These tools and the analyses they have done have triggered somewhere between two and three hundred bugfixes merged in curl through-out the recent 8-10 months or so."

AISLE is in that sentence. It was not an outsider that arrived after a public zero and showed up the big labs. It was one of the three tools curl had been running for the better part of a year, and it happened not to be in the August 24 list.

So the actual shape of the event is duller and more useful than the viral version: a project with four AI scanners in rotation ran three of them one week and got nothing, ran the fourth a day later and got twenty-nine reports, six of which became CVEs.

Why this matters more than the scoreboard

Here is the position I'll defend: a zero from a code-scanning system is a statement about scope, cadence, and configuration. It is never a statement about your code. And the industry has no vocabulary for that distinction, which is exactly why a maintenance log turned into "OpenAI and Anthropic found zero" inside a week.

That gap has teeth. If you run these tools in a real org, someone gets a clean report and closes a ticket. The number zero carries a finality that "3 findings, 2 dismissed" doesn't. Nobody books a follow-up on "no findings."

curl is the best possible place to see this, because curl is not a codebase with easy bugs left in it. Stenberg's numbers: 176,000 lines of C, installed in over twenty billion instances, 188 published CVEs before this release, and every production line rewritten an average of 4.14 times. The Mythos report itself opened by conceding the point: curl is "one of the most fuzzed and audited C codebases in existence" and finding anything in the hot paths "is unlikely."

Three tools reporting nothing on that codebase in one week is close to the expected outcome. It was only surprising to people who thought a zero meant something else.

What AISLE actually did, with dates

Stenberg posted the comparison the next day: "Mythos: 0, Aisle: 29."

Twenty-nine reports, not twenty-nine bugs. And AISLE's own write-up notes that Stenberg posted that number before the review process was complete, which matters for anyone tempted to do arithmetic on it.

curl's security team, not AISLE, decided what was real and what warranted a CVE. Six made it. They were reported across three days, August 24 through 27, and shipped in curl 8.22.0 on September 2:

• CVE-2026-80229, OpenSSL provider use-after-free
• CVE-2026-80230, OpenSSL pinning bypass
• CVE-2026-80231, native CA store connection reuse
• CVE-2026-80255, secure cookie attribute bypass with tab
• CVE-2026-82208, wolfSSL CA-cache hit overrides callback
• CVE-2026-82209, domain-scoped public-suffix cookie

Every one credits "Stanislav Fort (Aisle Research)" as reporter. Five were patched by Stenberg, one by Stefan Eissing. All six are rated Low.

The release carried ten new CVEs in total: these six, the three Stenberg already had pending on August 24, and one for wcurl. Check the severities of the pending three against his post and they reconcile exactly. CVE-2026-13608 low, CVE-2026-18924 low, CVE-2026-19931 medium. Two low, one medium.

What got found is instructive about what's left in code this hardened. CVE-2026-80230 only bites if you set CURLOPT_PINNEDPUBLICKEY while also disabling CURLOPT_SSL_VERIFYPEER and CURLOPT_SSL_VERIFYHOST, a combination the advisory notes means "the user most likely must also have weakened security" already. It has been present since curl 7.45.0. CVE-2026-80229 needs the multi interface, OpenSSL 3 providers, and an easy handle destroyed while a pooled connection is still alive. Its advisory carries a tag I have not seen another project use: "This bug is considered a C mistake (likely to have been avoided had we not been using C)."

Narrow corners where two subsystems disagree. Real, reproduced, accepted by domain experts, and also nobody's emergency.

The number I keep turning over, and why it doesn't prove what it looks like

Six accepted out of twenty-nine submitted is about 21 percent.

The tempting move is to line that up against curl's own history. When Stenberg ended the curl bug bounty in January 2026, he published the trend that killed it: in the good years, "somewhere north of 15% of the submissions ending up confirmed vulnerabilities," falling below 5 percent starting in 2025. His line: "Not even one in twenty was real."

I am not going to make that comparison, because it isn't one. Those are confirmed-vulnerability rates. My 21 percent is a CVE-designation rate, and in curl's process those are different bars with a real gap between them. The Mythos report is the proof: five findings the model called "confirmed," which curl's team ground down to exactly one CVE after a few hours of digging. Three were false positives against documented API behavior and the fourth was "just a bug."

So the honest version is weaker and still worth having. One system produced twenty-nine reports and six of them cleared the highest bar curl has, on a codebase where three other systems had produced nothing that week. That's a good result. It is not a leaderboard position, and anyone selling it as one is doing marketing.

Which, to be fair, is what happened. AISLE published this under the headline "AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero," which names the two frontier labs, omits Zeropath, omits that AISLE was already in curl's rotation, and omits that the zeros were a one-week delta. Every individual claim in it is accurate. The frame is a sales document.

Put this into practice

You are not going to run an autonomous vulnerability system against curl this week. You are going to see a security tool return an empty list and have to decide what it means. Here is how I'd handle that now.

1. Record the scope, not the result. Before accepting a zero, get on paper: which paths, which commit, which analysis passes, what got skipped for size or timeout, and how long it ran. If the product can't tell you, that's your answer about what the zero is worth.

2. Record the cadence too. This is the curl lesson specifically. "No new findings since the last pass" and "no findings" are different sentences, and only one of them is usually true. Write the ticket as "System X reported no new findings on commit abc123, seventh weekly pass." That phrasing survives being read back in six months.

3. Expect diminishing returns and plan for them. Stenberg's own note is the honest version: "counted by the volume of issues found, all the previous AI tools we have used have resulted in larger bugfix amounts. This is only natural of course since the first tools we ran had many more and easier bugs to find." Your first scan will look amazing. Your tenth will look like failure and will actually be fine.

4. Run tools with different designs, not different logos. curl's four scanners find different things because they search differently. That's the actual mechanism behind the six-to-zero. Adding a second vendor that wraps the same model the same way buys you very little.

5. Never let the tool grade itself. The reason curl's numbers mean anything is that maintainers adjudicated. Mythos said five confirmed; humans said one. If your tool both finds and scores, you have a benchmark, not a finding.

The ten-second version: next time a scan comes back empty, add one sentence to the ticket naming the scope and whether this was a first pass or a delta. That single sentence is what stops "no findings" from silently becoming "no bugs."

Honest limitations

AISLE is selling this. The post is an argument for the company's "System over Model" thesis and ends with a link to buy an audit. Treat the framing accordingly, and note that the underlying facts still check out against curl's own records.

Six Low-severity bugs is a modest absolute result. The interest is in the contrast, not the impact. If you read this as "AI finds critical vulnerabilities humans miss," you have read it backwards.

Mythos was not a fair comparison subject. It was never publicly released. Anthropic chose to "trickle it out to a selected few companies," curl's access came free through the Linux Foundation and Alpha Omega, and Stenberg did not run it himself. Someone with access ran a scan and sent him a report. One report, one commit, one operator. That is not a product evaluation.

We don't know what happened to the other twenty-three reports. AISLE says six were reviewed within days and that the count was posted before review finished. Their disposition is not public. I would not assume they were rejected, and I would not assume they were real.

Greg Kroah-Hartman's reply is an impression. The Linux stable maintainer responded that he sees the same pattern in the kernel. That's one maintainer, offered casually, with no numbers. Suggestive, not evidence.

One release is not a trend. curl's next release is planned for the end of October.

Stenberg never framed this as an AI story. His 8.22.0 announcement lists the CVEs and mentions neither AI nor AISLE nor the comparison. He treated them as ordinary security reports, which is arguably the most interesting editorial decision in the sequence.

The bug bounty ending is a separate story. curl stopped paying rewards on January 31, 2026 and left HackerOne, but it did not stop accepting security reports; they moved to GitHub's private vulnerability reporting. Stenberg named three causes, not one: AI slop, human reports getting worse, and reporters who "poke holes rather than help."

What to do with this

The durable finding here isn't about AISLE and it isn't really about curl. It's that a routine weekly maintenance result, posted by a maintainer in a parenthetical, became an industry-wide claim about model capability inside seven days, and nothing in how we talk about security scanning slowed that down for a second.

Your tooling is going to hand you a zero this month. The only question that matters is what it was looking at, how deep, and compared to when. Ask your vendor that this week. It costs them ten minutes and tells you more than any number on the pricing page.

And if you're the person who closes tickets on clean scans, you already know what the next ticket needs to say.

---

Sources: Daniel Stenberg's August 24 post · Mythos finds a curl vulnerability · AISLE's write-up · curl 8.22.0 release announcement · curl 8.22.0 changelog · curl CVE index · The end of the curl bug-bounty