AI is straining vulnerability disclosure for maintainers.

As software gets more complicated and used more broadly you inevitably end up with bugs that can cause potential security vulnerabilities. No matter if the problem is small or large, impacts hardly anybody or everybody, it’s important that you responsibly disclose the problem so consumers of the software can patch the software and take any other necessary steps to resolve any potential issue.

We’ve historically been very public when it comes to security vulnerabilities. When a user / security researcher finds a security problem within Directus, they can responsibly open a private disclosure over on our GitHub repo. Our team then manually reviews, confirms, and responds to the vulnerability. When we’ve confirmed it’s a real issue that affects the product, we resolve it as soon as we can and publish a patch to the issue. Once the patch is live, we request a CVE and publish the security vulnerability to our public vulnerabilities tracker.

Over the last couple of years, we’ve averaged around 30-40 reports of which about 2 in 5 get resolved and published as a real issue. The others are mostly false positives or configuration/hosting related issues.

Given the title of this blog post, I’m sure you have a hunch what’s coming next.

In the first half of 2026, we have received 230 security reports. That’s nearly 6 times as many in half the time it would usually take. More reports are not automatically bad news. We have accepted substantially more external findings in 2026 than in earlier years, and those findings make Directus safer for everybody. The signal-to-noise ratio however has changed dramatically. Of the 230 reports, we published 11 (or about 5%).

A security report is a claim, not (always) a vulnerability

AI has made it much cheaper to produce a security report that looks convincing. A model can inspect the codebase, recognize a familiar pattern, describe the potential impact, assign it a high severity, and produce a polished report in minutes. Sometimes it is right (great!), but oftentimes it is based on an incorrect assumption about the code, configuration, or threat model. Even worse, sometimes it’s a duplicate of an already resolved published report! Between Jan 2022 and February 2026, we haven’t closed any report as a duplicate. Since then, about 40% of new reports we’ve received have been closed as a duplicate.

The cost of generating another possible finding has fallen sharply, after all you can just have an agent do all the work on your behalf, and even post it automatically. However, the work of validation the security vulnerabilities hasn’t changed all that much. Given the sensitive nature of security problems, we can’t just ignore them. Someone still needs to understand the claim, test it against a current version, check whether it is reachable and exploitable, look for existing fixes and duplicate reports, decide whether it’s actually a security issue, write and review a fix, and coordinate the disclosure. It’s particularly costly when many “researchers” use similar tools against the same public code. One (false positive) issue can generate many detailed reports, each written differently and each requiring enough attention to establish that it’s a duplicate. As of today that’s still mostly human work.

This is not an argument against AI-assisted security research

Now don’t get me wrong, this isn’t a piece saying that we should stop using AI for security research. Quite the opposite: AI-assisted security vulnerability research is producing genuine results in projects across the industry.

Mozilla’s collaboration with Anthropic resulted in fixes for 22 security-sensitive Firefox bugs in Firefox 148. A later evaluation with Claude Mythos Preview led to 271 fixes in Firefox 150. Mozilla’s own engineers validated the findings and shipped the fixes, which makes this one of the clearest public examples of AI improving a well-resourced security program. Mozilla’s initial write-up and follow-up are both worth reading.

Google Project Zero’s Big Sleep found an exploitable vulnerability in SQLite that existing testing had missed. The issue was fixed before it reached an official release. Project Zero published a detailed account of the process.

Similarly, we’ve also seen various fixes in lower-level libraries like the verified and patched findings in wolfSSL. CVE-2026-5500 is one public example.

Reporting responsibility

What we do need to ask ourselves though is if our existing industry processes for reporting and resolving security issues is still relevant and helpful during this AI-transition. What we’re seeing now is that a lot of the work in preparing a report is being moved from the researcher to the maintainer. A useful report — be it AI generated or manually written — validates the finding, tests and provides a minimal reproduction, checks for existing reports and recent fixes, understands the project’s threat model, and has an author that stays available to answer follow-up questions. A bad report is a plausible sounding issue that outsources all of the unfinished work to the project being reported to.

This is not a situation unique to Directus either. Almost exactly a year ago Daniel Stenberg of curl fame blogged about this shift starting on the curl project as well. They too have been dealing with a rising volume of low-quality AI-generated reports, and they estimated that only around 5% of submissions were genuine vulnerabilities and described the effect as “death by a thousand slops”. (Uncanny how that 5% number is the same on our end today)

A shared responsibility

Security reporting has always depended on a relationship between researchers and maintainers. Researchers bring findings; maintainers bring the context needed to asses, fix, and release them. That relationship is under a lot of strain now that reports arrive faster than they can be triaged and properly understood.

The ability to find security issues is becoming more wildly available, which is great! The capacity to verify, remediate, and publish those issues remains limited however. If AI-assisted research is going to improve software security, the surrounding process has to make maintainers faster too. That means reports should arrive with evidence, it means platforms like GitHub need better ways to prevent repeated submissions, it means projects need the time and support to investigate the findings that matter.

We’re all striving for the same outcome: fewer vulnerabilities reaching users, and faster fixes for the ones that do. AI can help us get there, but we can’t forget: the value comes from the quality of work it enables, not the size of the queue it creates.