Tautologically every bug can legitimately be assigned a CVE, since every bug prevents some feature from working as intended. It's therefore a denial of service, which by the definition of the CVE system using CVSS means every bug is at least a 1/Low level vulnerability to CVSS v4.0.

If you're willing to stretch, missing but planned features also deny the use of said features since they haven't been added yet, and so are CVSS 1/Low vulnerabilities.

Resume-driven development for security researchers has never been easier!

> _any_ bugfix is assigned a cve

Any patch that is back ported to a stable kernel, indiscriminately. 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 (which is in this list), 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 gets corrupted, the buggy code path in the recovery (CVE-2026-89558) is effectively triggered over the network.

> note that _any_ bugfix is assigned a cve

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.

With particular emphasis on "almost any bug might be exploitable".

> Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify.

Er what?? CVEs should be assigned to bugs, not bugfixes, right?

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).

> 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.

Does this also mean the code generated and reviewed by LLMs will not have such issues going forward?

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

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.

Good thing we can patch those issues up and have an ironclad system afterwards.

Who said those vulnerabilities were found by an LLM?

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.

in theory, it could be the best thing that ever happened to open source.

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)

Broadcast, not expose.

We knew that for long time, there are countless meme about it, smart people protected their asses from it or exploited those.

> fragile the entire computing infrastructure in our world is.

It was "load bearing" just fine....

Anything is "fragile" if you put a bulldozer over it....

Instead of patching millions of environments, perhaps it’s better to just build a secure one from scratch?

That’s what I did with Safebox: https://safebots.ai/about/infrastructure.html

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.

Yeah it’s a great video (TLDR from the video)

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.

500 CVEs per release to 2000+

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.

Excellent plug and recommendation!

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.

Even before AI we have known that no one is smart enough to write bug free C. And with every bug being a launch platform for a full exploit it's become a big deal.

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

Do we know the code behind these vulnerabilities were written by AI? It seems like if anything AI was used to find exisitng vulnerabilities that would otherwise be used/sold as zero days and go unreported.

It was always the case that finding vulnerabilities in software was easier than writting perfect software. I'm hopeful that we can use AI to make software more secure over time. Project Zero [1] and others has shown many times the past few years (pre LLMs) that automated fuzzing and other forms of dynamic analysis are very effective, which bodes well for automated testing via LLMs!

I agree that more code = more bugs overeall, but there are slow moving codebases that run some of the worlds most valuable software. Seems like using AI to find vulnerabilities in that code is a huge win across the board.

[1]: https://www.google.com/search?q=site%3Aprojectzero.google&q=...

> AIs when writing code introduce vulnerabilities at a rate similar to humans writing the same code.

AI regurgitating all the insecure code AI companies scraped from stack overflow and github isn't going to give you something too different from what the humans who put it there in the first place came up with. Garbage in, garbage with random hallucinations out.

I guess trash in trash out also applies to the training of an LLM.

It doesn’t follow. Everyone sane has the models review the choose the models wrote. Reminder these are the models which found the Jacobian and Navier-Stokes counterexamples; they’ll find holes in their own slop, too.

> security has a cost associated with it, and unless there are _real_ consequences, it's a cost that most software houses ain't gon' pay.

Good to see someone say this. Software need only be good enough to do the job, and only as safe as reasonably required. Systems can be secured and audited through other means, sometimes at lower expense than guaranteeing every line of software has zero risk associated.

Long term we will end up with software with no low hanging fruit exploits left. But right now we are in a period where low hanging fruit is everywhere and it's easier to exploit systems than ever before.

If they were bugs of consequence you could expect each one to get it's own domain with a scary name and a logo.

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.

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.

this only really works for libraries, and not much else. especially not a kernel.

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.

I believe they call it semantic versioning (SemVer).

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…”

Is that all there is here? The quantifier "several" did not prepare me for the wall of CVE numbers in this list.

Yes. It looks funny, but it's a nothing burger.

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.

By late summer this year more software/code was produced than in all of 2025

Yes, naturally. It’s a brave new world.

GNU Hurd shall rise!

> Car makers are switching to QNX even though it costs them money.

My car runs QNX for its infotainment/navi system but I had the impression that manufacturers were, sadly, moving away from QNX?

You cannot possibly compare embedded/single-purpose systems to a general-purpose OS that is expected to run arbitrary user-written software performantly on thousands of different hardware combinations.

Alternatively, we could benefit from security through compartmentalization. Qubes OS runs everything in VMs, and there were two VM escapes in the last 20 years [0]. A dedicated VM for your email doesn't allow any attacker to compromise it, since you do not run anything else in it.

[0] https://forum.qubes-os.org/t/qsb-116-multiple-xen-issues-xsa...

>Weren't there rumours that intelligence agencies have been using microkernel operating systems for decades?

Governments, military, aviation, space.

For a good portion of the usage, the people involved cannot even talk about it. But sometimes it's possible. A surprising amount of real world use showed up in talks in seL4 summit 2026[0].

0. https://www.youtube.com/playlist?list=PLd7rrADYxxQQ

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.

Will everyone chill the F out for a minute?

These get released every few weeks. Tons of CVEs. If a kernel developer farts in the forest, does anyone hear it?

August saw 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.

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 :)

Why would coreboot be safe from AIs which solved Navier-Stokes

Clicking them here lists specific kernels, is that enough to tell you?

https://security-tracker.debian.org/tracker/source-package/l...

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".

Something to keep in mind is the Linux project registered as an authority to create their own CVE numbers in 2024. Previously the majority of bugs would just be fixed without note unless there was a demonstration that it could be exploited.

Now they just give almost every bug a CVE number.

In one the latest CCC kernel security talks, Ilya van Sprundel estimated 20.000 unfixed Linux bugs sitting around still. It's coming closer.

Any kernel bug gets a CVE even if it's not really a vulnerability or can be exploited

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 assume both? I'd be surprised to see a vulnerability fixed without first being discovered.

Seems like a reasonable assumption, but a pretty strong assertion. How could anyone possibly know?

History has proven that the microkernels are not necessarily more secure and have their own unique set of problems (see: macOS).

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 subsystems are backdoors, but if I were going to force companies to add one, it'd probably end up looking similar. The blackbox wireless chipsets in all our phones also come from a very small number of companies.

We're in an uneasy truce with regards to mandatory backdoors.

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.

Love the optimism.

> Don't post generated text or AI-edited text. HN is for conversation between humans.

https://news.ycombinator.com/newsguidelines.html

Did the non-deterministic computer program provide any references?