October 20, 2026
VLC Just Fixed 130+ Security Bugs. The Real Story Is What AI Is Doing to Open Source
Finding bugs got cheap. Fixing them didn’t. Here’s what VLC, curl, and FFmpeg reveal about the new pressure on the software you use every…

By Naro
9 min read
Finding bugs got cheap. Fixing them didn't. Here's what VLC, curl, and FFmpeg reveal about the new pressure on the software you use every day.
If you have ever watched a video file on a computer, you have probably used VLC. In late August, VLC's president, Jean-Baptiste Kempf, told TechCrunch the player had passed 7 billion downloads. A few weeks later, on September 22, the project shipped VLC 3.0.24.
On the surface, it looks like a normal update. It isn't. VideoLAN says it contains more than 130 security fixes, and Kempf calls it the project's biggest security release ever.
The more interesting question is why it happened now. Kempf gives two reasons: funded time for security work, and the fact that AI tools have changed the economics of finding bugs. Other major open source projects (curl, FFmpeg, Node.js and the Linux kernel) have been saying something similar all year.
In this article I walk through what VLC shipped, what Kempf says is behind it, and what other maintainers report. I attribute each claim to its source, and I link the primary sources at the end so you can check them yourself.
Who actually builds VLC?
VLC is made by VideoLAN, a nonprofit organization under French law. According to its own website, the project is led by and made up of volunteers.
French media coverage adds more detail. VideoLAN has no salaried staff and depends on donations and on services from VideoLabs. In a February interview with BFM Business, Kempf said VLC doesn't have enough money to employ even one full-time engineer.
It could have had money. Kempf said Google once offered a deal in which every VLC install would also install Chrome, in exchange for a payment per install. The French outlet reported the figure as $1, while BFM's account said €1. In both versions, Kempf refused. In an older interview, he said the project hates bundling and will always reject such offers. Wikipedia adds that the way Kempf structured the business side let him turn down acquisition offers, some reportedly worth several million.
This matters for the rest of the story. VLC is one of the most widely used programs in the world, and it is maintained by a small volunteer team with limited funding. That is exactly the kind of project that suffers when a flood of bug reports arrives.
What's inside VLC 3.0.24?
VideoLAN's security bulletin splits the "130+" number into two parts:
- More than 50 security issues fixed in VLC itself.
- Updated third-party libraries that bring fixes for at least 74 publicly documented vulnerabilities.
Kempf lists the kinds of bugs involved: out-of-bounds reads and writes, integer overflows, double frees, use-after-free errors, and infinite loops triggered by malformed files. If those terms are new to you, the short version is this. They are memory-handling mistakes common in older C code, and a specially crafted media file can trigger them.
Kempf says most of these bugs are hard to exploit in practice, but not all are harmless. The bulletin adds that code execution was demonstrated on macOS under specific conditions.
Other notable changes in the release:
- FFmpeg jumped from version 4.4 to 8.1.2. Kempf describes this as four major versions at once. In total, 49 third-party libraries were updated.
- The update-signing key was replaced. The old key dated from 2013 and was a DSA 1024 key. VideoLAN's X account says VLC downloads the new key signed with the old one, so this step is expected behavior, not a red flag.
- The old NPAPI browser plugin was removed.
- Outside researchers and the OSS-Fuzz project were credited for finding and reporting bugs.
One more detail is easy to miss. All of this ships on the 3.0 branch. Kempf says VLC 3.0 came out in February 2018, and eight and a half years later it is still the version almost everyone runs. That makes this a fix for an old codebase, not a shiny new one.
The old record, and why it stood for seven years
Before this release, the record belonged to VLC 3.0.7 from 2019. That release came out of the EU-FOSSA bug bounty, and Kempf's post from the time counted 33 valid security issues fixed through it. That record stood for seven years.
Going from 33 to 130 in one release is a big jump, and Kempf offers two explanations.
Reason one: money
Kempf says the Sovereign Tech Fund paid for a large part of this release, especially the security work. VideoLAN's X account says the release was clearly sponsored by the fund. This is the less dramatic reason, but it is a real one: paid, focused time lets a volunteer project do work it otherwise couldn't.
Reason two: AI changed bug hunting
Kempf's second reason is the one that connects VLC to the wider open source world. He writes that pointing AI tools at millions of lines of C code, full of 20-year-old patterns, has become cheap. VideoLAN now receives far more AI-assisted security reports than before.
He is honest about the quality. The output is noisy, with duplicates, crashes nobody can exploit, and reports that need hours of triage. But some of the bugs are real.
Then he makes the point I find most valuable in this whole story. Finding suspicious code got cheaper. But the steps that come after did not:
- reproducing the issue
- deciding whether it is exploitable
- writing the fix
- reviewing the fix
- backporting it to an eight-year-old branch
- making sure you don't ship a regression
Kempf says none of those got cheaper. He suspects this is the new normal for every large open source project.
He has said something like this before. In 2019 he criticized bug bounties because they pay people to find issues, not to fix them.
The same pattern at curl
Curl, the widely used data-transfer tool, has been dealing with this longer than most. Its lead developer, Daniel Stenberg, wrote about fake AI reports in January 2024. His point was that the more convincing a bad report looks, the more time and energy it takes to disprove it.
The numbers he shared over the next two years tell a story with a twist:
- July 2025: about 20% of curl's security reports were AI "slop," and only about 5% were real. Each report tied up three to four people from the seven-person security team for anywhere from 30 minutes to 3 hours.
- January 2026: Stenberg ended curl's bug bounty. It had run since April 2019, found 87 confirmed vulnerabilities and paid out over $100,000. The share of real reports had fallen from over 15% to below 5% during 2025.
- April 2026: he wrote that the slop problem was "not a problem anymore." Almost every report now uses AI, and the confirmed rate was back to 15–16%. The catch: there were far more reports.
- May 2026: reports were arriving four to five times faster than in 2024, more than one per day.
- July 1 to August 3: curl stopped accepting vulnerability reports entirely. Stenberg called it the "summer of bliss" and said the team had been under huge pressure for about four months. Afterward, he called the pause possibly the project's best decision in a long while.
- October 14: curl 8.23 shipped, fixing 24 vulnerabilities.
Notice what changed. First the problem was bad reports. Then it became good reports in huge volume. Both versions overload a small team.
FFmpeg's public argument with Google
FFmpeg is the library VLC just upgraded, and it has been vocal about this issue. In August 2025, Google told TechCrunch that its AI bug hunter, Big Sleep, had found 20 flaws in open source software. A Google spokesperson said a human expert reviews each report before it goes out, but that every bug was found and reproduced by the AI agent without human intervention.
In October 2025, FFmpeg's X account posted a patch for a codec used in the first 10 to 20 frames of Rebel Assault 2, a 1995 game. The next day, it linked a Big Sleep report about that same codec, which Google's tracker rated medium impact.
FFmpeg's complaint was about fairness. Is it reasonable for trillion-dollar companies to run AI over hobbyist code and then expect volunteers to fix everything? The account called it "CVE slop," and later said that if Google wanted to help, it should send or fund patches.
Not everyone on the team agreed. Michael Niedermayer, who describes himself as the main developer fixing security issues in FFmpeg, posted that he disagreed with the account's comments. He said Google has been the most helpful and nice of all the companies.
That disagreement is worth keeping in mind. Even inside one project, people see this situation differently.
In June 2026, The Hacker News reported that an AI agent from the security company depthfirst found 21 zero-days in FFmpeg for about $1,000. Depthfirst's writeup says nine received CVEs, and FFmpeg's git history credits depthfirst on several fixes. FFmpeg's security page now warns about a spike in AI-generated false positives, says automated submissions are not accepted, and since September says LLM-generated patches are not accepted either.
What the bounty platforms report
The platforms that connect researchers and projects are feeling it as well:
- HackerOne said in April that submissions grew 76% year over year, with a record in March 2026, while fixing improved only 19%. In October, it said the backlog of confirmed but unfixed bugs had grown 131% in two years. Its CEO, Kara Sprague, summed it up this way: fixing got faster, but it still lost ground.
- Bugcrowd says its triage queue grew 334% in three weeks of March, almost all from low-quality submissions.
The Linux kernel and others
In May, Linus Torvalds wrote that the continued flood of AI reports had made the kernel's security list almost entirely unmanageable, with many duplicates from people using the same tools. The kernel documentation now says that if AI helped you find a bug, you should treat it as public. A chart posted by Greg Kroah-Hartman in August shows kernel CVEs rising from about 500 per release to close to 2,000 for version 7.2.
Other projects report similar pressure:
- Node.js: per the OpenJS Foundation, it normally gets six to seven vulnerability reports a month. Between mid-December and mid-January, it got over 30.
- Python: the Python Software Foundation says maintainers told it security work went from about 20% of their time to almost all of it.
The money is shifting, too
Several bounty programs have been paused or ended:
- This spring, HackerOne paused its Internet Bug Bounty. Node.js says that ended its own bounties, and Stenberg says the same program had paid curl's bounties for years.
- On October 1, Google stopped taking product bug reports in its open source bounty, citing a significant rise in automated submissions, the vast majority of them invalid.
- The same day, GitHub added daily limits on how many private vulnerability reports one person can file.
There is new funding as well. In March, the Linux Foundation announced $12.5 million from Anthropic, AWS, Google, Google DeepMind, GitHub, Microsoft and OpenAI, partly to help maintainers triage AI-generated reports. Even so, Kroah-Hartman, quoted by Help Net Security, said grant funding alone won't solve the problem AI tools are causing for open source security teams today.
But the reports are getting better, too
It would be unfair to tell only the negative side. Some maintainers say report quality has improved. Kroah-Hartman told The Register in March that "now we have real reports." Stenberg says curl's confirmed rate is back above its pre-AI level. And in May, Anthropic said it and about 50 partners had found more than 10,000 high- or critical-severity bugs using its Mythos model, and that some maintainers had asked it to slow down its disclosures.
So the honest summary is not "AI is ruining security" or "AI is saving security." It is both, at once, and the bottleneck has moved.
My takeaways
I'll step back from the individual stories, because the pattern across them is the real lesson.
1. The bottleneck moved from discovery to repair. For years, the hard part of security was finding the bug. Now discovery is cheap, and the expensive parts are verification, fixing, reviewing and releasing. Every project in this article is struggling with the same imbalance.
2. Cheap discovery without funded repair is unfair to maintainers. This is the heart of FFmpeg's complaint and Kempf's 2019 bounty criticism. A report costs the sender almost nothing. It can cost a volunteer hours. Whoever benefits from the bug being found should help pay for it to be fixed.
3. Old code is where the pile is. VLC 3.0.24 is a cleanup of an eight-year-old branch with 20-year-old patterns underneath. AI tools make it cheap to dig through that history, so expect more of these big cleanup releases from other long-lived projects.
4. Big numbers deserve careful reading. "130 fixes" includes 74 vulnerabilities in updated libraries. That doesn't make the number meaningless, but it does show why reading the actual bulletin beats reading the headline.
5. Small teams are the fragile point. The software that much of the world depends on is often maintained by a handful of people. Pausing report intake, as curl did, shows how seriously stretched they are.
What should you do?
Kempf's advice is short, and I agree with it: update. VLC 3.0.24 is rolling out to what he calls hundreds of millions of machines. If you use VLC, check your version, install the update, and avoid opening media files from sources you don't trust on older versions.
If you want to support the ecosystem beyond your own machine, donating to the projects you rely on, or encouraging your employer to fund them, may do more than anything else on this list.
Conclusion
VLC 3.0.24 is more than a long list of security fixes. It is a visible sign of a change happening across open source: AI has made finding flaws fast and cheap, while the human work of confirming, fixing and safely shipping those fixes remains slow and expensive.
The projects that cope will be the ones that get funding, better triage tools and fairer relationships with the companies running the scanners. Until then, the best thing ordinary users can do is simple. Keep your software updated, and remember that behind every "free" tool is a small team doing hard work.