You have probably never maintained a piece of software the world depends on. Somebody has, though — on a Sunday night, working through a security inbox: the unpaid second shift that keeps the plumbing of the internet from leaking.
Picture the inbox. Bot. Bot. Bot. Long, confident, beautifully formatted reports describing vulnerabilities that do not exist. Your instinct is the obvious one: filter them. Write a rule, route the machine-written ones elsewhere, get the Sunday back.
Now ask the question a maintainer would ask instead — and if one of them is real?
It sounds like craftsman's pride. It is not; it is the right question, and the record since then shows why. The machine-written reports did not stay fake. They got good without getting fewer, and nobody had a plan for the version of this where the flood is right.
What is landing in those inboxes
The volume, at least, is not in dispute, and it shows up in four places.
Start with curl (the small open-source tool for moving data between machines). In July 2025 its lead maintainer, Daniel Stenberg, tallied the cost: about 20% of that year's submissions were AI slop, and by early July roughly 5% had turned out to be genuine vulnerabilities. Every report, real or not, pulled in three or four people, perhaps for thirty minutes, sometimes up to an hour or three each.
So in January 2026 he did the decisive thing. The maintainer who finally closed the door announced that curl's bug bounty would stop on January 31, 2026, after 87 confirmed vulnerabilities and over $100,000 paid out; the confirmed rate had fallen from north of 15% to below 5% starting in 2025. The reasoning was economic, not ideological — remove the money, remove the incentive to submit made-up lies — though he allowed a non-zero risk that his guesses were wrong.
It worked. Then something else happened.
By May 26, 2026 the problem had inverted. The slop stopped and the flood did not: reports arriving four to five times faster than in 2024 and double the 2025 rate, more than one a day on average, at higher quality than ever. He calls the result the current high quality chaos. With half a release cycle still to run, curl already had twelve confirmed vulnerabilities queued as twelve pending CVE announcements — a project record. His image was a tsunami with no life boats, plus a line about maybe cutting his work hours to breathe.
He is not an outlier, and his is not the biggest desk this hit. On Sunday, May 17, 2026, the man who runs the kernel called the list unmanageable. Linus Torvalds, in his weekly post to the Linux Kernel Mailing List, called the kernel's private security list "almost entirely unmanageable," blaming duplicate reports from researchers running the same AI tools against the same code. For scale: HAProxy's creator and kernel stable maintainer Willy Tarreau noted in March that a list which took two or three reports a week now takes five to ten a day. And the detail that reframes everything — most are solid finds. The kernel's problem is not junk. It is the same true bug arriving nine times, from nine people who pointed one model at one file.
Torvalds did not ask anybody to stop; he asked them to go further (read the documentation, write a patch). And the kernel's own documentation now says so in writing: if you resorted to AI assistance to identify a bug, you must treat it as public, because an AI-detected bug is not meaningfully a secret. It also wants a working reproducer, and says a report's validity should be seriously questioned without one.
Then the platforms. In May 2026 GitHub's advisory database published a record 1,560 reviewed advisories in a single month — more than five times its typical output, against roughly 270 a month two years earlier — while publication times stretched from about a week to, for many, multiple weeks. On HackerOne, finding got cheap and fixing did not: submissions up roughly 76% with signal rates relatively consistent, monthly resolutions down about 46%, unresolved vulnerabilities up 21 times over.
None of this arrived unannounced. Back in December 2024, Seth Larson — who triages security reports for CPython, pip, urllib3 and Requests — warned that these reports look legitimate at first glance and therefore take time to refute.
So filter them out. What could possibly go wrong?
That is the Sunday-night instinct, scaled up — the strongest objection to everything above. Now look at what the rule would have thrown away.
In 2025, Google's Big Sleep agent found a critical flaw in SQLite, CVE-2025-6965 — a flaw known only to the people planning to use it. Google says only that it believes this was the first time an AI agent directly foiled an exploit in the wild.
In February 2026, Anthropic said its Claude Opus 4.6 model had turned up more than 500 previously unknown high-severity flaws in open-source libraries, including Ghostscript, OpenSC and CGIF. That is a company's claim about its own model, validated by its own team — and nobody has produced a reason to think it false.
And in May 2025 the researcher Sean Heelan pointed OpenAI's o3 at the Linux kernel's SMB implementation and came away with a remote zero-day in code plenty of people had already read, CVE-2025-37899. Read his account before you get excited: across a hundred runs the model found no bug in 66 and produced 28 false positives (a signal-to-noise ratio he puts at roughly 1 to 50), and he writes that o3 is not infallible, far from it. He found the zero-day while wading through the noise.
That is the shape of the thing. The good report and the worthless one arrive in the same envelope, in the same register, at the same length. No filter keeps one and drops the other, because the difference is not in the writing.
Even Stenberg came around. When the researcher Joshua Rogers ran AI tooling across curl, about fifty of the resulting bugfixes were merged — mostly tiny mistakes, though several were quite impressive findings. This shows, he concluded, that AI can be used for good: powerful tools in the hand of a clever human. And after the bounty ended, the intake desks reported both halves at once — Stenberg saying volume and quality rose and the confirmed-vulnerability rate surpassed the pre-AI 2024 level; GitHub's Jarom Brown saying his team is inundated by submissions that show no real security impact. Both true. That is the problem.
One scoping note: curl is not where the monsters live — its vulnerabilities of the last few years were all rated LOW or MEDIUM, Stenberg notes. The spectacular finds are elsewhere: SQLite, ksmbd, libraries nobody had audited that hard.
Brussels answered a different question: who, legally, is even there?
Here the timing stops being coincidence. As RedMonk's Kate Holterhoff put it in May, bug bounty programs are becoming unsustainable at the exact moment that reporting vulnerabilities is becoming legally required — she was writing about the date that has since arrived.
The European Union's Cyber Resilience Act — Regulation (EU) 2024/2847, which puts baseline security duties on anything digital sold into Europe — runs on a staggered calendar. It entered into force on December 10, 2024 and applies in full from December 11, 2027, with Article 14 pulled forward to September 11, 2026. That earlier date has now passed.
Get the dates exactly right, because they are easy to collapse into one: they are not the same date for everybody. Since September 11, manufacturers must report actively exploited vulnerabilities and severe incidents — an early warning within 24 hours of becoming aware, a full notification within 72 hours, a final report within 14 days of a corrective measure — filed once through a single platform that reaches a national response team and, barring exceptional circumstances, ENISA. Open-source stewards are not on that clock: under Article 71(2) their reporting duty does not begin until December 11, 2027. Anyone telling a volunteer they owe Brussels a 24-hour report has it wrong.
So what is a steward? Here European law quietly runs out of road. A manufacturer, in the CRA's definition, can be a natural person or a legal one (you, personally, can be a manufacturer). But a steward has to be a legal person: an entity, other than a manufacturer, systematically supporting the sustained development of open-source software intended for commercial activity. A foundation qualifies. A nonprofit qualifies. A person with a mailing list and a Sunday night does not.
Which brings us back to curl. In that same May post, Stenberg noted something that reads very differently with the definition in front of you: the project is not owned by a company and not part of any umbrella organization. Maximum freedom, maximum flexibility — and quite possibly no legal person for the law to name as its steward.
To be fair to Brussels, the category exists because the open-source world fought for it. When the CRA was still a proposal, nearly every open-source institution in Europe objected at once — the Open Source Initiative, the OpenSSF, GitHub and Microsoft among them. The Python Software Foundation feared becoming legally responsible for security problems in products built from code it gives away free, and says the category was written into the final text to answer exactly that — while flagging that an "open source steward" is a brand new idea in European law.
The duties that landed are genuinely lighter. What Brussels asks of a steward is a documented cybersecurity policy, kept in a verifiable manner, plus cooperation with market surveillance authorities on request — with the heavier Article 14 duties applying only to the extent the steward is actually involved in developing the thing. Better still, no fines attach to a steward at all; the penalties everyone quotes, up to €15 million or 2.5% of global annual revenue, are aimed at manufacturers. The Commission even issued guidance on open source six weeks early, on July 27, 2026.
So: a duty without a penalty, on a category invented to protect volunteers, with fifteen extra months to prepare. What could go wrong?
Two years into the run-up, most of the people this governs still do not know it exists: unfamiliarity went up in the Linux Foundation's readiness survey, to 66% from 62%, with 61% of non-commercial contributors still unsure whether the law touched them. So on June 30, 2026 the Eclipse Foundation and the Open Regulatory Compliance Working Group launched a free training hub (which is, said out loud, volunteers building a compliance course for volunteers).
When the steward clock starts
Just imagine December 2027 — not a speculative distance. Fifteen months.
The steward clock starts, and volume has not fallen — nothing in the economics points that way. The reports are not slop. They are correct, detailed, and increasingly they arrive with a working patch, because filing a raw finding stopped being socially acceptable somewhere around the Torvalds post.
So maintainers do the only thing left: they point machines at the machines. Triage agents that fold nine reports of one bug into a single ticket, rank by exploitability, draft the CVE text. A reputation market forms — for the tools, not the researchers.
And somewhere in there, a widely used project looks at the paperwork, looks at the words "legal person," and decides the safest move is to incorporate — or to stop. Not because of a fine, since stewards face none, but because the cheapest way to become legible to a regulator is to become an entity, and the cheapest way to avoid that is to archive the repository. The failure mode to watch is not enforcement. It is withdrawal.
What the people who study this for a living are saying
This is not a fringe concern, and it does not break along the usual lines. The Atlantic Council put it bluntly in June 2026: the cost of finding and exploiting a software vulnerability has collapsed, and frontier labs are surfacing flaws faster than anyone can triage them. Its prescription is restraint — stop treating open-source ecosystems as de facto testbeds.
On the CRA, the criticism spans the spectrum. From the free-market side, the R Street Institute warns the law may disproportionately burden individuals and nonprofits, and that a 24-hour rule could hand attackers a map of freshly reported, unpatched flaws. From the digital-rights side, the Electronic Frontier Foundation argued in 2023 against the proposed text that it would penalize open-source developers who receive any monetary compensation, and that the same clock would greatly expand the risk of exposing vulnerabilities to people who mean harm. The steward category answered part of the first objection. No one has answered the second.
The academic work is early but pointed. A 2026 preprint — not peer-reviewed — gives the effect a name and a measurement: a denial-of-service effect in which plausible but low-quality AI-generated contributions overwhelm community capacity, measured across 294 repositories and more than two million pull requests and issues. Its diagnosis is the best line on any of this — these tools dramatically lowered the cost of producing code while raising the cost of evaluating it. A companion preprint lands on the older, sadder framing: productivity gains externalizing costs onto whoever reads the output next. A tragedy of the commons, with commit access.
Then the money. On March 17, 2026, the companies building the models wrote a check — $12.5 million in grants to the Linux Foundation from Anthropic, AWS, GitHub, Google, Google DeepMind, Microsoft and OpenAI, the press release naming the cause plainly: AI is dramatically increasing the speed and scale of vulnerability discovery, and maintainers face an unprecedented influx of findings they lack the resources to triage. One funder says the quiet part out loud: AWS, contributing $2.5 million, writes that foundation models are beginning to outpace security researchers at finding bugs in critical code. The coalitions cleaning this up are funded by the same firms whose products generate the volume.
I do not think that is hypocrisy. I think it is the first honest pricing of an externality this industry has managed in years, and nowhere near enough. Nor is it only volunteers: on August 4, 2026, even Apple started rationing its own inbox, capping how many reports a researcher may have open at once, citing an uptick in hallucinated bugs. When the deepest pockets on earth start metering submissions, "hire more triagers" stops being a serious answer.
What does this mean for you?
You are not a kernel maintainer. You still depend on all of this, daily, through software you never chose. So:
If you file security reports, change what you send. A finding is no longer scarce; a verified one, with a working reproducer and a tested patch, is. Forwarding raw model output to a volunteer is not research — it is outsourcing your reading to someone who never agreed to it.
If your business ships software into the EU, find out which noun you are. Manufacturer duties went live on September 11; steward duties, reporting included, not until December 11, 2027. Most people in your position genuinely do not know which they are.
If your company depends on open-source code, put a number next to it. Not a sponsorship gesture — a line item, with a name on it, aimed at the projects in your build. It is a bet either way; price it.
If you maintain something and you are underwater, say so publicly. Security reports feel private, so nobody compares notes — and the silence is what let this scale unseen.
If you are simply watching this go by, look at the shape. Rules that assume a company on the other end — a legal person with a compliance budget — hand the work to whoever is left when there isn't one. You will meet that pattern again, far from software.
The lesson, as I see it
The instinct to filter is wrong, but not in the way you might expect. The question was never how to keep the garbage out. The real question — the maintainer's — is what you owe a stranger who hands you something true.
Because that is what changed. The implicit deal in open source was that finding a bug was hard, so a report was a gift. AI collapsed the cost of finding and left the cost of fixing exactly where it was, and no gift economy survives that asymmetry without someone rewriting the terms. The fixing is still done by hand, by people, at night, for free.
My vote? Stop treating this as a spam problem — the spam ended when curl took the money away, and the flood got worse. Treat it as what it is: a discovery capacity we built collectively and a repair capacity we never funded. Europe's clock, awkward as it is, at least forces somebody to name who is responsible. For a great deal of the code you are reading this on, the answer is nobody in particular — and the people doing the work are tired.
You depend on code written by people you will never pay. Send this to whoever decides what that is worth — and the HAIA Foundation will keep publishing these until the line item exists.