Contents
Linux Services & Systems
Domains, hosting, PEC, email infrastructure, network services and Linux systems. Open Source infrastructure support and management.
Discover →
Cybersecurity
CISO-as-a-service consulting: posture, remediation roadmap, ongoing support.
Discover →
CyberAgent
Continuous vulnerability assessment and gap analysis: scanning, mapping onto framework requirements, documented evidence ready to hand over.
Discover CyberAgent →
What happened on 19 and 20 July
On Sunday 19 and Monday 20 July the linux-cve-announce list poured out 432 CVE identifiers in a little over twenty-four hours. Some trackers, counting the following day’s additions too, reach 440. The entries span most of the subsystems: networking, Bluetooth, storage, memory management, virtualisation, graphics, wireless, device drivers, filesystems.
nixCraft flagged it first, on Monday morning. On Tuesday 21 sysadmin Jan Schaumann opened a thread on the oss-security mailing list with a blunt argument: “this onslaught really shows it’s not feasible to attempt to prioritize individual kernel changes”. He lined up the realistic options and dismissed them one by one: use an LLM to prioritise against your own environment (but the CVEs keep coming), wait for a vulnerability to earn a logo and a catchy name before moving, or update everything weekly across the whole fleet.
Greg Kroah-Hartman replied on Wednesday 22. First, on the substance: this was not a wave of new vulnerabilities, it was a public review queue cleared in bulk after “a perfect storm of 6 weeks straight of conferences and vacations”. Second, on the outlook: “The number of llm-found issues is only on the rise right now, it’s going to be a very long 18 months at the least to dig ourselves out of this mess”.
Why the kernel produces so many CVEs
Since February 2024 the project has been its own CNA, assigning its identifiers itself. The stated policy is deliberately cautious: at the level the kernel runs, almost any bug affecting a running system can be exploited to compromise it, so the team assigns a CVE to every fix that lands in stable and meets the CVE Program’s definition of a vulnerability.
The result is arithmetic. In 2024 the kernel published 4,325 CVEs, third largest CNA in the world by volume. In 2025 it moved to first place, at a pace of roughly fifty CVEs a week. That is the baseline, and a queue cleared in forty-eight hours is simply its most visible form.
The same month, Microsoft and Oracle
On 14 July Microsoft closed a Patch Tuesday covering 570 vulnerabilities, around sixty rated critical and three zero-days, two of them already exploited in attacks. That is almost triple the previous month, which was itself a record. The company attributed the jump explicitly: “The pace of vulnerability discovery is changing with advances in AI making it possible to find more issues, faster, across more code”, said Pavan Davuluri, executive vice president. Third-party tallies that also include CVEs from external components, Chromium above all, run past 620: the figure moves with the counting method, the order of magnitude does not.
On 21 July Oracle published the largest Critical Patch Update in its history: 1,449 patches for 1,235 unique CVEs, 261 of them critical, spread across hundreds of products. The heaviest concentrations are in E-Business Suite (410 patches), Fusion Middleware (355) and Communications (168).
For contrast, in the same month SAP released sixteen new security notes and the Android bulletin covered fifty-seven vulnerabilities. The difference is not in how rigorous the teams are: it is in how much code there is and how many automated tools are combing through it.
The shared driver
On 17 May 2026, in the Linux 7.1-rc4 announcement, Linus Torvalds called the kernel’s private security mailing list “almost entirely unmanageable”. The numbers tell the story: from two or three reports a week two years earlier to five to ten a day, with different researchers running the same AI tools, finding the same bugs at the same time and reporting them in parallel, sometimes for issues fixed months ago. The countermeasure is procedural: a bug found with AI tooling should be treated as a public disclosure and sent straight to the subsystem maintainers, not to the private list.
It is worth noting what Kroah-Hartman does not say. He does not call it slop: back in March he observed that the quality of AI-assisted reports had risen considerably in recent months. The problem is not the quality of the reports, it is their number.
In June FIRST revised its forecast for the year upward: roughly 66,000 CVEs in 2026, after actual disclosures ran more than 45% above the initial projections. In its 15 June note the organisation points to the latest generation of vulnerability-hunting agents as a driver, naming Anthropic’s Mythos and OpenAI’s GPT-5.4-Cyber. These are the same tools that, on the other side of the table, have already carried out an autonomous intrusion.
Downstream, the NVD has already stopped analysing them all
On 15 April 2026 NIST announced that the National Vulnerability Database will no longer enrich every CVE. Severity scores, affected products and CPEs now go to three categories: CVEs in CISA’s KEV catalogue, within one business day; those affecting software used by the federal government; those covering critical software under Executive Order 14028. Everything else falls into lowest priority: it stays in the database and stays indexed, without analysis, with enrichment available on request by email.
The numbers behind the decision are the ones seen so far. In 2025 the NVD enriched nearly 42,000 CVEs, 45% more than any previous year. Submissions grew 263% between 2020 and 2025. The first quarter of 2026 came in about a third above the same period the year before. Roughly 29,000 backlogged CVEs dated before 1 March 2026 were moved to Not Scheduled.
For anyone who built their vulnerability management process on severity and affected products read from the NVD, this is operationally the heaviest of the three pieces of news.
The kernel’s answer: always update
Kroah-Hartman’s position has been consistent for years and came back sharp in the thread: update. “This is what the kernel developer community recommends and supports. If you want support from us, do this. If you can’t do this, then pay a company to provide the needed support.”
The more interesting passage is elsewhere. On hand-picking which patches to apply, Kroah-Hartman writes that “this is going to be legislated away, and rightfully so”, with an explicit reference to the Cyber Resilience Act. In plain terms: choosing at your discretion which fixes to install is about to become, in Europe, a compliance matter. The dates are known and close, the CRA reporting obligations apply from 11 September 2026 while SBOM and essential requirements arrive on 11 December 2027.
He closes by quoting Halvar Flake: “Software was never designed for perfect security, that choice is now catching up with us.”
What changes for anyone running systems
The number of open CVEs has stopped being a useful measure of risk, and the individual CVE has stopped being a sensible unit of triage. Four practical consequences.
1. Continuous updating becomes the default. On a Linux estate that means the distribution’s stable or LTS kernel, planned reboot windows and livepatch where downtime is expensive. At these volumes per-CVE triage costs more than the deployment, and that arithmetic now does itself.
2. You need to know what is actually running. Without an inventory, the question “are we exposed?” has no answer at any speed. This is why SBOM and provenance move from good practice to infrastructure: the CRA will make them mandatory, but you need them earlier, to answer within hours when a dependency really is exploited.
3. Priority shifts from severity to exploitability. With the NVD enriching only part of the flow, the useful signal comes from the KEV catalogue, from EPSS and from reachability analysis: does that CVE touch a function your code actually calls, on a machine that actually exposes that service? It is the material that scanners such as Trivy prepare, and that someone still has to interpret.
4. Exceptions have to be written down. Where a reboot is not possible, the deviation needs a documented rationale, a compensating mitigation and an expiry date. Between NIS2 and the CRA, “we didn’t update” without a register is a hard position to defend in front of a regulator.
What we think
The new thing about July is not that the Linux kernel has many vulnerabilities: it always has, and Copy Fail showed in April that the most interesting ones stay in circulation for years before anyone looks at them with the right eyes. The new thing is that the capacity to find them has grown by an order of magnitude in eighteen months, while the capacity to read, classify and distribute them has stayed where it was. The bottleneck has moved from discovery to consumption, and the NVD giving up on universal enrichment is the first institution to certify it.
For anyone running infrastructure the consequence is concrete and, in the end, freeing: stop treating the CVE list as a work queue. The real queue is a different one, and it has three items. An estate kept continuously up to date, which is the job our Linux services and systems team does, where the value sits in maintenance windows and rehearsed rollbacks rather than in reading 432 changelogs. An inventory that holds up when the question is asked in a hurry. An exception process that produces paper, because in twelve months someone will ask for it.
On that last point CyberAgent does the repetitive technical work: continuous scanning, mapping vulnerabilities onto framework requirements, reproducible documented evidence. As we have already written about NIS2, it does not produce automatic compliance and it does not decide for you which exceptions to accept: it cuts the manual work and makes the part you have to demonstrate repeatable. Deciding what to update and when stays a risk choice, and a person has to sign it.
There is a final, systemic point. The CVE Program and the NVD are public infrastructure the entire security industry rests on, and they are showing their limits under a load nobody anticipated when they were designed. It is the same pattern we see elsewhere: tools built for one order of magnitude find themselves carrying another. It holds for vulnerability triage, it holds for maintainer mailing lists, and it holds for the customer security teams asking us to make sense of a feed that in 2026 will run to sixty-six thousand entries.
Sources
- oss-security: 432 Linux kernel CVEs, Jan Schaumann’s opening message
- oss-security: Greg Kroah-Hartman’s reply
- The Register: Linux kernel team publishes 432 CVEs in two days
- The Register: Torvalds on the kernel security mailing list
- LWN: the kernel becomes its own CNA
- LWN: how kernel CVE numbers are assigned
- Krebs on Security: Microsoft patches a record 570 security flaws
- Oracle Critical Patch Update Advisory, July 2026
- NIST: NVD updates operations to address record CVE growth
- Help Net Security: the FIRST forecast for 2026
- Red Hot Cyber: Linux developers published 432 CVEs in two days