I feel like it's also been overrun by a lot of spam. As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam.
Occasionally I see real security researchers on HN complaining that no one takes the disclosure seriously, or that people reply immediately with a cease and desist. But from the receiving end it's just because the spam is unmanageable.
I'm getting CVE fatigue with all of these super ultra critical 10/10 vulnerabilities that are some node package that compiles my frontend can get stuck if I give it a malicious regex.
It's hard to spot the stuff that actually matters.
Same experience here. I've run a successful vulnerability disclosure program for over a decade and paid out thousands of dollars in bounties for scanii.com (a malware identification API service), but recently (since the beginning of the year), we went from receiving maybe 5 per month to receiving 5 per day. These are clearly AI-generated and extremely low quality (albeit well-written). The rules of the program aren't read, and it's clearly a “point-and-click to a website" and file a report.
I'm now considering just shutting down the program since, as the OP pointed out, if you found this vulnerability using an AI tool, they are inherently public.
I haven't gone that far yet but have instituted some new rules aiming at filtering out most of the reports: 1- No AI-generated report and 2 - Reports must include a video of the exploit.
You can see our program rules here: https://docs.scanii.com/article/131-does-scanii-have-a-secur...
Security through obscurity was never a great strategy.. and now it’s not a strategy at all..
Hopefully at the end of this decade, a ton of software practices have been overhauled to eliminate classes of problems. Memory-safe language use is a great start - but it’d be great to see innovation in checking for TOCTOU problems, improper/missing authn & authz, and many others.
This is an engineering problem. It won’t be solved by models that “only do dumb shit 1/10th as often, only 0.01% of the time now not 0.1%!” It won’t be solved by adding more models to do even more double-checking before and after the work. It won’t be solved by hoping humans catch it in review. It isn’t solvable by adding outer loops of any sort - though we may get close. To truly solve this will take serious CS research.
Almost never do software companies even attempt to design secure systems. I'm not sure this requires new fundamental research so much as slightly giving a shit.
Most verification is undecidable, lots of it is pspace complete. That doesn’t mean very much in practice since those are worst case bounds. People regularly solve problems that are undecidable for all practical instances that they care about.
Verifying behaviour of an arbitrary program is uncomputable. However that doesnt mean you can't have proofs of behaviour of specific programs you create.
Personally i have some doubts, a lot of research has gone into the idea without much to show for it, but its a very reasonable research area.
At risk of quoting too much of the article, it opens with this:
> A requirement for staying sane while working in public as an open source maintainer is realizing that every issue, PR, and piece of feedback is a present, not an obligation. You can accept it, ignore it, and use it partially or not at all.
> Except…
> For years, as lead of the Go Security team at the time, I’ve told new team members that it doesn’t apply to vulnerability reports. No, vulnerability reports are special. Security researchers are doing us a favor by reporting things confidentially instead of doing full disclosure, so we owe them something, which is not true of regular issues opened on the issue tracker.
[...]
> It’s 2026 and none of the premises are true anymore.
I respectfully disagree.
The premise is absolutely still true: if someone discovers a critical, exploitable vulnerability in your software, the impact and tradeoffs are exactly the same as they were before LLMs started finding bugs. There are just more of them now, so they're easier to come by.
But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report. This is just chugging through the backlog.
All of that said, I don't think finding vulnerabilities has really been the difficult security problem for most companies (or open source projects). The difficult problem is dedicating resources to fixing those vulnerabilities instead of building software, products, and/or infrastructure that people want. That problem is absolutely still here today, but I'm optimistic that agentic security developers will be able to take the burden off of development teams in the near future.
The problem is there used to be a fairly high correlation between ‘security report’ and ‘real vulnerability’. Not perfect but good enough. Now the two are almost entirely disconnected.
There are some problems with incentives in the vuln report space. People report trivial vulns and expect the same treatment as people reporting critical vulns. But this isn't new with AI. Look at all the ReDos vulns in npm ecosystem. Its questionable if its a vuln in general but half of them aren't even triggerable.
The _demonstration_ of security impact through vulnerability reports was special. The automation of “demonstration of impact” with AI isn’t that at all. The last mile is human and always was. This isn’t to say it won’t change in the future, but that’s a fact of where we are now.
Vulnerability reports aren’t special anymore. They never were. It was the impact, the demonstration, the communication that was special.
When you realize that this is being written from the perspective of someone who does vulnerability reporting in a professional capacity, you’ll connect the dots. We took care to be kind and succinct because for many of us, we learned our skills from being on the development side of things first.
Vulnerability reports aren’t special anymore. The only ones that felt special were the ones with human touch, the ones doing their job as an adversarial thinker, and taking the care to understand that net positive outcomes require coordination even if both parties don’t see eye to eye.
Nothing has changed. It never was. You’re just inundated with AI slop; which as a practitioner who uses AI regularly I can say with absolute confidence. The end result is the same, the volume is increased, but the special thing was never the report itself.
Finding a vulnerability was always the easy but high toil part. It was the care to communicate succinctly and be invested in the outcome that was special.
I'm wondering whether this is a permanent change. After all the easy-to-find bugs have fixed and you can't find them just by asking an AI, perhaps security issues will deserve special treatment again.
I agree with this. One of the consequences of the "vulnpocalpyse" is that it's become even harder to sift through the noise: I triage well over a dozen reports a week, many of which are "real" in the sense that they reflect a genuine defect but otherwise have an unclear impact on a typical user. This has always been true of the median vulnerability report, but the volume means that I now lean much more heavily away from coordinated disclosure.
One flipside to this is that, because many of these bugs are "shallow" to LLMs, it's actually easier than ever to moderate the worst participants in your vulnerability program -- if someone sends you slop, you can just ban them and wait for the next, better orchestrated LLM to send you a better report for the same vulnerability.
> If a security vulnerability is reported by someone who is also violating the CoC, what do you do? Do you ignore it? Fix it silently?
Is this even a question? You triage and fix the vulnerability just like any other one. Are truths spoken by folks one dislikes — even for perfectly valid reasons — any less true?
The only way I can imagine this somehow applying is if someone has a habit of reporting vulnerabilities which do not exist, or of exaggerating their severity. Is crying wolf a CoC violation? If so, then I can imagine that particular sort of bad behaviour justifying some consideration before acting on a report.
How badly are they violating the code of conduct? It wouldn't be the first time a security researcher got thrown into prison or jail, in this line of work.
I feel like it's also been overrun by a lot of spam. As someone running a company, I get 2-5 unsolicited "vulnerability reports" per week. Half of them are an LLM finding some bad CSS on our framer splash page. The other half I assume are an extortion attempt so we just mark as spam.
Occasionally I see real security researchers on HN complaining that no one takes the disclosure seriously, or that people reply immediately with a cease and desist. But from the receiving end it's just because the spam is unmanageable.
I'm getting CVE fatigue with all of these super ultra critical 10/10 vulnerabilities that are some node package that compiles my frontend can get stuck if I give it a malicious regex.
It's hard to spot the stuff that actually matters.
Not sure what dumbass out there is marking those as 10/10. A 10 should be an auth bypass or RCE. Not a crashed build in my CI.
Same experience here. I've run a successful vulnerability disclosure program for over a decade and paid out thousands of dollars in bounties for scanii.com (a malware identification API service), but recently (since the beginning of the year), we went from receiving maybe 5 per month to receiving 5 per day. These are clearly AI-generated and extremely low quality (albeit well-written). The rules of the program aren't read, and it's clearly a “point-and-click to a website" and file a report. I'm now considering just shutting down the program since, as the OP pointed out, if you found this vulnerability using an AI tool, they are inherently public. I haven't gone that far yet but have instituted some new rules aiming at filtering out most of the reports: 1- No AI-generated report and 2 - Reports must include a video of the exploit. You can see our program rules here: https://docs.scanii.com/article/131-does-scanii-have-a-secur...
Security through obscurity was never a great strategy.. and now it’s not a strategy at all..
Hopefully at the end of this decade, a ton of software practices have been overhauled to eliminate classes of problems. Memory-safe language use is a great start - but it’d be great to see innovation in checking for TOCTOU problems, improper/missing authn & authz, and many others.
This is an engineering problem. It won’t be solved by models that “only do dumb shit 1/10th as often, only 0.01% of the time now not 0.1%!” It won’t be solved by adding more models to do even more double-checking before and after the work. It won’t be solved by hoping humans catch it in review. It isn’t solvable by adding outer loops of any sort - though we may get close. To truly solve this will take serious CS research.
Almost never do software companies even attempt to design secure systems. I'm not sure this requires new fundamental research so much as slightly giving a shit.
Verifying correctness of an implementation is P NP, not serious CS research.
Most verification is undecidable, lots of it is pspace complete. That doesn’t mean very much in practice since those are worst case bounds. People regularly solve problems that are undecidable for all practical instances that they care about.
Verifying behaviour of an arbitrary program is uncomputable. However that doesnt mean you can't have proofs of behaviour of specific programs you create.
Personally i have some doubts, a lot of research has gone into the idea without much to show for it, but its a very reasonable research area.
At risk of quoting too much of the article, it opens with this:
> A requirement for staying sane while working in public as an open source maintainer is realizing that every issue, PR, and piece of feedback is a present, not an obligation. You can accept it, ignore it, and use it partially or not at all.
> Except…
> For years, as lead of the Go Security team at the time, I’ve told new team members that it doesn’t apply to vulnerability reports. No, vulnerability reports are special. Security researchers are doing us a favor by reporting things confidentially instead of doing full disclosure, so we owe them something, which is not true of regular issues opened on the issue tracker.
[...]
> It’s 2026 and none of the premises are true anymore.
I respectfully disagree.
The premise is absolutely still true: if someone discovers a critical, exploitable vulnerability in your software, the impact and tradeoffs are exactly the same as they were before LLMs started finding bugs. There are just more of them now, so they're easier to come by.
But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report. This is just chugging through the backlog.
All of that said, I don't think finding vulnerabilities has really been the difficult security problem for most companies (or open source projects). The difficult problem is dedicating resources to fixing those vulnerabilities instead of building software, products, and/or infrastructure that people want. That problem is absolutely still here today, but I'm optimistic that agentic security developers will be able to take the burden off of development teams in the near future.
For tokens, of course.
The problem is there used to be a fairly high correlation between ‘security report’ and ‘real vulnerability’. Not perfect but good enough. Now the two are almost entirely disconnected.
There are some problems with incentives in the vuln report space. People report trivial vulns and expect the same treatment as people reporting critical vulns. But this isn't new with AI. Look at all the ReDos vulns in npm ecosystem. Its questionable if its a vuln in general but half of them aren't even triggerable.
Tangent point, I think more broadly this is a big piece of AI-cynicism in general- “x isn’t special anymore”.
It’s tough staying motivated on a craft when an AI is nearly as good as you. Chess players manage to do it at least.
> Chess players manage to do it at least.
The 5 on earth still getting paid to play chess?
Vulnerability reports were never special.
The _demonstration_ of security impact through vulnerability reports was special. The automation of “demonstration of impact” with AI isn’t that at all. The last mile is human and always was. This isn’t to say it won’t change in the future, but that’s a fact of where we are now.
Vulnerability reports aren’t special anymore. They never were. It was the impact, the demonstration, the communication that was special.
When you realize that this is being written from the perspective of someone who does vulnerability reporting in a professional capacity, you’ll connect the dots. We took care to be kind and succinct because for many of us, we learned our skills from being on the development side of things first.
Vulnerability reports aren’t special anymore. The only ones that felt special were the ones with human touch, the ones doing their job as an adversarial thinker, and taking the care to understand that net positive outcomes require coordination even if both parties don’t see eye to eye.
Nothing has changed. It never was. You’re just inundated with AI slop; which as a practitioner who uses AI regularly I can say with absolute confidence. The end result is the same, the volume is increased, but the special thing was never the report itself.
Finding a vulnerability was always the easy but high toil part. It was the care to communicate succinctly and be invested in the outcome that was special.
Godspeed.
I'm wondering whether this is a permanent change. After all the easy-to-find bugs have fixed and you can't find them just by asking an AI, perhaps security issues will deserve special treatment again.
I agree with this. One of the consequences of the "vulnpocalpyse" is that it's become even harder to sift through the noise: I triage well over a dozen reports a week, many of which are "real" in the sense that they reflect a genuine defect but otherwise have an unclear impact on a typical user. This has always been true of the median vulnerability report, but the volume means that I now lean much more heavily away from coordinated disclosure.
One flipside to this is that, because many of these bugs are "shallow" to LLMs, it's actually easier than ever to moderate the worst participants in your vulnerability program -- if someone sends you slop, you can just ban them and wait for the next, better orchestrated LLM to send you a better report for the same vulnerability.
this is hilarious and i might try it.
> If a security vulnerability is reported by someone who is also violating the CoC, what do you do? Do you ignore it? Fix it silently?
Is this even a question? You triage and fix the vulnerability just like any other one. Are truths spoken by folks one dislikes — even for perfectly valid reasons — any less true?
The only way I can imagine this somehow applying is if someone has a habit of reporting vulnerabilities which do not exist, or of exaggerating their severity. Is crying wolf a CoC violation? If so, then I can imagine that particular sort of bad behaviour justifying some consideration before acting on a report.
How badly are they violating the code of conduct? It wouldn't be the first time a security researcher got thrown into prison or jail, in this line of work.
Will xorg backport patches from Xlibre?