In Heroes of Might & Magic 3, “several” means 5–9. 10–19 is “pack”, 20–49 is “lots”, 50–99 is “horde”, 100–249 is “throng”, 250–499 is “swarm”, 500–999 is “zounds…” and 1000+ is “legion”.
I suggest this post be renamed “A legion of vulnerabilities has been discovered…”
Maybe we should use legion as a collective noun for vulnerabilities. Like murder of crows or school of fish. Would signal the urgency no matter the actual number or impact...
Hah! I remember playing that game as a young non-English-speaker and having no idea what these qualifiers meant. They never give the scale, it's just assumed you know that several < pack < lots < horde < throng etc. Which.. even as bilingual as I am today I'd struggle to put on a scale.
https://docs.kernel.org/process/cve.html states that because almost any kernel bug can potentially compromise system security, the CVE team acts with extreme caution and labels nearly all bug fixes with a CVE
yes because the majority are memory safety issues, and it's automatically assumed that a memory safety bug can lead to a vuln
one again illustrating the importance of encapsulating unsafe behavior. perhaps c should get a __UNSAFE { } block, where memory access is encapsulated and thus most bugs occurring outside of those blocks do not need to be marked as CVEs.
No. It's because Greg doesn't like the CVE system and MITRE, the stupidest decision ever, made Greg a CNA, and this is his tantrum that he's been waiting 40 years to throw.
C has many more ways to trigger undefined behaviour than memory access. If C had unsafe blocks they'd restrict most forms of signed integer arithmetic and shifting, for a start.
I was looking earlier and the majority of these do not have a CVSS score assigned to them yet, but a lot of them that did were >7.0 (although I suppose by nature that the more impactful CVEs are going to be scored more quickly)
That’s probably a great thing. The initial friction of AI overwhelming projects certainly sucks, but once there are better processes to deal with them it’s going to strengthen the quality of so many projects!
All the good backdoors have got to be in the hardware anyway. There's only a handful of companies making the chips all our systems run on. US companies that can be forced to backdoor their stuff under secret gag orders. I mean, I'm not saying that PSP/CSME subsystem are a backdoor, but if I were going to force companies to add one, it'd probably look similar.
Is there a way to know if a particular vanilla kernel has a particular CVE addressed? Unhelpfully, the ChangeLog-* only seems to contain sporadic references to CVEs.
"Several" feels a bit of an understatement, there are 1313 CVEs listed on that page!
Wonder how many of these NSA and others been sitting on, for how long and how many are still there? I guess the silver lining with the aixplosion of CVEs is that software eventually will get more secure.
NSA allegedly used to have a "black budget" of around a couple dozen million dollars for software sabotaging. I wonder what percentage of those CVEs could be related to it...
I checked out the last (highest-numbered) one just as a quick sanity check:
> In the Linux kernel, the following vulnerability has been resolved:
> usb: typec: ucsi: unregister debugfs entries on teardown
> ucsi_register() creates per-instance debugfs entries, but
> ucsi_unregister() keeps them around until ucsi_destroy().
> Drivers like ucsi_glink that unregister/register the same UCSI
> instance across remoteproc restart then try to create an already
> existing debugfs directory and log:
> debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi'
> Unregister debugfs entries as part of ucsi_unregister(), and
> clear ucsi->debugfs after freeing it so repeated unregister
> paths remain safe.
I'm going to need someone to explain how that could possibly become a "vulnerability".
If any of these were remotely exploitable it would be getting much louder and more urgent news. Local privilege escalation bugs are encountered all the time.
note that _any_ bugfix is assigned a cve, which makes for big numbers.
>“Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel… Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.”
I've been following these announcements for a few years. This is the most CVEs I've seen in one by a wide margin, although there have been some big sets coming through for things like chromium, openssl. I agree it's mostly meaningless without context. So what's the context? Who/what found all these bugs?
I do find it interesting though, that in the interest of transparency, every bugfix gets a CVE. Which ends up being a huge number… which will ultimately yield a more insecure environment as we’re getting conditioned to ignore/discount CVEs by the volume.
Over-reporting in this case seems to risk being counterproductive.
Counterproductive for whom? The stance of the kernel developers is that whether a bug is a vulnerability or not depends on intended use. They say, we do not dictate use, therefore this decision is out of scope for us. This makes kernel development more focussed and productive.
I would argue that it is more productive for the enduser as well. Not making a decision they cannot reasonably make is better then blindly believing in a decision that is likely wrong for your usecase.
Reasoning behind it being that theoretically, a RAID could be accessible over the network via NFS, iSCSI, etc... so if it gents corrupted, the above buggy code path in the recovery is triggered effectively over the network.
There's nothing malicious about the CVE. It lets people use it to index issues, like it was supposed to, and stops dumb people from using it as an indicator of work done or vulnerability level, things that it was never useful for.
Is it possible that some of these bugs were already exploited by governments? And AI might help use close of that kind of thing? (And expose other kinds of things , in a kind of AI arms race?)
Probably. Organizations specializing in hacking are probably having a great time hacking everything and installing permanent presence. It is probably like a gold rush period.
We're considering weekly reboots at work now with the pace of kernel updates coming out, and the speed with which vulnerabilities are getting exploited.
There is exactly one CVE in the entire list that is high severity, and it affects an obscure IBM NIC driver for big iron systems used in companies with more money than brains.
Problem is it takes more effort to read the CVE list and work out if you have one of the drivers impacted loaded than it does to just update the kernel.
Sorry but I'm not causing outages and rebooting systems every four days because the people whose job it is to do this can't triage properly. They are actively making people's lives more difficult.
If your system goes down to update a kernel then you have a major issue already. This is like manually renewing https certs. When the task is done often enough you just automate it in a painless way.
Well then, it's a business decision to accept the risks. IMO it makes sense that a percentage of machines would always be offline for maintenance. If you're running bare metal and you cannot afford 10% of your machines being offline at most times, then you're in deep shit if there's even a tiny traffic irregularity, and it's a sign that your management is YOLOing the company. Not uncommon though.
severity on cve is a crapshoot most of the time, but especially with linux cna. i would not advise relying on them for decision making.
"We can not assign severity
[...]
So any group that attempts to give a “severity score” to a Linux CVE is lying to you, UNLESS they know exactly your use case.
ALWAYS ignore any attempt that groups such as NIST/NVD that purport to assign things like CVSS scores to a vulnerability. Those numbers are false and give companies a “fake sense of security”."
Regarding the fart question, it depends on the audio driver and the underlying codec. While you would think “free as in beer” would make for truly resonant flatulence, only truly letting loose (plus a Bic lighter) brings real enlightenment.
Linux has never, at any point in history, lacked flaws that could be exploited to escalate privileges. The only question has been how well-known the flaws were, and when. The count of latent local privilege escalation bugs has never been zero.
This is great, more access did provide more eyes on these problems.
But, does that all of these being found now call into question, not the open source model logic itself, but the ability of human eyes to find security issues? These vulnerabilities have been sitting here for however long, but how many thousands of humans did not find them before AI?
The threshold for Microsoft and Apple to actually report vulnerabilities is MUCH MUCH higher than for Linux, and open source as a whole. They generally only disclose issues in Windows and macOS that are quite serious and impactful.
For Linux, the threshold is nearer to the point of it being questionable whether a bug is even exploitable on a real production distro, compiled and run with any sort of sane configuration.
Some vulnerabilities are incredibly complex and are identified not through the code itself but through various attack chains being strung together.
Also there are likely a lot of vulnerabilities identified but the work required to fix them vs the complexity to exploit them means they don't get fixed.
I'd wager we don't have an issue with identifying vulnerabilities but the ability to fix them.
I work in security consulting and identifying vulnerabilities isn't the difficult part its actually fixing them and fixing the ones that have valid exploitable attack chains that matter
I thought the "Security in the LLM age" talk by Greg Kroah-Hartman published this week from Kernel Recipes was pretty interesting: https://www.youtube.com/watch?v=NnV_cWeoo5Q
Extending the ratio from my other comment. What are the token ratios between using LLMs to:
1. Create functional software
2. Find bugs in functional software
3. Triage/Prioritise a quadrupling of the reported CVEs
4. Fix the bugs while keeping the software functional
I'm assuming that #2, #3, and #4 require more tokens (each or cumulatively) that #1, then there will be increase in the amount of insecure software because, with the advent of LLMs (that allow otherwise non-software developers to become software developers), there will be (a lot?) more software being created.
If we want software security to get better, then the existence of LLMs requires the increasing use of LLMs. I find this quite interesting.
1. LLMs have high false positive rate. From mythos 79 vulnerabilities found in the Linux kernel, only a single digit were actual bugs and they were all obscure so don’t panic.
2. What does obscure mean? I don’t really understand it, but many of the bugs have to do with custom network drivers or other custom drivers that are very specific to certain organizational setups, not a general Linux distro issue.
3. He’s very frustrated with the high false positive rate mythos generates. Even after multiple rounds of adversarial review and prompting strats, he mentions it is > 20% false positive rate, which wastes a lot of time. When some random user on the internet brings up a bug with an LLM it’s almost always fake, he even says just push back a few times claiming it’s not a bug to see if it’s a real bug (LLMs very quickly cave and “notice their mistake” etc)
4. General observation on the useful bugs mythos finds. Chain multiple smaller bugs to see if you can get a bigger breakage. Mythos is really good at constructing these long convoluted chains that fuzzers miss.
5. Go through recent bug fixes and check if similar bugs are hidden elsewhere in the codebase. Mythos is good at such pattern matching albeit with a high false positive rate.
Final conclusion: don’t panic, the bugs are getting fixed, this is not as bad as the first fuzzer bug mania and will be fixed quicker, he estimates a year and we won’t see huge bug reports anymore.
I use daybreak to do most of my security scanning. I always tell it that any finding must be accompanied by a harness that faithfully reproduces it using the code at the current commit with no modifications. In my experience it eliminates most if not all of the false positives.
>he mentions it is > 20% false positive rate, which wastes a lot of time.
If it's just 20% that is really low. Especially for complicated long chain potential bugs.
Most other detection tools have much higher rates of FP, or much higher rates of false negative.
Then you have humans that miss bugs for 20+ years. Or, they don't tell you about the things they thought were bugs they wasted hours on themselves. Because of this it's really hard to measure how bad/good the AI really is.
It would be interesting to know why the more SOTA models are getting the FPs. Is it from a lack of understanding of C? Is it complex code with deep branches? Is it code smell and convoluted logic?
It's an ~hour-long video! I don't blame anyone for preferring the 2-minute TL;DR if it's available! ¯\_(ツ)_/¯
If there's something wrong or prone to misinterpretation in the TL;DR it would be better to call it out in response to that, rather than the users responding to the TL;DR, simply because it's likely that's what most people will respond to.
Yeah, if the only way to get content is video, I don’t consume it. It’s usually a complete waste of time, unless you speed it up until the speakers are chipmunks. The information density of video is poor compared to text.
He makes the exact opposite claim in the video. He thinks 20% is far too high and no one will pay for it once these tools are no longer available for free. He specifically cites the company Coverity that also found many useful bugs with their code analyzer but had a much smaller false positive rate (something like 5% I think), and no one paid for that, and the founder had to write a post mortem. He thinks the same’s going to happen to these LLM tools if they stop providing it for free.
If you push back against a LLM, you can convince it in almost anything.
If it's obviously a bug you can just fix it, and if it's obviously not, you can ignore it. In either case you've already done the work to understand it.
If it's on the borderline, and you push back against the GPU with a plausible sounding reason, it's likely to agree, regardless of whether oe nor it's a bug.
I've never gotten a good outcome out of arguing with the GPU.
> push back a few times claiming it’s not a bug to see if it’s a real bug (LLMs very quickly cave and “notice their mistake” etc)
I wonder how much more likely the LLM is to cave for a false-bug. There have been a number of times in my own (non-security) work that I'm told the LLM that it was wrong, it apologized and agreed, and then later that day I realized it was correct after all.
For additional context, Greg Kroah-Hartman has been contributing to Linux for 3 decades, and is _the_ maintainer for Linux's stable branch, as well as many other core parts of Linux.
My takeaways:
* Do not panic. Do acknowledge that LLMs are sycophantic, and LLM companies are trying to sell their stuff. "Yes, push back hard".
* If it smells like AI slop, treat it like AI slop and relax. If someone sends you 50 security reports, and a few look wrong, just calm down and ignore them; or ask for proof-of-humanness.
* A report without a patch is, for better or worse, worthless if you maintain widely used open source software.
* Of course, there are real vulnerabilities being discovered and reported. Keep calm, keep fixing real bugs, and carry on.
* Delete as much code as you possibly can. Reduce your surface area. Do the same thing you've always been doing.
Anyone here who wanted an unreliable summarization from a chatbot could have just asked a chatbot for one. If the count/breakdown of issues is important to someone, it's probably important to them that it's accurate. That means they'll have to take the time to verify it properly anyway.
Would you say the same had they used grep | wc -l ? I'm not a huge AI fan but for the post above it's just a tool they used to count, not to write. Anyone who needs to verify it shouldn't be trusting HN comments anyway.
someone did want an unreliable count from a chatbot, and did ask for it.. and they passed the information along in their comment (along with a very upfront comment about how the generated it). Feel free to come with other methods to generate unreliable summarization if you don't like the chatbot generated one. I'm sure humans and off by one errors or maybe badly formed regex's can give you a whole range of new things to complain about.
We know that humans are flawed and make errors. Those human generated errors are an intrinsic part of "conversation between humans". We both expect and accept that when we read posts here because, as the guideline states, "HN is for conversation between humans."
Oh please, I can use a computer program to do counts for me while roughly helping me sort into categories. Don’t be ridiculous. I labeled it as such without misrepresentation as well.
People who are respectful enough to disclose their use of AI in the first place will hopefully be respectful enough not to fill this space with AI slop after being informed/reminded that it isn't welcome.
Security has always been a cat and mouse game. The usual precautions about software updates, least privileged access, separation/sandboxing, and precautions like not pasting/installing random software (especially something on Show HN) continue to apply; but at this point, I'd suggest thinking more towards a model of "How do I best detect, and contain a compromise" model.
One thing I do is a wallet.dat honeypot with (now) ~$1700 of bitcoin. Any movement essentially shuts down my home network from external access. At worst, it's a justifiable tax deduction, not capital gains :)
I wish everyone used the same versioning system for all software: A.B.C increment C for security patches, increment B for new features, increment A for systemic changes.
Well, this is called semantic versioning (semver) and it is the most popular versioning system out there: https://semver.org/
However I see software variants where simple numbers work as well, e.g. Firmware code that runs on totally self contained hardware is often just versioned with simple integers, that is because most updates (releases) of that software contain both features and bugfixws and "breaking changes" don't apply to stuff that doesn't read or write files. So you could use semver and have 1.50.0, 1.51.0, 1.52.0 forever, but by that point you can just give it aimple integer versions.
Linux kernel introduces bug fixes, new features, and major systemic changes all the time. That’s why using SemVer for Linux is pointless and why Linus dropped it.
If the Western AI companies get their way, only the developers/companies that have access and paid extra for the security review will get to have a lower chance of such issues.
You're going to get a wide range of responses on this but given the improvement in these models in just one year, and the number of bugs they're detecting which humans could not, I suspect that even median vibe-coded software is going to surpass median human coded software soon - if it hasn't already.
The important thing to remember here is there perfect isn't on the table. The benchmark is existing human-introduced bugs vs LLM-introduced bugs. Many developers have encountered odd bugs which a human would not have introduced, while forgetting about all the bugs caught which humans introduced. Or their opinion is formed by models from six months ago.
Mine isn’t. To point: we don’t really have a definition of vibe-coded anymore. All software has some degree of AI enhancement now. Is vibe-coded when it’s 60%? 80% 100%?
Try out Opus 5.5 on high. It’s shockingly good. Of course if you’re trying to one-shot a sprawling application with load balanced distributed DBs, you’re going to have a bad time. For small, defined features, it’s pretty fucking great.
Depends on if people are willing to pay the extra wall time to write mathematical proofs for everything to make it provably correct. Takes way way longer but modern models can do it.
It depends? LLMs are not a silver bullet for writing bug free software (IME at least, and of course it also depends on the "threshold" what actually counts as a bug).
They're definitely a useful additional tool for finding more (and more obscure) bugs, but that takes a lot of both human and compute effort too, and after the reports are clean you still can't be 100% sure (but at least a bit more confident) that the code is now free of bugs.
Because most devs don't want to do formal verified system development. I know only one OS working on that which is open source Ironclad OS hope many others follow this path. It is Ada/SPARK based but others should do with whatever language they are using. NetBSD also heard going to do something similar with C in last AGM
> most devs don't want to do formal verified system development.
That may be true. Serious question though: even if most devs wanted to develop formally verified code, do you think that it is reasonable to suggest that the typical systems developer could do it with today's tools? I don't mean verified protocols (TLA+) or verified algorithms (SPIN) I mean end-to-end verified code, a-la seL4. I got the impression that this is still very specialised work. Perhaps things have advanced since I last checked.
Do you make your professional career by building formally verified systems? I ask because I don't think that the reason comes down to "because most devs don't want to do formal verified system development". It's much more complicated of course.
I could believe it. Verified system development most likely comes with metric ton of paperwork.
Want to merge the PR? I need verified sign off in ServiceNow by staff level engineer. They are on vacation for 2 weeks? Did manager fill out delegation paperwork in ServiceNow with VP sign off? Oh they did but they forgot to put in return date AND time. Form needs to be corrected and reapproved before we can go into ServiceNow and make changes.
Genode as a whole isn’t formally verified, but it can use seL4 as a kernel, and it uses a robust capabilities system to sandbox basically everything, including drivers.
As it evolves I suspect there will be a push to verify more components of the stack. Once the capabilities layer can be verified, verification of most other components and drivers would become much less urgent.
I am an experienced engineer and am building a product actively right now. I started pre-AI, and cautiously adopted AI. I am using AI tools a lot now, but still dedicate a lot of my attention to validating it's output and design decisions.
I recently asked it to review my code and configs from the security perspective. Wow! 90% of the things it identified were MY bad decisions dating from pre-AI development. I am honestly humbled and impressed at the same time.
AI can create slop, and it can create quality products. It depends who is using it, and how.
I do it all the time, and I get feedback about tons of things that need to be fixed. I ask Claude to review ChatGPT code and vice versa. I also ask Claude to review Claude code, and it finds issues as well. I ask it to review copy I wrote and offer style, grammar, voice, and consistency suggestions. LLMs make pretty darn good reviewers.
In this case, what matters most is that the AI security review raised real issues that needed to be fixed. That is valuable.
While I totally agree with the statement, question is - is this challenge even solvable? Though where I come from there is a proverb - "for every malady there's a remedy", wonder what it can be this time.
And, of course, there are piles of legacy corporate spaghetti entangled in incomprehensible mess everywhere you look at. And this shit still runs, this precious hand-carved hand-weaved mess of bad decisions. I can't wait for LLMs to rewrite most of it.
No, it will be a tsunami of new discoveries in old code bases at first, but that will settle down as those old bugs are fixed. It's been like this with every new code analysis tool (the wave may be exceptionally high this time though).
There is a difference here. The "new coding analysis tool" that you use for the analogy here is getting better every few weeks with the release of new models.
It is plausible to assume that, for instance, a Linux kernel that was hardened for CVEs that Sonnet 3.5 could detect is not hardened for bugs that Sonnet 4.5, 5.5, Opus, Fable, and models in 2027 can and will be able to detect.
Hence, it is rather a constant catch-up game until the LLM improvements might hit a ceiling and won't get any better in this regard.
Search for "Security in the LLM age" in this HN page for a reality check, apparently 80% of the security vulnerabilities that Mythos initially flagged in the Linux kernel turned out to be false positives. Better than nothing of course, but it really doesn't look like Mythos is quite the "wonder weapon" it was marketed as (and the situation by far isn't as dire as the initial flurry of Mythos news).
The problem isn't the 20% actual bugs found (that's great), but the 80% false positives which are reported with high confidence and (most likely) misleading reproduction code. An experienced programmer familiar with the code base first needs to validate all reports and throw away 4 in 5. That's a massive waste of time.
In my hobby projects I use LLMs in my development workflow mainly for passive bug scanning, reviewing and helping to maintain tests, they are definitely useful for catching some bugs early and noticing unhandled edge cases, but they're also definitely no silver bullet (they sometimes ignore quite obvious bugs. and the fewer 'actual' bugs remain, the more one has to be careful about false positives). E.g. the funny thing is that now I'm actually slower than before due to the intense 'rubber ducking' with LLMs, but I still want to pretend that the resulting code is more robust out of the door.
Eg everything that Greg KH says in the video sounds very familiar, and it's very disappointing that Mythos still suffers from the same issues (or maybe even worse) as older models.
> An experienced programmer familiar with the code base first needs to validate all reports and throw away 4 in 5. That's a massive waste of time.
Okay, but again, even with all that extra effort, they found 4x as many bugs, so it seems like the effort is clearly worth it.
And each model gets more reliable, we get better at building proper reproduction code, etc. - this was mostly a comment about the cycle, direction, and velocity we should expect from the future, given this has already happened twice.
You assume an infinite level of brokenness is legacy code bases. Granted, working on those things one can get the impression, but I think stable code converges to a low level of bugs after sufficient scrutiny and superhuman scrutiny doesn't reveal a never ending deluge of new problems. Not to mention that the bug-chains that you need for a successful exploit keep getting longer very quickly as more problems are discovered and the code is hardened.
I expect that the incremental model improvements will become smaller and smaller until they run into the same diminishing returns effect like all other new technologies.
I'm not ready to take any bets when exactly the curve will be flat though ;) (e.g. in a just couple of months or a couple of years)
It's normal practice for companies to have a backlog of scanner tool results. Sometimes in the thousands for a larger project. Many of them are legit bugs but also highly local and so far down the stack they're hard to exploit. It takes a ton of work to triage, more than management is willing to spend. Also more than they're wiling to fix and paydown.
I predict a different outcome: the rate of vulns identified and fixed will be more than matched by the rate of new vulns introduced by irresponsible use of LLMs on top of brittle and unwieldy tech stacks.
The result will be an overall increase in turbulence and the normalization of steadily intensifying security crises in nearly all software systems.
The only projects that will escape this fate are those which have either been already developed from ground up with rigorous and principled, verified (or verifiable) design, or those which are rewritten to gain this.
> AI is going to expose how fragile the entire computing infrastructure in our world is.
this is a good outcome. A forcing function to encourage all computing to be more secure can only be good in the long term, even if there's a lot of pain in the short term.
> the benefits of it will not be applied uniformly.
why not? Any system you have permission to use and store your data should be beneficial to you if it became more secure. Unless...of course if you're the one who desires unauthorized access.
I wonder what “a lot of pain” could mean here in a world where Crowdstrike is allowed to render half of the world unbootable without repercussions.
Not that I think you are wrong, I am sometimes just confused why we hold back on fixing security because of imaginary deployment- and business-related pains, when it is so obviously unproblematic to crash half the world for a day?
I don't like AI code, but AI is a decent reviewer.
...for human code.
In the small startup I work for boss (ex-programmer) discovered fable, and ai-coded 15K lines . So much productivity! So great! He even asked multiple reviews and it was fine!
I ask it a couple of reviews and it finds only minor things. The code is a mess of duplication and different coding styles, so I start cleaning it up. After a couple of months the reviews (same ai model) start actually finding big logic bugs that were always there.
We might already be at the point where the Ai-Coder is generating stuff that ai-reviewer can't find and will automatically pass.
--
1M context window is what? 70-80k LOC, tops? Without comments or documentation?
That is a smallish project of a couple of components. AI will remain inherently myopic until it can keep in context whole codebases.
Exposing current problems is fine to me, but I am worried of how brittle AI code will be.
That's because lots of websites and applications are being written by low-skilled laborers in Third World nations. Many websites are rife with vulnerabilities and insecure configurations.
It's not that difficult to build secure (web) applications but it takes effort and knowledge to get it right. You can't expect a web designer who can barely code in JavaScript to build a secure back-end, configure and maintain it. That's just asking for trouble.
Even high-value sites are built by cheap laborers these days. LLMs (I refuse to call it A.I.) will expose their weaknesses within minutes.
I put weatherstripping on my front door and made part of my house much more comfortable and easy to heat in the winter. Then I bought an FLIR and found lots more places leaking heat. I made a list, hired a handyman, and I'm more comfortable and saving money.
Should I now expect to find even more places to seal up the next time I break out the FLIR?
Or you could categorize the current bug apocalypse under the heading "unsustainable trends will not be sustained."
The main way this analogy doesn't hold up to me is that your house is mostly static -- you're not rebuilding the walls, adding new doors or windows constantly.
But in software, especially with agents, we're constantly renovating the house. If you were renovating every 6 months I'd expect to find more places to seal up, even if you were following best practices in those remodels.
That being said, I do think we will reach an equilibrium where most vulnerabilities are found at PR time.
Some software, especially human facing products in competitive markets, will always have new security issues. But in general I agree. We are headed toward a different and generally more secure and reliable equilibrium. Hopefully it's the end of stupidly long bug lists in some products.
282 comments
[ 3.8 ms ] story [ 94.7 ms ] threadI suggest this post be renamed “A legion of vulnerabilities has been discovered…”
For context, there are 48,152 CVEs from 2025 and 73,356 in 2026 so far.
Yeah, the "Several" is a massive understatement.
one again illustrating the importance of encapsulating unsafe behavior. perhaps c should get a __UNSAFE { } block, where memory access is encapsulated and thus most bugs occurring outside of those blocks do not need to be marked as CVEs.
Seems like an enormous increase over 2024 and 2025.
Apparently by late summer this year, there were already more vulnerabilities found than in all of 2025.
They're not demanded because targets are just so easy to pop.
If we did secure software across the board with AI, there'd likely be a resurgence of calls for mandatory backdoors.
Wonder how many of these NSA and others been sitting on, for how long and how many are still there? I guess the silver lining with the aixplosion of CVEs is that software eventually will get more secure.
> In the Linux kernel, the following vulnerability has been resolved: > usb: typec: ucsi: unregister debugfs entries on teardown > ucsi_register() creates per-instance debugfs entries, but > ucsi_unregister() keeps them around until ucsi_destroy(). > Drivers like ucsi_glink that unregister/register the same UCSI > instance across remoteproc restart then try to create an already > existing debugfs directory and log: > debugfs: 'pmic_glink.ucsi.0' already exists in 'ucsi' > Unregister debugfs entries as part of ucsi_unregister(), and > clear ucsi->debugfs after freeing it so repeated unregister > paths remain safe.
I'm going to need someone to explain how that could possibly become a "vulnerability".
Remotely or locally exploitable? This is very lacking on information.
>“Due to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel… Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.”
https://docs.kernel.org/process/cve.html
"number of cves" is a useless metric, especially when it comes to the kernel.
I do find it interesting though, that in the interest of transparency, every bugfix gets a CVE. Which ends up being a huge number… which will ultimately yield a more insecure environment as we’re getting conditioned to ignore/discount CVEs by the volume.
Over-reporting in this case seems to risk being counterproductive.
I would argue that it is more productive for the enduser as well. Not making a decision they cannot reasonably make is better then blindly believing in a decision that is likely wrong for your usecase.
Any patch that is back ported to a stable kernel. And they have also started assigning CVSS scores with the same kind of malicious compliance.
Take for example, this patch in the device mapper RAID code:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
After back porting to stable, it got assigned CVE-2026-89558, and a CVSS score of 9.8:
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree...
Reasoning behind it being that theoretically, a RAID could be accessible over the network via NFS, iSCSI, etc... so if it gents corrupted, the above buggy code path in the recovery is triggered effectively over the network.
but no, in linux cve id is assigned "on a one to two week delay from when the fix has landed in a released stable kernel version."
These get released every few weeks. Tons of CVEs. If a kernel developer farts in the forest, does anyone hear it?
August had separate Debian kernel updates released four days apart. Does anyone even reboot that often?
I have three kernels installed over the last 45 days or so and I probably missed a few.
You can skip the Xanax this week.
Real businesses still run legacy file/print services, license daemons, proprietary applications. Some still run on bare metal.
You need outage windows. You can't just YOLO it and update prod during the day, it's unbelieveably irresponsible.
"We can not assign severity
[...]
So any group that attempts to give a “severity score” to a Linux CVE is lying to you, UNLESS they know exactly your use case.
ALWAYS ignore any attempt that groups such as NIST/NVD that purport to assign things like CVSS scores to a vulnerability. Those numbers are false and give companies a “fake sense of security”."
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignmen...
But, does that all of these being found now call into question, not the open source model logic itself, but the ability of human eyes to find security issues? These vulnerabilities have been sitting here for however long, but how many thousands of humans did not find them before AI?
For Linux, the threshold is nearer to the point of it being questionable whether a bug is even exploitable on a real production distro, compiled and run with any sort of sane configuration.
Also there are likely a lot of vulnerabilities identified but the work required to fix them vs the complexity to exploit them means they don't get fixed.
I'd wager we don't have an issue with identifying vulnerabilities but the ability to fix them.
I work in security consulting and identifying vulnerabilities isn't the difficult part its actually fixing them and fixing the ones that have valid exploitable attack chains that matter
alternative link, clearer source: https://lists.debian.org/debian-security-announce/2026/msg00... (https://news.ycombinator.com/item?id=49891411)
Extending the ratio from my other comment. What are the token ratios between using LLMs to:
1. Create functional software
2. Find bugs in functional software
3. Triage/Prioritise a quadrupling of the reported CVEs
4. Fix the bugs while keeping the software functional
I'm assuming that #2, #3, and #4 require more tokens (each or cumulatively) that #1, then there will be increase in the amount of insecure software because, with the advent of LLMs (that allow otherwise non-software developers to become software developers), there will be (a lot?) more software being created.
If we want software security to get better, then the existence of LLMs requires the increasing use of LLMs. I find this quite interesting.
1. LLMs have high false positive rate. From mythos 79 vulnerabilities found in the Linux kernel, only a single digit were actual bugs and they were all obscure so don’t panic.
2. What does obscure mean? I don’t really understand it, but many of the bugs have to do with custom network drivers or other custom drivers that are very specific to certain organizational setups, not a general Linux distro issue.
3. He’s very frustrated with the high false positive rate mythos generates. Even after multiple rounds of adversarial review and prompting strats, he mentions it is > 20% false positive rate, which wastes a lot of time. When some random user on the internet brings up a bug with an LLM it’s almost always fake, he even says just push back a few times claiming it’s not a bug to see if it’s a real bug (LLMs very quickly cave and “notice their mistake” etc)
4. General observation on the useful bugs mythos finds. Chain multiple smaller bugs to see if you can get a bigger breakage. Mythos is really good at constructing these long convoluted chains that fuzzers miss.
5. Go through recent bug fixes and check if similar bugs are hidden elsewhere in the codebase. Mythos is good at such pattern matching albeit with a high false positive rate.
Final conclusion: don’t panic, the bugs are getting fixed, this is not as bad as the first fuzzer bug mania and will be fixed quicker, he estimates a year and we won’t see huge bug reports anymore.
[0] https://news.ycombinator.com/item?id=49605691 [1] https://news.ycombinator.com/item?id=49897075 [2] https://huggingface.co/models?other=offensive-security
If it's just 20% that is really low. Especially for complicated long chain potential bugs.
Most other detection tools have much higher rates of FP, or much higher rates of false negative.
Then you have humans that miss bugs for 20+ years. Or, they don't tell you about the things they thought were bugs they wasted hours on themselves. Because of this it's really hard to measure how bad/good the AI really is.
It would be interesting to know why the more SOTA models are getting the FPs. Is it from a lack of understanding of C? Is it complex code with deep branches? Is it code smell and convoluted logic?
If there's something wrong or prone to misinterpretation in the TL;DR it would be better to call it out in response to that, rather than the users responding to the TL;DR, simply because it's likely that's what most people will respond to.
If it's obviously a bug you can just fix it, and if it's obviously not, you can ignore it. In either case you've already done the work to understand it.
If it's on the borderline, and you push back against the GPU with a plausible sounding reason, it's likely to agree, regardless of whether oe nor it's a bug.
I've never gotten a good outcome out of arguing with the GPU.
I wonder how much more likely the LLM is to cave for a false-bug. There have been a number of times in my own (non-security) work that I'm told the LLM that it was wrong, it apologized and agreed, and then later that day I realized it was correct after all.
My takeaways:
* Do not panic. Do acknowledge that LLMs are sycophantic, and LLM companies are trying to sell their stuff. "Yes, push back hard".
* If it smells like AI slop, treat it like AI slop and relax. If someone sends you 50 security reports, and a few look wrong, just calm down and ignore them; or ask for proof-of-humanness.
* A report without a patch is, for better or worse, worthless if you maintain widely used open source software.
* Of course, there are real vulnerabilities being discovered and reported. Keep calm, keep fixing real bugs, and carry on.
* Delete as much code as you possibly can. Reduce your surface area. Do the same thing you've always been doing.
Roughly 140 CVEs are in areas an unprivileged user might reach: net/sched, netfilter, bpf, io_uring, mm, kvm.
About 850 CVEs are in drivers or filesystems. Those usually need specific hardware, a mount, or root.
On Debian, many of the 140 also need user namespaces. Debian also blocks unprivileged bpf by default.
The above three paragraphs were made up by a non-deterministic computer program. I wouldn't take them as gospel.
https://news.ycombinator.com/newsguidelines.html
That was a human posting a count of issues generated by an ai... not an ai generated message? Or do all the issues need to be counted by hand now ?
One thing I do is a wallet.dat honeypot with (now) ~$1700 of bitcoin. Any movement essentially shuts down my home network from external access. At worst, it's a justifiable tax deduction, not capital gains :)
However I see software variants where simple numbers work as well, e.g. Firmware code that runs on totally self contained hardware is often just versioned with simple integers, that is because most updates (releases) of that software contain both features and bugfixws and "breaking changes" don't apply to stuff that doesn't read or write files. So you could use semver and have 1.50.0, 1.51.0, 1.52.0 forever, but by that point you can just give it aimple integer versions.
The important thing to remember here is there perfect isn't on the table. The benchmark is existing human-introduced bugs vs LLM-introduced bugs. Many developers have encountered odd bugs which a human would not have introduced, while forgetting about all the bugs caught which humans introduced. Or their opinion is formed by models from six months ago.
Try out Opus 5.5 on high. It’s shockingly good. Of course if you’re trying to one-shot a sprawling application with load balanced distributed DBs, you’re going to have a bad time. For small, defined features, it’s pretty fucking great.
We use LLMs extensively on the projects I work in. We don't "vibe code", and we understand every commit.
They're definitely a useful additional tool for finding more (and more obscure) bugs, but that takes a lot of both human and compute effort too, and after the reports are clean you still can't be 100% sure (but at least a bit more confident) that the code is now free of bugs.
I'm not super sure about that. But if its going to exist I'm crossing my fingers it works to the OSS community benefits (eventually)
That may be true. Serious question though: even if most devs wanted to develop formally verified code, do you think that it is reasonable to suggest that the typical systems developer could do it with today's tools? I don't mean verified protocols (TLA+) or verified algorithms (SPIN) I mean end-to-end verified code, a-la seL4. I got the impression that this is still very specialised work. Perhaps things have advanced since I last checked.
Want to merge the PR? I need verified sign off in ServiceNow by staff level engineer. They are on vacation for 2 weeks? Did manager fill out delegation paperwork in ServiceNow with VP sign off? Oh they did but they forgot to put in return date AND time. Form needs to be corrected and reapproved before we can go into ServiceNow and make changes.
As it evolves I suspect there will be a push to verify more components of the stack. Once the capabilities layer can be verified, verification of most other components and drivers would become much less urgent.
That’s what I did with Safebox: https://safebots.ai/about/infrastructure.html
It was "load bearing" just fine....
Anything is "fragile" if you put a bulldozer over it....
We knew that for long time, there are countless meme about it, smart people protected their asses from it or exploited those.
I recently asked it to review my code and configs from the security perspective. Wow! 90% of the things it identified were MY bad decisions dating from pre-AI development. I am honestly humbled and impressed at the same time.
AI can create slop, and it can create quality products. It depends who is using it, and how.
In this case, what matters most is that the AI security review raised real issues that needed to be fixed. That is valuable.
And, of course, there are piles of legacy corporate spaghetti entangled in incomprehensible mess everywhere you look at. And this shit still runs, this precious hand-carved hand-weaved mess of bad decisions. I can't wait for LLMs to rewrite most of it.
It is plausible to assume that, for instance, a Linux kernel that was hardened for CVEs that Sonnet 3.5 could detect is not hardened for bugs that Sonnet 4.5, 5.5, Opus, Fable, and models in 2027 can and will be able to detect.
Hence, it is rather a constant catch-up game until the LLM improvements might hit a ceiling and won't get any better in this regard.
Like, "4x as powerful as a team of engineers" is still really quite impressive
In my hobby projects I use LLMs in my development workflow mainly for passive bug scanning, reviewing and helping to maintain tests, they are definitely useful for catching some bugs early and noticing unhandled edge cases, but they're also definitely no silver bullet (they sometimes ignore quite obvious bugs. and the fewer 'actual' bugs remain, the more one has to be careful about false positives). E.g. the funny thing is that now I'm actually slower than before due to the intense 'rubber ducking' with LLMs, but I still want to pretend that the resulting code is more robust out of the door.
Eg everything that Greg KH says in the video sounds very familiar, and it's very disappointing that Mythos still suffers from the same issues (or maybe even worse) as older models.
Okay, but again, even with all that extra effort, they found 4x as many bugs, so it seems like the effort is clearly worth it.
And each model gets more reliable, we get better at building proper reproduction code, etc. - this was mostly a comment about the cycle, direction, and velocity we should expect from the future, given this has already happened twice.
I'm not ready to take any bets when exactly the curve will be flat though ;) (e.g. in a just couple of months or a couple of years)
The result will be an overall increase in turbulence and the normalization of steadily intensifying security crises in nearly all software systems.
The only projects that will escape this fate are those which have either been already developed from ground up with rigorous and principled, verified (or verifiable) design, or those which are rewritten to gain this.
this is a good outcome. A forcing function to encourage all computing to be more secure can only be good in the long term, even if there's a lot of pain in the short term.
why not? Any system you have permission to use and store your data should be beneficial to you if it became more secure. Unless...of course if you're the one who desires unauthorized access.
I wonder what “a lot of pain” could mean here in a world where Crowdstrike is allowed to render half of the world unbootable without repercussions.
Not that I think you are wrong, I am sometimes just confused why we hold back on fixing security because of imaginary deployment- and business-related pains, when it is so obviously unproblematic to crash half the world for a day?
...for human code.
In the small startup I work for boss (ex-programmer) discovered fable, and ai-coded 15K lines . So much productivity! So great! He even asked multiple reviews and it was fine!
I ask it a couple of reviews and it finds only minor things. The code is a mess of duplication and different coding styles, so I start cleaning it up. After a couple of months the reviews (same ai model) start actually finding big logic bugs that were always there.
We might already be at the point where the Ai-Coder is generating stuff that ai-reviewer can't find and will automatically pass.
--
1M context window is what? 70-80k LOC, tops? Without comments or documentation?
That is a smallish project of a couple of components. AI will remain inherently myopic until it can keep in context whole codebases.
Exposing current problems is fine to me, but I am worried of how brittle AI code will be.
It's not that difficult to build secure (web) applications but it takes effort and knowledge to get it right. You can't expect a web designer who can barely code in JavaScript to build a secure back-end, configure and maintain it. That's just asking for trouble.
Even high-value sites are built by cheap laborers these days. LLMs (I refuse to call it A.I.) will expose their weaknesses within minutes.
Should I now expect to find even more places to seal up the next time I break out the FLIR?
Or you could categorize the current bug apocalypse under the heading "unsustainable trends will not be sustained."
But in software, especially with agents, we're constantly renovating the house. If you were renovating every 6 months I'd expect to find more places to seal up, even if you were following best practices in those remodels.
That being said, I do think we will reach an equilibrium where most vulnerabilities are found at PR time.