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.
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
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:
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)
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.
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 method of assigning CVEs hasn't changed, but the number of CVEs has risen sharply.
A lot of these bug reports are incorrectly filed. Let’s look at one issue:
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)
At this point, I'm mildly surprised when it seems like a human wrote the article.
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.