The 18 CVEs in curl 8.21.0 — the "High-Quality Chaos" That Followed the End of the Bug Bounty

Introduction — 18 CVEs in One Release
Checking the Numbers First — curl's First Half of 2026
How We Got Here — the Slop Era and the Death of the Bug Bounty
"High-Quality Chaos" — Not Slop, but the Real Thing, Pouring In
What the 18 CVEs Actually Fixed
The Bug That Didn't Become a CVE — the First CNA Dispute
On the Feature Side — MASQUE Proxying, Named Glob, and Advance Removal Notices
What Changes in Practice
Closing
References

Introduction — 18 CVEs in One Release

On June 24, 2026, curl 8.21.0 was released. Daniel Stenberg's per-release statistics showed up as usual, and one line jumps out. The 275th release, a 56-day cycle, 531 commits, 276 bug fixes, 6 new features — and 18 security fixes.

Eighteen CVEs in a single release is the most in curl project history. It's already a record for 2026's yearly total, too. Looking at that number alone, you might think "something's gone wrong with curl" — but break the 18 down and the story changes. 4 Medium, 14 Low. No High, no Critical. curl's last High-severity CVE is still CVE-2023-38545 (a SOCKS5 heap overflow) from October 2023.

So the real story of this release isn't "curl has become dangerous." It's that the security-report ecosystem has structurally changed this year, and curl is at the front line of that shift. This post follows that process — the slop era, the end of the bug bounty, the failed GitHub migration, and the present moment Stenberg calls "High-Quality Chaos" — through primary sources, and lays out what changes in practice.

Checking the Numbers First — curl's First Half of 2026

curl publishes its entire vulnerability history as machine-readable data (vuln.json). Rather than taking the blog post's claim at face value, I counted this file directly. Here's the number of CVEs per year, by publication date.

Year	CVEs Published
2020	6
2021	13
2022	21
2023	18
2024	11
2025	9
2026 (through June 24)	36

Broken down by 2026 release: 6 on January 7 (8.18.0), 4 on March 11 (8.19.0), 8 on April 29 (8.20.0), and 18 on June 24 (8.21.0). That's 36 in total — already surpassing the previous record year, 2022 (21), before the first half of the year was even over. By single-publication-date count, too, this 18 is the most ever; the previous record was 11, on November 2, 2016. The blog's "record" claim matches the data exactly.

One caveat. This is not a graph of "curl's code suddenly got worse" — it's a graph of "the rate of discovery changed." That distinction is the theme of this whole post.

How We Got Here — the Slop Era and the Death of the Bug Bounty

You need the timeline to read the current situation. All of it is Stenberg's own record.

April 2019 — curl's bug bounty launches on HackerOne. By the time it's abolished, it has 87 cumulative confirmed vulnerabilities and over $100,000 paid out to researchers.
January 2024 — "The I in LLM stands for intelligence". LLM-fabricated vulnerability reports start becoming a public issue.
July 2025 — "Death by a thousand slops". Slop surges. The confirmation rate (real vulnerabilities as a share of submissions), which had run above 15% in prior years, drops below 5% in 2025 — fewer than one in twenty submissions turns out to be real.
January 26, 2026 — Announcement ending the bug bounty. Rewards are fully abolished as of January 31. The stated reason was "to remove the incentive to submit fabricated lies," and the reporting channel also moves from HackerOne to GitHub's Private Vulnerability Reporting.
February 25, 2026 — A month later, announcement of a return to HackerOne. Rewards remain gone, but the platform moves back to HackerOne starting March 1.

He also left a record of why the GitHub migration failed, and the list doubles as a ready-made checklist for any team weighing a vulnerability-intake system. You can't turn off the full report text going out in plaintext notification emails (early-leak risk); there's no way to flip an invalidated report to public status (curl's principle is to publish even wrong reports); curl is its own CNA and issues CVE numbers directly, but the CVE field in GitHub's form isn't editable; and there's no labeling feature for tracking slop statistics. Stenberg's conclusion: "the tooling for open-source projects trying to run proper vulnerability intake without a bounty is generally inadequate."

"High-Quality Chaos" — Not Slop, but the Real Thing, Pouring In

Did dropping the bounty mean fewer reports? The opposite happened. The numbers are in April's "High-Quality Chaos" and May's "The pressure".

Slop stopped being the problem. Instead, report frequency reached 4-5x the 2024 rate — itself double the 2025 rate — for more than one report a day on average.
The confirmation rate has returned to pre-AI levels (around 15-16%), and even exceeds them. The share of reports that aren't vulnerabilities but are real bugs has also risen well above what it used to be.
And nearly every report shows signs of AI use — in writing style, in structure, and, apparently, in duplicate reports arriving simultaneously with a level of sophistication no human could produce.

So if 2025's problem was "fakes fabricated by AI," the problem starting in March 2026 is AI-armed researchers finding real bugs faster than humans can process them. Back in April, Stenberg projected that "at this rate, we could get close to 50 CVEs this year" — and with 36 already by June 24, that projection is tracking.

It's also important that this isn't curl-specific. In an informal poll Stenberg ran on Mastodon, projects like Apache httpd, BIND, Django, Firefox, git, glibc, GnuTLS, HAProxy, the Linux kernel, OpenLDAP, Python, Ruby, urllib3, Wireshark, and wolfSSL confirmed the same trend. It's safer to assume the CVE publication rate is rising across your entire dependency tree.

Meanwhile, there was an interesting contrasting case in May. Mythos, a model that made headlines because Anthropic said its ability to detect security flaws was "dangerously good enough that we're disclosing it selectively for now," scanned curl via the Linux Foundation — and the result was just 1 confirmed vulnerability (Low). When the security team verified the report's claimed "5 confirmed," 3 turned out to be false positives and 1 was just a plain bug. In the same post, Stenberg reveals that AI analysis tools like AISLE, Zeropath, and OpenAI Codex Security have already led to 200-300 bug fixes and more than a dozen CVEs in curl over the past 8-10 months. His assessment is two-sided: mystifying any one model is closer to marketing, but it's also true that AI code analyzers in general clearly find more than traditional static analyzers do. And one key observation — AI doesn't invent new categories of vulnerability, it just finds more new instances of categories we already know about.

What the 18 CVEs Actually Fixed

That observation shows up directly in 8.21.0's CVE list. Skim the titles of 2026's 36 CVEs and one word keeps repeating: reuse. By my count, "reuse" appears in the title of 10 of the 36 — wrong STARTTLS connection reuse, wrong reuse of SMB connection, connection reuse ignores TLS requirement, incomplete mTLS config matching in conn reuse, and so on.

That's not a coincidence. libcurl keeps completed connections in a pool and reuses them for later transfers when the configuration matches, and deciding "the configuration matches" is only safe if you compare every dimension that affects trust — host, port, protocol, TLS options, client certificate, proxy, auth state — without missing any. Every dimension you skip produces one more bug that "wrongly reuses a connection from a different security context." Once one case gets published as a CVE, researchers armed with AI tools start systematically mining variants of the same class. The 2026 CVE cluster is the trace left by that mining.

Picking out the individual cases worth a closer look from a protocol-plumbing angle (severity and affected versions per curl's own disclosures):

CVE-2026-9545 — HTTP/3 early data exposure (Low). With the TLS session cache and CURLSSLOPT_EARLYDATA enabled, reconnecting to the same host could send request bytes out over 0-RTT before certificate-verification failure was confirmed. Present since 8.11.0 (November 2024). A textbook case of why 0-RTT is disabled by default — beyond replay attacks, there's also the trap of verification ordering.
CVE-2026-11352 — QUIC zero-length UDP datagram busy-loop (Low). The receive helper discarded zero-length datagrams without counting them against the per-call packet budget, so a malicious server could keep the client stuck indefinitely by streaming empty datagrams. A regression introduced in 8.18.0 (January 2026), caught in June. Because QUIC's receive path lives in userspace, every one of these budget-logic details is an availability boundary — exactly the point covered in QUIC Receiver-Side CPU Cost.
CVE-2026-10536 — HTTP/2 stream-dependency-tree UAF (Low). Building a dependency tree with CURLOPT_STREAM_DEPENDS and then cleaning up after curl_easy_reset() touched an already-freed struct again. Present since 7.88.0 (February 2023). What's interesting is the response — 8.21.0 didn't stop at fixing the bug, it removed stream-dependency tracking entirely. RFC 7540's priority tree is a mechanism already marked deprecated in follow-on standards, so rather than keep a barely-used attack surface alive, they tore it out.
CVE-2026-8924 — trailing-dot super cookie (Low). The cookie parser's Public Suffix List check could be bypassed, letting a malicious server plant a cookie that gets sent to an unrelated third-party domain. Introduced in 7.46.0 — December 2015. A bug that stayed dormant for over a decade, passing fuzzers, static analyzers, and audits alike, finally caught by this wave.

The 4 Medium cases are a SASL double-free, two cases of proxy/cross-origin Digest-auth state leaking, and a long-standing proxy password leak. These are all in the class of auth state crossing connection or redirect boundaries, which matters in real terms for deployments that sit behind a proxy — worth checking the list yourself.

The spread of introduction versions is also worth noting — everything from 2015 vintage to a regression from this January is mixed in together. When the tools for finding bugs get better, old sediment and fresh mistakes surface together.

The Bug That Didn't Become a CVE — the First CNA Dispute

On the opposite side of the CVE flood, there's the story of the first CVE dispute, published the same day. curl has been its own CNA since January 2024, so it decides for itself whether to issue a CVE within its own scope — and this is the first time that decision was escalated all the way to MITRE.

The bug itself was real. The wildcard-certificate matching function would wrongly match a hostname starting with a dot, like https://.example.com/, against the *.example.com wildcard, and it was fixed on December 8, 2025. But since dot-leading names are illegal in DNS, they're unreachable at all without local intervention like /etc/hosts, and the attacker would also need to hold that wildcard certificate — the preconditions stack up so heavily that curl's security team classified it, in their internal terms, as "below Low" and didn't issue a CVE. The reporter disagreed and escalated a dispute to MITRE, which asked the same question three times over February, May, and June before handing down a final ruling on June 24 — no CVE issued, the CNA's judgment stands.

What makes this episode matter isn't the ruling itself but the cost logic behind it. By Stenberg's estimate, libcurl is installed on tens of billions of devices worldwide — in his own words, somewhere between 20 and 30 billion — and every CVE published sets off scanners on security teams everywhere, triggering a chain of patch and update work. That cost is paid by the ecosystem, not by curl. So it's also part of a CNA's responsibility not to raise an alarm over a theoretical problem that's actually unreachable. A project that published 36 CVEs this year, and also fought for over four months not to publish one — both facts come from the same principle: judge by real risk, not by the count.

On the Feature Side — MASQUE Proxying, Named Glob, and Advance Removal Notices

Buried under the security story, there are also some substantial items among 8.21.0's 6 new features from a plumbing perspective, per the official changelog.

HTTP/3 proxy support — CONNECT and MASQUE CONNECT-UDP (ngtcp2 QUIC builds only). Until now, curl's proxying topped out at HTTP/1.1 or HTTP/2; now you can punch through the proxy leg itself with HTTP/3 and carry UDP (i.e., end-to-end QUIC) over it via CONNECT-UDP. It's one more tool for testing MASQUE-style proxying outside of large deployments like iCloud Private Relay.
named glob — a CLI convenience feature that names a URL glob so it can be referenced in output filenames, including glob references on the upload side.
Removed: HTTP/2 stream-dependency tracking (covered above), and CURLAUTH_DIGEST_IE, which existed for IE6 compatibility.

And the removal-notice list at the end of the release notes might actually be the most urgent part for practitioners. The built-in crypto implementation, NTLM, SMB, and TLS-SRP are listed as removal candidates, and anyone using those features is explicitly told to speak up on the curl-library list now. This wave of stripping out legacy auth and protocols runs in exactly the same direction as OpenSSH 10.4's list of deprecations. Given how much enterprise internal-network automation still leans on NTLM proxy auth, this notice isn't something to quietly skip past.

The next release is announced for September 2, with the cycle extended by two weeks for the summer break.

What Changes in Practice

Whether you link libcurl directly or it's just sitting there as a distro package in your base image, here's roughly where this trend touches your team.

Scanner noise increases. With curl's CVE count jumping from 9-11 a year to 36+ this year, curl entries will noticeably pile up in your container image scan results. The good news is that curl's disclosure quality is top of the industry — each detailed page states everything from the introducing commit to the fixed version, and vuln.json is served in an OSV-compatible schema, so you can build a pipeline that automatically determines "is our version actually in the affected range."

Severity is a value you should re-evaluate, not just consume. curl's rating is a curl's-eye-view rating that assumes "we don't know how the user is using this." For instance, if you've never enabled CURLSSLOPT_EARLYDATA, CVE-2026-9545 doesn't apply to you, and if you've never used the stream-dependency API, neither does CVE-2026-10536. Conversely, if your environment has a lot of proxy-plus-auth combinations, you need to take the 4 Medium cases more seriously than their rating suggests.

There's no basis for panic. The fact that curl's vulnerabilities have all been Low/Medium in recent years, with the last High back in October 2023, is a real measurement of a codebase that has received a different order of scrutiny for decades. But you should take the opposite lesson too — even a codebase scrutinized this thoroughly produced 36 CVEs in half a year once the tools got better. Your in-house C code, with its shallower scanning history, would produce far more. As Stenberg puts it, a project that doesn't run AI analyzers is effectively giving attackers a head start to find the same things with the same tools.

Keep the maintainer-side cost in view too. Verifying, fixing, and disclosing more than one security report a day is currently being shouldered by a small handful of people, and in his May post Stenberg publicly raised concerns about health and working hours for the first time, asking commercial users to sign support contracts. As this trend spreads across your whole dependency set, each project's response capacity becomes your supply-chain risk. Whether this wave eventually hits a plateau the way fuzzing did is something even Stenberg himself says he can only "wait and see."

Closing

To sum up: the 18 CVEs in curl 8.21.0 are not a signal that the code got worse — they're a signal that, since March 2026, the security-research ecosystem has rearmed with AI and the rate of discovery has structurally jumped. The slop era ended along with the bug bounty, and what's arriving now is a flood of real bugs — mostly Low, a mix of old sediment and fresh regressions, concentrated in specific bug classes like connection reuse.

curl is getting through this wave with record-level transparency — detailed per-case disclosure, machine-readable data, and even the same seriousness applied to rejecting a CVE as to issuing one. What we need to do is straightforward: build a pipeline that triages the growing curl entries in scanner results by actual impact scope, check right now whether your own workload touches the removal-notice list like NTLM and SMB, and adjust your patch cadence for an era when CVE publication rates are rising across your entire dependency set. And the habit of reading severity and preconditions before being alarmed by the number, the next time you see "18 security fixes" in some release notes — that's the basic skill of this new era.