How AI Broke Open Source Security: End-of-Life Software Is the Most Exposed

In January 2026, Daniel Stenberg shut down cURL's bug bounty program. If you don't know cURL, you're using it right now. It's running on your phone, in your car, in your TV, in more than 20 billion installations worldwide. And the guy who's maintained it since 1996 told HackerOne to stop sending him reports because he couldn't keep up with the AI slop.

His words at the time: "We need to make moves to ensure our survival and intact mental health."

The cost-benefit had broken. AI-generated reports, plausible-looking and almost never real, were arriving faster than the project could triage them. For an unpaid maintainer, the math had stopped working.

The valid-rate on cURL reports had collapsed from one in six to one in twenty or thirty. One sample week last summer: seven reports in sixteen hours, none real. The first twenty reports of 2026: zero genuine vulnerabilities.

Three months later, the picture changed. cURL went back to HackerOne in March 2026, and by April, Stenberg's data showed the slop problem had effectively resolved itself. What replaced it is harder to dismiss. Report volume is now roughly double what it was in 2025, which was already double the years before that. The quality is back to or above 2024 pre-AI levels, with the confirmed-vulnerability rate again sitting in the 15-16% range and the share of reports identifying real-but-non-security bugs significantly higher too. Almost every report now uses AI in some form. cURL is on track for around 50 published CVEs in 2026, a record by any measure. Stenberg calls this the era of "high-quality chaos."

This is the part of the AI-and-security conversation that doesn't make headlines, and it's the part that matters most for anyone running open source code in production. AI is changing the math in five places: how vulnerabilities get found, how they get patched, how they get exploited, how they get invented in the first place, and how the volume of findings (slop in early 2026, real bugs by spring) overwhelms the people maintaining the code.

‍

AI works for both sides

AI is finding vulnerabilities. Google's "Big Sleep" agent caught its first real-world bug in October 2024, a buffer underflow in SQLite. By July 2025 it had pre-empted an in-the-wild zero-day before threat actors could exploit it. Anthropic's Claude Opus 4.6 found 22 Firefox bugs in two weeks (shipped in Firefox 148); a successor model later reported 271 additional issues to Mozilla, mostly lower-severity hardening findings, fixed in Firefox 150. DARPA wrapped its AI Cyber Challenge in August 2025 with seven competing AI systems finding 18 net-new zero-days in real production OSS, and they open-sourced all the tooling. The OpenSSL bug Google's AI caught in late 2024 had been sitting in the codebase for twenty years. If a heavily-audited, heavily-fuzzed library can hide 20-year-old bugs from human review, what else could be out there?

AI is patching vulnerabilities. GitHub Copilot Autofix went GA in August 2024 and dropped median fix time from 90 minutes to 28. SQL injection: 3.7 hours to 18 minutes. Snyk, Mend, Endor, Semgrep all have AI-fix tooling now. The DARPA finalists shipped 11 working auto-generated patches for real-world zero-days during their competition. It works, if you have a maintainer team to integrate it.

AI is exploiting vulnerabilities. Researchers at the University of Illinois showed in April 2024 that GPT-4 could autonomously exploit 87% of one-day CVEs just from the NIST description. Other LLMs and the open-source tools (Metasploit, ZAP) hit 0%. Mandiant's M-Trends 2026 puts the average time-to-exploit at negative one day for 2024 and an estimated negative seven for 2025, meaning attackers are now exploiting on average before patches are available. WormGPT variants are back, this time running on top of Grok and Mixtral, sold for around $100 a month on BreachForums. KELA tracked a 219% increase in dark-AI tool mentions on cybercrime forums in 2024 alone.

The asymmetry is the thing. Attackers can run all of this autonomously. Defenders, especially the unpaid open-source kind, need humans in the loop. AI may write the finding, but a human still has to triage, reproduce, validate, patch, regression-test, and ship. That math was rough when the reports were slop. At April 2026 volumes, with cURL on track for fifty CVEs in a single year and other projects reporting the same trend, it is worse.

‍

Slopsquatting: the attack that exists because AI exists

Sometimes the AI doesn't need a real vulnerability. It invents one. Slopsquatting works like this: coding assistants hallucinate plausible-looking package names that don't exist, attackers register those names on PyPI or npm, and developers who paste the AI's install command pull whatever the squatter shipped.

Bar Lanyado at Lasso Security demonstrated the mechanic. He took huggingface-cli, a name multiple LLMs kept inventing in install instructions, uploaded an empty package to PyPI, and racked up over 30,000 real downloads in three months. Charlie Eriksen later found react-codeshift, a hallucination that mashes jscodeshift and react-codemod together, spreading through 237 GitHub repositories via AI-generated agent skills. A USENIX Security 2025 study across 16 models found 8.7% of hallucinated Python package names happened to be real JavaScript packages. The attack jumps ecosystems too.

‍

Open source maintainers are still drowning. The cause changed.

Stenberg isn't alone. Seth Larson at the Python Software Foundation raised the same flag about CPython, pip, urllib3, Requests during the slop wave. Django added an AI-disclosure clause to their security policy in May 2025 (with a canary requirement: reports must end with a paragraph on the meaning of life and the submitter's stance on P = NP). Node.js had a contributor submit an AI-generated 19,000-line pull request that took the team days to review.

When Stenberg surveyed peer projects in April 2026 about the high-quality-chaos pattern, the list of confirmations read like the modern enterprise stack: Apache httpd, BIND, Django, Elasticsearch, Firefox, git, glibc, the Linux kernel, OpenLDAP, Python, Ruby, urllib3, Wireshark, wolfSSL, and many others. The OpenSSF opened a working group on AI security reporting. HackerOne acknowledged the problem in their public response to cURL.

These are active projects with paid or volunteered maintainers. They were buckling under slop in early 2026, and they're buckling under volume now. The shape of the load changed; the load did not. EOL projects, with no maintainers at all, were already underwater. AI is now finding real, often serious bugs at unprecedented rates, and somebody needs to ship the patches. For end-of-life software, that somebody no longer exists upstream.

‍

End-of-life open source software is uniquely exposed

Now stack the dynamics together. Big Sleep, Claude, the AIxCC tools, and XBOW (which hit #1 on HackerOne's US leaderboard in June 2025 with 1,060 submitted vulnerabilities) all run against any code that compiles, end-of-life or not. AngularJS is just as scannable as React. Vue 2 is just as scannable as Vue 3. .NET Framework 4 is just as scannable as .NET 9.

For supported software, the loop closes, imperfectly, but it closes. Bug found, bug reported, bug patched. For end-of-life software, the loop has no closing side. The bug surfaces. The exploit follows. And there's no upstream maintainer to ship the fix. A few EOL projects get volunteer forks. Most don't, and the ones that do face the same AI load with smaller teams. That missing side of the loop is our specialty at HeroDevs.

The "we'll just have AI patch our legacy stack" answer doesn't hold either. Veracode's 2025 GenAI study tested 100+ LLMs across 80 coding tasks: 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability. Java was at 72%. Cross-site scripting protection failed 86% of the time. Sonatype tested 37,000 LLM-assisted dependency upgrades: GPT-5 hallucinated nonexistent component versions 28% of the time, and in some cases recommended packages that turned out to be known malware.

AI-only patching, without specialist humans owning the codebase, just trades one risk for another. Humans miss things too. But humans who own a codebase have what AI doesn't: context for what the code is supposed to do, memory of past regressions, and accountability for what ships.

‍

Where this leaves us

The right answer in 2026 isn't to fear AI, and it isn't to pretend the upstream community will catch what AI throws at it. AI helps defenders only when humans supervise it. It helps attackers without supervision. The community is overwhelmed. EOL projects don't even have a community to overwhelm.

The right answer is to make sure every component in your stack, especially the legacy ones you can't migrate off in twelve months, has a human team behind it. Either yours, the upstream maintainers, or a vendor purpose-built to be that team. AI made attacking your legacy stack a commodity. We make defending it a service.

At HeroDevs, that's the service: human teams maintaining ongoing security support for end-of-life open-source software, so your engineers aren't the only ones standing between modern AI attacks and legacy code nobody else is updating. When the AI report lands on a project with no upstream maintainer, someone still has to pick up. That's the question 2026 is asking, and that's the question HeroDevs is answering.