The pressure: open-source security teams under the AI-assisted vulnerability flood

What is this?

On May 26, 2026, curl’s lead developer Daniel Stenberg published The pressure — a short, personal post describing what AI-assisted vulnerability research is now doing to the security pipeline of one of the most ubiquitous pieces of open-source software in the world. The numbers are blunt: incoming security reports running at four to five times the 2024 rate and double the 2025 rate, more than one report per day on average, and twelve confirmed CVEs already queued with half the release cycle still to go, putting curl on track for at least thirty published CVEs in 2026 before the half-year mark.

This is not a vulnerability advisory. It is the line item we are covering here precisely because the phenomenon Stenberg describes is no longer isolated to curl. Simon Willison summarised the post the same day. Help Net Security had documented the broader pattern eight days earlier, with Linus Torvalds calling the Linux kernel security mailing list “almost entirely unmanageable” and GitHub’s product-security team publishing new submission requirements to filter AI-padded reports. The story is the workflow shift, not the bug count.

How it works

There is no exploit here. The mechanism is operational, and it has gone through two distinct phases in the past eighteen months.

Phase                Period           Dominant signal               Maintainer response
-------------------- ---------------- ----------------------------- -------------------------------
1. AI slop           mid-2024 → 2026  Low-quality hallucinated      Bounty programs raise quality
                                      vulnerability reports         bars; some shut down
2. High-quality      March 2026 →     Detailed, credible, often     "Never-before seen pressure";
   chaos             ongoing          duplicated AI-assisted        re-baselining of patch SLA,
                                      reports                       team capacity, disclosure flow

Phase 1 — AI slop. Through 2025 and into early 2026, projects with public bounty programs were drowning in plausible-looking reports that did not survive verification. Stenberg’s January 2026 post The end of the curl bug-bounty documents the curl trajectory: confirmed-vulnerability rate collapsing from north of 15% in 2024 to below 5% in 2025, and the bounty program closed on January 31, 2026. Apache Log4j, Nextcloud and other projects walked the same path. Help Net Security cites Daniel Stenberg’s own accounting putting AI slop at roughly 20% of curl submissions in 2025, with only about 5% of all submissions turning out to be genuine vulnerabilities.

Phase 2 — high-quality chaos. Stenberg’s April 22, 2026 post High-Quality Chaos documents the inflection. After curl moved reporting to GitHub then back to HackerOne without bounties, the slop dropped sharply and the confirmed-vulnerability rate “is back to and even surpassing the 2024 pre-AI level, meaning somewhere in the 15-16% range” — while the absolute report volume kept rising. Almost every report now shows AI-assistance fingerprints, including “very detailed duplicates in ways that can’t be done had they been written by humans”. The May 26 post is the same person, six weeks later, describing what happens to a maintainer team when the good report rate also climbs past one per day on a project with about thirty billion installations.

A non-exhaustive list of projects whose maintainers have publicly confirmed the same trend to Stenberg: Apache httpd, BIND, Django, Elasticsearch Python client, Firefox, git, glibc, GnuTLS, GStreamer, Haproxy, Immich, libssh, libtiff, Linux kernel, OpenLDAP, PowerDNS, Python, Prometheus, Ruby, Sequoia PGP, strongSwan, Temporal, Unbound, urllib3, Vikunja, Wireshark, wolfSSL.

Why it matters

Three shifts make this worth treating as a security topic and not a community-management one.

First, the disclosure pipeline is the bottleneck, not the bugs. Help Net Security quotes Shubham Shah of Assetnote noting that organisations now take far longer to review legitimate reports — the feedback loop that keeps top researchers engaged is degrading. If a maintainer team cannot triage at the rate AI-assisted research can submit, the project’s effective time-to-fix lengthens regardless of how good the underlying tools are. The same model that finds a bug for a defender can find the same bug for an attacker; the longer the queue, the longer the window.

Second, the cost is being absorbed by a small, untenured population. Stenberg’s post is unusually candid about working 50-hour weeks, “all days of the week”, and being told by his wife to slow down. The curl project is not owned by a company, is not part of an umbrella organisation, and has roughly the headcount it had five years ago. The Apache Log4j PMC, per Piotr P. Karwasz in the comments to the bounty-shutdown post, is grappling with the same constraint. This is a single-point-of-failure for libraries that sit underneath a substantial fraction of the world’s software.

Third, the dominant variable is now governance, not detection. Mozilla’s public note on Mythos-assisted Firefox triage describes 271 latent defects fixed before Firefox 150, with the observation that “the defects are finite”. Even if true, that finite tail still has to pass through human-reviewed disclosure, fix, release, downstream packaging and end-user update. Those stages are not subject to AI-speed compression today.

Defenses

The defensive playbook here is operational rather than technical, and applies whether your team maintains an open-source library, runs a bug-bounty program, or consumes upstream advisories. None of these recommendations require frontier-tier model access.

1. Set submission requirements that match the new reality. GitHub’s revised bug-bounty rules, published in May 2026, are a usable template: working proof-of-concept demonstrating concrete security impact, validation of AI-assisted findings before submission, concise reports rather than AI-padded prose, and explicit closing of reports covering known ineligible categories. The Linux kernel’s responsible-use-of-AI guidance is a second reference. Both are short and survive translation into smaller projects’ policies.

2. Decouple reporting from monetary rewards where slop is the dominant problem. curl’s January 2026 decision to keep the disclosure channel open while removing bounties is the cleanest natural experiment available: post-change, confirmed-vulnerability rate recovered to pre-AI levels. The lesson is not “abolish bounties” — large vendors still benefit — but “the bounty incentive needs design specific to AI-era submissions”. HackerOne and Bugcrowd are layering AI-assisted triage on top of human review; ask your platform what is filtered, with what false-negative rate, before you commit headcount to a program at risk of collapse.

3. Re-baseline your patch SLA and your disclosure SLA together. If your internal target for browser engine, kernel and ubiquitous-library CVEs is still “30 days from disclosure”, that number was set when the rate of credible findings was lower. The disclosure side — time from acknowledged report to public CVE — is now constrained by maintainer triage capacity, not researcher pace. Track both numbers, and report them to leadership as a single curve.

4. Fund the libraries you ship. Stenberg’s only explicit ask in the May 26 post is for companies that depend on curl or libcurl in commercial software to fund the team. The same applies across the projects listed above. A support contract or a sponsored maintainer is materially cheaper than the downside of a critical library’s security pipeline going dark. For security and compliance teams, this is a budget line, not a CSR line.

5. Mirror the AI workflow on the defensive side. The pattern that produces the inbound flood — model surfacing candidate bug classes from public source — is reproducible on internal code without Mythos-class access. Triage your own codebase for unpatched analogues of disclosed CVEs in the library version you ship. Generate minimal repros from advisory text before the official PoC lands. The asymmetry favours defenders only if defenders use the same tooling.

6. Track maintainer attrition as a supply-chain risk. A single lead maintainer reducing hours, leaving a project, or burning out is a software-supply-chain event for everyone downstream. Add the question “who maintains this, and at what capacity?” to your due-diligence checklist for any library above a defined criticality threshold. The list of projects above is a reasonable place to start.

7. Engage with the OSSF working group. The Open Source Security Foundation’s Vulnerability Disclosures Working Group is collecting feedback on best-current-practice for AI-assisted submissions. If your organisation files reports, has a bounty program, or consumes upstream advisories at scale, your operational data is useful to that work and the resulting policy templates are usable in your own program.

Status

Item	Reference	Date	Notes
Stenberg, The pressure	daniel.haxx.se	2026-05-26	>1 report/day; 12 confirmed CVEs at mid-cycle
Willison link blog summary	simonwillison.net	2026-05-26	Same-day amplification, security/AI tags
Stenberg, High-Quality Chaos	daniel.haxx.se	2026-04-22	Confirmed-vulnerability rate back to 15-16%
Stenberg, End of the curl bug-bounty	daniel.haxx.se	2026-01-26	Bounty program ended 2026-01-31
Help Net Security, AI is drowning maintainers	helpnetsecurity.com	2026-05-18	Torvalds, GitHub, HackerOne quoted
GitHub Security bounty update	github.blog	2026-05	New submission requirements, PoC mandatory
OSSF Vulnerability Disclosures WG #178	github.com/ossf	2026	Open call for AI-slop best practices

The right framing here is not “AI is producing too many bugs” — it is “the human-reviewed disclosure pipeline that the entire software ecosystem depends on was sized for a world in which finding bugs was slower than fixing them, and that assumption no longer holds for every project.” The maintainers who keep the lights on are signalling it explicitly. The cost of acting on that signal — funding, policy, tooling — is small relative to the cost of acting after a critical library’s security team is no longer there.