I think a tricky thing about these metrics is GitHub and the Linux Kernel became their own CNA in mid-2024[1] and mid-2025[2]. This caused a bunch of new automation and lowered barriers to actually filing a CVE.
As a small data point I have a >20k downloads Obsidian plugin and it got a CVE on a Beta release due to a bad pathing regex. I feel this would have never happened 2 years ago.
So, I feel the bar for a CVE being issued is WAYYYY lower in 2025+ than before.
Severities are not directly comparable. The CVSS docs leave the choice of the "vulnerable component" as an exercise for the reader. The choice of the "vulnerable component" is also not encoded in the score so a critical may be a critical in the context of a library scored against a theoretical (and bad) program or it could be scored on a single website with known mitigations.
It’s impressive that the number of CVEs issued the last two years has skyrocketed, given how badly DOGE gutted the cybersecurity [0] agencies. Unfortunately we don’t know how huge the backlog may have since grown
DOGE was impressively criminal. The team tried to remove the CVE reporting system entirely and only failed to do so because of intevention from the military and several agencies.
The CVE system is far, far from perfect and NIST has faced increasing criticism (even before 2025) about its ability to triage and process the backlog. But I don't think their role is limited to simply posting what’s sent to them?
Cool. This would be easier to interpret with a log scale. There's an option for it, but clicking it doesn't change the chart and freezes the site for me.
Others have pointed out that we thought we would get security vulnerability from AI code, but it turns out AI is uncovering vulnerabilities in decades of human code.
They aren't mutually exclusive. Wait until we find out intelligence services have been influencing the output of AI generated code for certain people/counties.
Is the point that you're making that it only found the vulnerabilities because they were in the training set, and therefore AI didn't really "find" them?
If so, I fear you're making the opposite point, which is that AI made genuinely new discoveries that were not in its training set, about codebases that were in its training set. It quite literally expanded the horizon of what we know.
Not the topic (the site is interesting), but a tangential rant.
I think the whole CVE/CVSS system is completely outdated, and it doesn't reflect the reality of software making for a while now (years). Also. for years, major software providers have been fighting to control their own release logs and security vulnerabilities. Recently, NIST stopped actually analyzing CVE's (one can relate to that), and the fact is that the system only makes sense as 1) vuln database; 2) in the context of responsible discosure; Responsible disclosure is from a non-AI era, where the time between a finding and a release woulds be measured in months, not weeks. Also, from a time where the probability of another human to stumble on that specific vulnerability was quite low. Pre-AI times.
Also, in April 2025 MITRE announced that fundings to the CVE/CWE program would expire, and it took a couple of days for the Trump administration to backpedal from that. We need a global system, not an american one - and clearly, americans should not be in charge of these global programs, as there is no way to isolate the world from their local politics. Their programs, their funding, nothing against it. I just think we, collectively, should have something a bit more robust, and while at it, do it on a quite more modern basis (EU CRA is actually a good start, as it includes SBOM and mandatory reporting).
CVE, CVSS, CPE seem all designed by comittee; CVSS and CPE are a flagrant case of that (try to apply CPE versioning to your own software, you'll get it); Its "what we have now" - there are alternatives, afaik but not that mainstream.
Everyone thinks that system is outdated. I don’t think we have any cybersecurity professionals claiming otherwise.
It is in use just because it already is there and to make something new will be tough.
I think we should drop the score entirely. Just give me details and I should be able to make my risk management based on if it is RCE is it local or just info disclosure etc.
Global scoring is something that feels right but in practice it is totally wrong. Biggest damage happens when management that doesn’t understand any of that wants to have excel sheets green.
IIRC the original purpose of CVE identifiers was purely identifiers, like IP addresses - they are assigned in blocks and the assignment of one doesn't say anything about what it points to. The government databases came a bit later.
I remember a comment somewhere, where employees of a company, would open a CVE for a piece that they use in their job, to force an upgrade of said software since normal update request has been denied despite having business reasons to do so. So, the number doesn't matter.
Also, the linux kernel assigns CVE for anything that can be though as a vulnerability:
> Note, 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, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team
12,000 CVEs? That doesn't match the data in the source at the bottom. I cloned it and for 2026 there are 79,764 CVE json files. I'm pretty sure I patched more than 12,000 CVEs for my RHEL systems this year. Also the site freezes for me as well when switching to logarithmic.
That's kind of where my careers been, it seems like sre has been rebranded infrastructure and platform engineering and there's not to much sre titled jobs. It's probably not to hard if you have demonstrated experience with the expected sre tools. If you happened to have made the unforgivable sin of not using k8s or terraform durring your career it sucks.
Looks like an exponential curve, the inflection point doesn’t seem to line up with either the introduction of AI, or AI’s inflection point. Yes, yes, lower your prompt box, Software Development Has Changed Forever In The AI Era, but this is just “CVEs got Goodharted”.
It has hit the point where I’ve told people reporting bugs with my software that I won’t acknowledge the bug unless they provide a patch to mitigate the issue.
A lot of these bug reports are incorrectly filed. Let’s look at one issue, which I am sure was found with AI assistance:
CVE-2026-40719
Here’s the issue: An IP authorized to perform recursive queries can cause the DNS server to be non-responsive if it sends hundreds of specially crafted packets a minute (this can be changed to millions of packets a minute if one sets a parameter in the configuration file). Normal service is restored within a minute of the attack being stopped. The workaround would require me to essentially rewrite the recursive part of the DNS server.
Since the DNS server, like any server in a LAN, is already vulnerable to a flooding attack, this is just a flooding attack with extra steps.
I told the guy that was interesting, I’m not being paid enough to rewrite the DNS server to be immune to the attack, and people shouldn’t be using its recursion (it has very limited IPv6 support, for starters), and if they do use its recursion, only authorized IPs (e.g. 127.0.0.1 or 192.168.1.0/24) should be allowed to perform recursion.
It wasn’t a serious enough attack to merit a patch, and anyway the guy reporting the bug didn’t even have the decent courtesy to give me a patch.
Point being, a lot of these CVE reports out there which supposedly are high impact bugs are trivial things like “someone can overload a server for about one minute if they send hundreds to thousands of specially crafted DOS packets”.
(Today, I got an issue which, as far as I can tell, looks to be a Linux kernel issue and not an issue with my code. I told him to show me how he would patch my code to “fix” the issue, but so far have gotten nothing but crickets)
“Forced” is a little strong. RedHat/Fedora filed a bug report, and I felt it was prudent to have a patch for them to use, even though I explained why they didn’t need to use the patch.
In case you didn't notice this is yet another LLM slop project, have a look at the sourcecode, it's your typical everything-in-one-file regurgitation with loads of very verbose, claudish comments...
what would help with this is to regulate and restrict frontier models from doing cyber work so that the good guys are defenceless against bad actors /s.
really disagree with western policy makers and ai company leaders on the path they are steering us, leaving us defenceless all for the sake of their obvious self serving attempts at regulatory capture.
I think a tricky thing about these metrics is GitHub and the Linux Kernel became their own CNA in mid-2024[1] and mid-2025[2]. This caused a bunch of new automation and lowered barriers to actually filing a CVE.
As a small data point I have a >20k downloads Obsidian plugin and it got a CVE on a Beta release due to a bad pathing regex. I feel this would have never happened 2 years ago.
So, I feel the bar for a CVE being issued is WAYYYY lower in 2025+ than before.
[1]: http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/
[2]: https://github.blog/security/vulnerability-research/how-to-r...
GitHub's been doing CVE requests since at least 2022
https://github.blog/security/vulnerability-research/removing...
This is a good point thanks for bringing it up. Will look to capture this nuance in some updates I'm making to the site
I was suspicious the absence of a severity filter was exaggerating the trend...
But then I found this:
https://craci.com/resources/CVE-publication-trends?sev=criti...
Trend for critical CVEs is actually worse, at roughly 25x that of 2020, compared to all CVEs which are roughly 5x compared to 2020.
Severities are not directly comparable. The CVSS docs leave the choice of the "vulnerable component" as an exercise for the reader. The choice of the "vulnerable component" is also not encoded in the score so a critical may be a critical in the context of a library scored against a theoretical (and bad) program or it could be scored on a single website with known mitigations.
I'll look to add some additional features to the site based on this feedback - thanks!
It’s impressive that the number of CVEs issued the last two years has skyrocketed, given how badly DOGE gutted the cybersecurity [0] agencies. Unfortunately we don’t know how huge the backlog may have since grown
[0] https://www.securityweek.com/mitre-signals-potential-cve-pro...
DOGE was impressively criminal. The team tried to remove the CVE reporting system entirely and only failed to do so because of intevention from the military and several agencies.
> DOGE was impressively criminal. The team tried to remove the CVE reporting system
Honest question: what would be the criminal purpose for that?
I think the argument would just be, “why should the government do this when someone else could be making money off it”
Sabotage the government to further the interests of their employer
State sponsored sabotage.
Watch the world burn.
Do the agencies do any research to find CVEs? Or do they run a mostly cacheable website where they simply get posted?
The CVE system is far, far from perfect and NIST has faced increasing criticism (even before 2025) about its ability to triage and process the backlog. But I don't think their role is limited to simply posting what’s sent to them?
https://www.securityweek.com/cve-and-nvd-a-weak-and-fracture...
They have nothing to do with the number is my point. They don't uncover anything.
"They"? MITRE runs cve.org under contract by CISA.
Cool. This would be easier to interpret with a log scale. There's an option for it, but clicking it doesn't change the chart and freezes the site for me.
Will fix - thanks for flagging
The irony of my vibe coded personal site going viral because the site I was using historically was down due to P2PShell...
https://x.com/0x_Osprey/status/2113152597767172346
Same
Others have pointed out that we thought we would get security vulnerability from AI code, but it turns out AI is uncovering vulnerabilities in decades of human code.
They aren't mutually exclusive. Wait until we find out intelligence services have been influencing the output of AI generated code for certain people/counties.
Already did. DeepSeek generates insecure code if you mention Tibet and underhanded code if you mention US DoD.
https://www.crowdstrike.com/en-us/blog/crowdstrike-researche...
Which it was trained on
Is the point that you're making that it only found the vulnerabilities because they were in the training set, and therefore AI didn't really "find" them?
If so, I fear you're making the opposite point, which is that AI made genuinely new discoveries that were not in its training set, about codebases that were in its training set. It quite literally expanded the horizon of what we know.
Neither, I'm trying to assert that AI generated code would follow the (flawed) pattern we encoded in it. I think they're great for cyber stuff
That assumes AI isn't used to review AI code. As it turns out that AI is great at finding vulnerabilities.
If it can find flaws in human generated code why not find flaws in self generated code as well?
Not the topic (the site is interesting), but a tangential rant.
I think the whole CVE/CVSS system is completely outdated, and it doesn't reflect the reality of software making for a while now (years). Also. for years, major software providers have been fighting to control their own release logs and security vulnerabilities. Recently, NIST stopped actually analyzing CVE's (one can relate to that), and the fact is that the system only makes sense as 1) vuln database; 2) in the context of responsible discosure; Responsible disclosure is from a non-AI era, where the time between a finding and a release woulds be measured in months, not weeks. Also, from a time where the probability of another human to stumble on that specific vulnerability was quite low. Pre-AI times.
Also, in April 2025 MITRE announced that fundings to the CVE/CWE program would expire, and it took a couple of days for the Trump administration to backpedal from that. We need a global system, not an american one - and clearly, americans should not be in charge of these global programs, as there is no way to isolate the world from their local politics. Their programs, their funding, nothing against it. I just think we, collectively, should have something a bit more robust, and while at it, do it on a quite more modern basis (EU CRA is actually a good start, as it includes SBOM and mandatory reporting).
CVE, CVSS, CPE seem all designed by comittee; CVSS and CPE are a flagrant case of that (try to apply CPE versioning to your own software, you'll get it); Its "what we have now" - there are alternatives, afaik but not that mainstream.
Everyone thinks that system is outdated. I don’t think we have any cybersecurity professionals claiming otherwise.
It is in use just because it already is there and to make something new will be tough.
I think we should drop the score entirely. Just give me details and I should be able to make my risk management based on if it is RCE is it local or just info disclosure etc.
Global scoring is something that feels right but in practice it is totally wrong. Biggest damage happens when management that doesn’t understand any of that wants to have excel sheets green.
IIRC the original purpose of CVE identifiers was purely identifiers, like IP addresses - they are assigned in blocks and the assignment of one doesn't say anything about what it points to. The government databases came a bit later.
I remember a comment somewhere, where employees of a company, would open a CVE for a piece that they use in their job, to force an upgrade of said software since normal update request has been denied despite having business reasons to do so. So, the number doesn't matter.
Also, the linux kernel assigns CVE for anything that can be though as a vulnerability:
> Note, 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, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team
In other words, the number is fake
> In other words, the number is fake
In other words, the method of assigning CVEs hasn't changed, but the number of CVEs has risen sharply.
That's false, the kernel rarely assigned CVEs, now it does assign them liberally. So, the method changed
Yes, and all of that changed in 2024 so fairly recently: http://www.kroah.com/log/blog/2024/02/13/linux-is-a-cna/
The actual number needs to be interpreted carefully but the change is certainly real.
I prefer the tornado
https://rogolabs.net/tornado/
I'll look to add this as a mode on the site as well and credit the original. It's a great, unique visualization!
Thanks for this. I’m going to send it on our #general on Slack so people might understand when I say I’m a “bit” busy at the moment…
I am more interested in the long term trend. Do we burn through the low hanging fruit at some point or is this the new normal?
The Shigure mode cracked me up
Thanks - we all need a good laugh right now given everything happening...
You'll sleep easier if you think of the graph label as "vulnerability removals"
CVE moonshot and no one is getter paid. How very 2026.
12,000 CVEs? That doesn't match the data in the source at the bottom. I cloned it and for 2026 there are 79,764 CVE json files. I'm pretty sure I patched more than 12,000 CVEs for my RHEL systems this year. Also the site freezes for me as well when switching to logarithmic.
12,000 per month
This is what AI companies meant by embracing the exponential?
Are folks finding it relatively easier to get SRE positions now? Demand ought to be up.
I think SRE is a solid career pivot right now, especially if you have an overlapping skill set like mechanical/electrical engineering.
That's kind of where my careers been, it seems like sre has been rebranded infrastructure and platform engineering and there's not to much sre titled jobs. It's probably not to hard if you have demonstrated experience with the expected sre tools. If you happened to have made the unforgivable sin of not using k8s or terraform durring your career it sucks.
Avalanche on Mount Tech Debt?
Looks like an exponential curve, the inflection point doesn’t seem to line up with either the introduction of AI, or AI’s inflection point. Yes, yes, lower your prompt box, Software Development Has Changed Forever In The AI Era, but this is just “CVEs got Goodharted”.
It has hit the point where I’ve told people reporting bugs with my software that I won’t acknowledge the bug unless they provide a patch to mitigate the issue.
A lot of these bug reports are incorrectly filed. Let’s look at one issue, which I am sure was found with AI assistance:
CVE-2026-40719
Here’s the issue: An IP authorized to perform recursive queries can cause the DNS server to be non-responsive if it sends hundreds of specially crafted packets a minute (this can be changed to millions of packets a minute if one sets a parameter in the configuration file). Normal service is restored within a minute of the attack being stopped. The workaround would require me to essentially rewrite the recursive part of the DNS server.
Since the DNS server, like any server in a LAN, is already vulnerable to a flooding attack, this is just a flooding attack with extra steps.
I told the guy that was interesting, I’m not being paid enough to rewrite the DNS server to be immune to the attack, and people shouldn’t be using its recursion (it has very limited IPv6 support, for starters), and if they do use its recursion, only authorized IPs (e.g. 127.0.0.1 or 192.168.1.0/24) should be allowed to perform recursion.
It wasn’t a serious enough attack to merit a patch, and anyway the guy reporting the bug didn’t even have the decent courtesy to give me a patch.
The guy responded by filing for a CVE report, incorrectly calling it a “high impact” bug, and I had to make a “patch” which simply disables recursion: https://samboy.github.io/MaraDNS/patches/MaraDNS-CVE-2026-40...
Point being, a lot of these CVE reports out there which supposedly are high impact bugs are trivial things like “someone can overload a server for about one minute if they send hundreds to thousands of specially crafted DOS packets”.
(Today, I got an issue which, as far as I can tell, looks to be a Linux kernel issue and not an issue with my code. I told him to show me how he would patch my code to “fix” the issue, but so far have gotten nothing but crickets)
Who forced you to make the patch instead of just leaving the CVE open forever?
“Forced” is a little strong. RedHat/Fedora filed a bug report, and I felt it was prudent to have a patch for them to use, even though I explained why they didn’t need to use the patch.
In case you didn't notice this is yet another LLM slop project, have a look at the sourcecode, it's your typical everything-in-one-file regurgitation with loads of very verbose, claudish comments...
It's software posted on hacker news. I'd be shocked if it wasn't absolutely slop.
At this point, I'm mildly surprised when it seems like a human wrote the article.
And those get downvoted. This site should adopt some filters for people that dont want to just talk about AI everyday.
Someone shared unslop.news and it kinda works but I forget it exists.
They're still almost every software story on the front page.
what would help with this is to regulate and restrict frontier models from doing cyber work so that the good guys are defenceless against bad actors /s.
really disagree with western policy makers and ai company leaders on the path they are steering us, leaving us defenceless all for the sake of their obvious self serving attempts at regulatory capture.