Vulnerability reports are not special anymore
words.filippo.io174 points by goranmoomin 6 hours ago
174 points by goranmoomin 6 hours ago
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.
Yep. I remember years ago seeing the website for some guy who proudly listed all the CVEs he'd discovered. Clearly he'd written some scanning tool to look at regexes in open source projects and was creating CVEs for anything that might result in exponential time execution or whatever.
It sounds like an interesting case study. Do these things get reported with a patch?:
(a) add a new function that does regular expressions searching / matching with a resource checker (eg a timer);
(b) write a local linter that reports an error for any use of the builtin regular expression tools;
(c) fix all the lint warnings;
(d) commit the linter.
CVE 10 if you use you current version of Python to serve files over ftp, and parse the incoming files using the most obscure file type found in the forbidden libraries of the Vatican
And your ISO etc certificates make this CVE mandatory priority 1 action point
Seriously. We got 116 github dependabot alerts this week. Half of them for dev dependencies.
I tried to raise that with my internal security team recently - don't clutter my vulnerability dashboard with issues in dev dependencies. They somewhat rightly pointed out that malware needs to be dealt even if it's a dev dependency. So my suggestion went nowhere because I guess we can't filter by type of vulnerability.
Working in the EU energy sector where we have to work with NIS2 compliance, I'd argue that your security team rightly pointed it out. I suspect that's what you mean though, and the rightly is just there because you agree with it but don't like it. We work with even more tight dependencies policies than just having alerts. We have a set of pre-approved and yearly vetted packages, like pandas or pyarrow for Python data work. Aside from that we have some isolated development environments where your pipeline can get access to something like SQLC for Go. Which is essentially where your dev dependency lives in it's own environment where it can produce the code it needs to and then submit it for approval into your regular dev environment.
Ironically we'd probably need to run Dependabot itself in a mirrored environment since it too has external dependencies we'd probably not want to vet.
I do think external dependencies are among our biggest security threats though. It's so hard to vet them, and compliance basically comes down to "We trust the apache software foundation enough, and pyarrow is vital to our business, so we accept the risks", and then you lock versions and aren't the first to update except for vulnerabilities. Shadow AI is obviously the number one security threat right now, especially in enterprise with people who are very tech savvy. This makes dependencies so much worse though, because now everyone can (if their systems aren't locked down tight) do so many crazy things. Both with the "non-sanctioned" AI but also with the code it can generate for them.
Yeah I completely understand their intent, but I might get 30 vulnerabilities across a multiple repos flagged in a week. It is already tedious to check them all and assess if they're worth worrying about let alone having to update them. These are 99% Javascript though - I suspect other ecosystems are much more manageable.
It's easier to keep stuff up to date these days. If you have a project with typescript, unit tests, and end to end tests like cypress you can just have dependabot create the PRs to update packages. If everything passes you just have to hit the merge button.
Just updating everything is probably easier than assessing if it's possible to trigger an exploit with the way you use the package.
Dev dependencies is how they compromised SolarWinds and thereby most of the US federal government.
> The attackers used a supply chain attack. The attackers accessed the build system belonging to the software company SolarWinds, possibly via SolarWinds's Microsoft Office 365 account, which had also been compromised at some point. SolarWinds was using build management and continuous integration server TeamCity provided by the Czech company JetBrains. In 2021 The New York Times stated that unknown parties apparently embedded malware in JetBrains' software and through this way compromised also SolarWinds.
https://en.wikipedia.org/wiki/2020_United_States_federal_gov...
I don’t know what kind of software you write, how valuable your company’s infrastructure is, etc. But supply chain and insider threat in security/infrastructure is a big topic — that I’m sure they’re concerned about because that’s their area of responsibility.
Even if I’m personally sympathetic to not wanting to deal with the churn of dev dependency updates.
This is very real, but such CVEs are such a tiny fraction in relation to denial-of-service-due-to-regex that it’s hard to take the system seriously.
So far as I’m concerned the solution is to isolate everything as much as possible. I’d love to see something on the CVE classification side to also address the signal to noise problem but I don’t see it happening.
Pretty much - I don't know too much about the CVE process but if ReDoS stuff was flagged at the CVE level as "exploitable only with unconstrained inputs" then great - I know my tests have sane inputs, so I'll close thanks.
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.
The common thread of late really seems to be the node ecosystem and the, frankly, low skill people that abound within it.
When we were making fun of leftpad saying node is unsuitable for serious work, it was labeled elitism. What is it now?
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...
What if... on the vulnerability report rules page there's an image of some text saying something like "your report must include the text: turtle123". Reports without that text get automatically deleted.
Sure - modern AI can figure that out, but I bet in a vast majority of cases they won't.
Have you considered requiring a small payment for vulnerability disclosure? Refund it on payout. This should be very effective at deterring spammers. It also sucks for real reports, but beats shutting down the program entirely.
Why would anyone pay money to have a chance of being arrested?
Sure, it sounds dumb when you say it like that.
But do you know how many people are doing things that are even dumber right this very minute? I don't know either, but I'm sure it's larger than either of us would like to admit.
If a vulnerability disclosure program has a good track record of paying out, and legitimate reports get refunded, why not?
Again, the alternative might be shutting down the program entirely.
It's not a horrible idea... the challenge there would be making that payment/refund flow totally transparent in order to build trust and be fair to the researchers.
Yeah, I help review security reports for a small FOSS organization, and someone reported a "critical" vulnerability about a publicly-accessible SVN server. Like yes, that is indeed the purpose of hosting open source software. But at least that report was obviously bogus; much worse are the ones that look legitimate at first, so you have to read through dozens of AI-generated paragraphs to make sure that there's nothing valid hidden in there.
but why would you answer with a C&D if you are overwhelmed? provided, it's not always the same person?
I hated these low-effort reports, so I created a simple automation that checks my security inbox, mentions me in #security on Slack for things that look legitimate so I see them quickly, and marks things that seem entirely automated as spam.
I still check the spam folder for legitimate emails, but so far there haven't been any false positives.
Have you considered having an agent, or just a model, classify/triage them for you? Modern problems require modern solutions.
Its been like that for half a decade across all software. People act like finding a linux kernel bug is a big deal, completely ignoring the fact that in order to exploit that bug, the attacker has to be able to run code on your computer in the first place, which is extremely hard to do these days remotely.
Also people ironically just DGAF that much. The last actual bad exploit was log4shell in java, which given how it was introduced (i.e someone purposefully at Apache made it so a log statement can execute code, and nobody questioned it before pushing it to prod), should have been the signal for everyone to completely remove all Apache libraries from their services, but yet all the software is still being used.
These bugs are indeed important, you need them once you‘ve found a bug in an application.
I feel like the current situation is temporary. LLMs are finding all the bugs. LLMs are also help fixing most of the bugs. Once most of the bugs are fixed, LLMs should be good at finding bugs before shipping them, the stream of bug reports will die down, and we'll be back to vulnerabiltiy reports being special.
Further, the fact that bugs are so easy to find by LLMs means there is strong incentives to find ways to minimize creating bugs in the first place. That could be new or better languages, less 3rd party dependencies, more vetted code, better linters, better fuzzers, whatever. The point the new reality of bugs being easy to find will, actually must, lead to less bugs eventually because the world can't function with easy to find bugs.
I feel this sentiment is wishful thinking,but I want to start by saying I hope it turns out to be correct.
I find that often bugs will be created when using an LLM, like others have said. Saying that this can then be fixed by identifying all the bugs created by an LLM with an LLM doesnt guarantee another bug is not introduced when the LLM is addressing the initial problem.
Also, what if the LLM has a blind spot. They certainly also could be incapable of finding or fixing a bug. They dont pass any benchmark at 100% right now. Also also, guaranteeing there are no bugs in your code is like saying you have 100% test coverage, all of the tests pass, and they are written perfectly. Saying that you can simply identify and fix the bugs also assumes there is enough time and energy to find all of the bugs that exist within a project and then to address them. Even LLMs use time and energy. In a sufficiently complex system that is certainly wishful thinking.
Considering the size and complexity of a lot of modern software (like web browsers, 3d modelling software, game engines, etc.) software is just too complex to not have bugs even when created and managed by LLMs.
There will continue to be bugs in code and we will simply have to live with the fact that LLMs make it easier to exploit computer systems. I mean consider a hardware bug like Spectre [0]. If bugs like this become easier to find does that mean our existing hardware will just become obsolete more quickly? that type of problem can be addressed, but at quite a high cost.
Not sure what all of this means for the future.
0. https://en.wikipedia.org/wiki/Spectre_%28security_vulnerabil...
If LLMs can trivially find bugs, then they can trivially find bugs. If they can't find any bugs that doesn't mean there are no bugs but it suggests that others can't easily find them either. So the LLMs find all the bugs problem is fixed by asking the LLMs to find them before you ship.
Read what wrote, I didn't say your program will be bug free. I said, if the LLM can trivally find the bug it will. If it can't then we're at worst, back to the state of before LLMs could find bugs, but likely much better since we fixed so many of the,
So, the fact that LLMs can trivially find bugs is enough to get the bugs fixed.
You, and several others, seemed to think I was saying LLMs would fix all the bugs. I never said that. I said they'd help. Finding them is help. Writing a possible fix is often help. Writing a possible fix and seeing if they can detect a bug after the fix is applied is also help. Automating the entire things and letting LLMs fix them without review is likely not help.
That supposes that LLMs can write secure software. Also, if we assume that finding bugs is easier that not creating them (reasonable I would say), the supply of bugs will never be exhausted.
How can it be easier to find them than to not create them? Whatever you do to find them, you could do before you release.
What's the difference between finding bugs and not making? Just run the bug finding in during CICD.
> That supposes that LLMs can write secure software.
I think we're at the point that the best LLMs can indeed write software that's far more secure than your average programmer. Partly because the average is so terrible.
Lol you think LLMs are generating bug free code?
I never said that. I said they are good at helping fix them. Go read the bug reports on firefox, or Safari, or Chrome. Most of them have a fix. It might be wrong but it usually points in the right direction, which is a 1000x more than nearly all human bug reports. So, the LLM helps. which is all I stated.
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.
There's lots of things to show for the research!
Part of what the research shows is that correctness-by-proof has a cost in developer effort.
If there really is a vulnerability-apocalypse due to AI, and it's not just a different flavour of AI hype, the cost of having insecure software will rise to the point that the cost of dealing with insecure or incorrect code at time of creation becomes less than the cost of ignoring it until it blows up.
I doubt it'll rise so much that we'll want to face the cost of behaviour proofs for much code at all, but it's quite possible it'll rise enough that we want to do things like prove that indices are in bounds, at compile time, so vector accesses can skip checks without compromising safety.
I fear it'll just move the problem one layer up. Sure, you've now proven that the code matches the specification - but how do you ensure the specification is watertight?
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.
> 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.
I think your logic is partly correct but the fact that the same LLMs are allowing an exponential increase in insecure code generated is a counterbalancing point. I do not think this phenomena will slow down.
Nah, those same LLMs, if prompted correctly, will be able to do an audit pass and a fix pass on that LLM-generated code. It’s a tooling issue that will get fixed in time.
> But that won't last forever, either. As LLMs find increasingly difficult-to-find vulnerabilities, there will be fewer of them to report.
That is not my experience at all. People will continue to high-volume spam intended behaviour as if it is a bug.
There will be fewer reports that matter as you fix things - but the volume of reports will either stay steady or go up. Making it harder to even notice the ones that matter.
The problem always existed, but nobody amassed a sufficiently large army of trolls to exploit it until now. So it wasn't a priority to solve it before, but now it is. We're going to have to learn to differentiate reports that matter from those that don't. Classifying reports might actually be something you could productively use an LLM for..
When we solved this problem for email... We just dumped everything similar to untrusted into the rubbish bin. Important things can vanish too, and that's an acceptable price.
It's not (just) more of them, it's the same ones reported by multiple people.
I think the point is those issues are now easily discoverable and are nearly public because of it.
> LLMs are as good as almost any security researcher, and anyone can run them.
I wonder what the metrics are. Also, not "anyone", just the affordable.
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.
They weren't special even before LLMs. Drive-by script-kiddies would run some basic scripts against your platform and send generally-not-actually-a-vulnerability reports, claiming that these were big problems, and requesting to be paid bug bounties.
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.
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.
This x 1000
I’ve been screaming this from the rooftops. Impact is what was always important. No one is going to take down prod to do an emergency patch on an RCE that COULD NEVER ACTUALLY BE EXPLOITED.
I feel like we’re witnessing the result of multiple roles suddenly becoming security aware but not having the background or understanding to make any sense of it.
In an ideal universe yes. But we live in a world where vulnerability scanners reign supreme.
Yep, I've updated dependencies with an RCE that can't be exploited in my codebase just to keep my security team happy. Not worth the multiple arguments about it not actually being an issue.
Linus Torvalds once went on record saying security vulnerabilities are no more important than regular bugs.
This of course made vulnerability researchers seethe worse than aggrieved Redditors.
It turns out he was right all along.
The author also gets it wrong by assuming that regular bug reporters are not "providing a service". They are.
When I wrote up a bug report, I made sure it's thorough with detailed steps to reproduce. It takes a lot of time and I've done it professionally for projects you've absolutely heard of.
Having said that, getting them ignored repeatedly and — even worse — having my detailed PRs rejected, sometimes within minutes, as if I'm some ignorant luser is why I don't do it anymore. My time is more valuable than your hubris.
A lot of open source developers have their heads so far up their own asses they forgot that it takes a community for projects to be successful.
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'm curious about people's experiences with Kalshi support in this context.
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?
There's only one Magnus Carlsen, who earned > $1 million in 2025 for playing chess, but the long tail, there were 26 people who made more than $100k, https://thechessworld.com/articles/general-information/the-1...
but like, if you mean literally "someone gave them money and they played a game of chess", the number becomes much bigger. Chess coaches, streamers, club instructors, exhibition players, league players, camp counselors, and titled players receiving appearance fees, etc. All told, you're looking at ten's of thousands across the world.
And if you mean “people who can live off of tournament winnings” it’s not more than 26.
It’s like most of art, writing, and sports. The only way to make money is by becoming a teacher.
"LLMs are as good as almost any security researcher"
No they are not. Everything else can be safely ignored. The author is suffering from AI psychosis and needs to get some help.
>> 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.
I don't think the gift analogy works well. In most cultures, turning down or even ignoring a gift is considered anywhere from impolite to hugely offensive. But that's the opposite of open source: there's nothing wrong with requesting changes to a PR or even closing 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?
No, because xorg is a dead project that doesn't take any patches from anywhere and xlibre has shit code quality and is probably vibecoded now
[dead]
[flagged]