432 Flaws in 31 Hours. 3 People Filed Them. Missing One Costs Millions.

Four in ten arrive with no severity score at all. The people who wrote them cannot say which ones reach your product. In September that becomes your problem.

Photo by Kelly Sikkema on Unsplash

The security feeds filled with the same number over and over between Sunday morning and Monday afternoon, July 19 and 20, 2026. 432 new security flaws, all in the same piece of software. One every four minutes, for 31 hours.

One of the people watching is an infrastructure security architect who also teaches graduate students how to run and defend large systems.

He looked at the number, wrote a brief public note, and ended it with: “I’m not sure what to do here going forward.” He has no answer. Every company shipping a Linux device still has to read those same 432 records and decide which of the flaws can hurt the products it sells, on top of the regular week’s work.

A European law will take effect on September 11, 2026. From that morning, the moment one of those flaws comes under attack, the manufacturer selling the device has 24 hours to notify the authorities, and there is no reliable way to know which flaw it will be.

And there is more of that…

Just Reading is One Engineer’s Week

His name is Jan Schaumann, who calls himself an accidental infrastructure security architect. Graduate students at Stevens Institute of Technology take his classes in System Administration and Advanced Programming in the UNIX Environment.

He wrote to the oss-security mailing list on July 21, 2026: “the Linux kernel published 432 CVEs between 2026–07–19T09:09 and 2026–07–20T16:27 (in addition to the >40 other CVEs already published this month alone).”

CVE stands for Common Vulnerabilities and Exposures, the global ID number stamped on a software security flaw so the whole industry can track it.

He went through three ways to cope, none of which convinced him: point an AI model at the intake and ask it to prioritize for your environment, wait until a flaw earns a marketing name before reacting, or blanket-patch every machine every week regardless of risk.

He even conceded the ground under his own feet: “I understand the position that CVEs were always a flawed way to track or prioritize security changes, and ‘but it’s the only thing we have’ isn’t a great argument in favor.”

I have spent a good part of twenty years on the other side of that feed. We had a Monday morning ritual on the fourteen compliant platforms I helped architect. Someone opened the vulnerability scanner, stared at a wall of fresh entries, and started guessing which ones could actually hurt us.

That was a few dozen a week… Give each of Schaumann’s 432 records five minutes, which is extremely fast for a kernel patch, and reading them takes thirty-six hours. That is one engineer’s nearly entire workweek in Europe, not counting the fact that the majority of them have day-to-day jobs.

So which one gets read first? If you miss the one that ends up under attack, the fine runs to eight figures.

4 in 10 With No Severity Score

The people outside of the Linux kernel wrote its security tickets for the first three decades. Researchers, distributors, and MITRE filed them, often on bugs the maintainers considered misjudged and could not veto.

CVE numbers “were very often assigned in inappropriate ways and for inappropriate reasons,” the kernel documentation says, and “ongoing abuses by individuals and companies outside of the kernel community” convinced the developers to take over.

The kernel became a CNA in February 2024, covering every kernel version on kernel.org that is still in support. Greg Kroah-Hartman, Sasha Levin, and Lee Jones run the assignment team.

A CVE is the number assigned to a single flaw; a CNA, or CVE Numbering Authority, is an office that the CVE Program authorizes to issue them.

The assignment team issues a number once a fix reaches a stable release, without waiting for proof the bug can be attacked. Almost any kernel bug might be exploitable, the documentation says, and “the possibility of exploitation is often not evident when the bug is fixed.” So the team “is overly cautious and assign CVE numbers to any bugfix that they identify.”

Lee Jones addressed the automation effort publicly in June 2024: “The Linux CNA Team does not take the process of allocating CVE numbers lightly and the process is not automated.”

No record says whether the flaw reaches your product. The same kernel bug is harmless on a locked-down server, and a root exploit on a cheap router. The people writing the code cannot dictate how anyone uses it, Kroah-Hartman says. About 4 in 10 records in the July batch had no score.

The count went from 4,325 in 2024, its first year assigning its own numbers, to more records against it in 2025 than any other product in the world, with 720 on one day that February. The first half of 2026 came to 2,308 records naming Linux as the affected vendor, more than Microsoft, Oracle, Adobe, and Apple combined, and more than Google alone.

“I gotta change my talk where I say ‘we are #2’ as that’s not the case by far anymore,” Kroah-Hartman wrote.

Kroah-Hartman, Levin, and Jones will file the same way next week, and the week after that. One vulnerability researcher says the problem was foretold in 2022, two years before they took the job.

Both Machines Get the Same Alert Anyway

The people on the receiving end have been objecting since the kernel became a CNA.

Brian Martin, a vulnerability-database veteran who writes as “jericho,” has flagged the kernel CNA and traces his red flags to 2022. Assigning IDs to every bugfix, he argues, “drowns blue teams” and “wastes their valuable time,” because “these are assignments, not always vulnerabilities.”

Security work splits into two sides, named after the colors used in military exercises. The red team plays the attacker, breaking into its own employer’s systems to show where the holes are before a stranger does. The blue team defends, and the alert queue is its day: read whatever arrived overnight, work out which entries are real, patch or escalate the ones that are, and get to the end of the list before something on it gets used.

The CVE system was built for discrete products with clear boundaries, and the kernel has none of those.

The same kernel runs inside thousands of different products. A bug in the Bluetooth code is a way into a smart door lock and is dead weight on a server with no Bluetooth radio. One severity number cannot be true for both machines, so the record arrives without a number that fits either. Both machines get the same alert anyway.

The average behind the bursts is 12 to 13 new kernel CVEs a day, drawn from the 2,308 logged against the kernel in the first six months of this year. You learn whether any of them touches the product you sell by reading the patch yourself, or by watching an attacker use it first.

Clap if you have guessed your way down a list like this, comment with the one you nearly missed, and share this with whoever opens the scanner Monday.

Missing one of those records costs you nothing today. A European regulation changes that on September 11.

September 11 Starts the Clock

The EU Cyber Resilience Act (Regulation 2024/2847), the CRA for short, entered into force on December 10, 2024. Its reporting rules under Article 14 start applying on September 11, 2026, seven weeks from the day I am writing this. Manufacturers must then report actively exploited vulnerabilities and severe incidents in products with digital elements.

The clock starts the moment a manufacturer “becomes aware.” For an actively exploited vulnerability, the manufacturer owes an early warning to the authorities within 24 hours, a full notification within 72 hours, and a final report within 14 days once a fix or mitigation exists. A severe incident runs on the same 24- and 72-hour clocks, with one month for the final report. Everything routes through one platform to the coordinating CSIRT, the national Computer Security Incident Response Team, and to ENISA, the European Union Agency for Cybersecurity.

If you miss those deadlines, Article 64 sets the penalty at up to 15 million euros, or 2.5 percent of total worldwide annual turnover, whichever is higher. Microenterprises and small enterprises are exempt from the fine for failing to meet the 24-hour deadline.

Credit: Author, The EU Cyber Resilience Act Reporting Clock for an Actively Exploited Vulnerability

When we look at the details of the regulation, we see that it places the burden on manufacturers. Open source stewards are explicitly not on the hook for penalties. The obligation, the SBOM (the Software Bill of Materials listing the components of a product), vulnerability handling, the 24-hour and 72-hour clocks, and the fines fall on the commercial manufacturer that places a product containing the kernel on the EU market. Article 24 gives stewards a narrower reporting duty of their own, and no fines.

So every company selling a router, a smart door lock, a security camera, or an industrial controller running embedded Linux owes that 24-hour report from September 11.

The repair work still has to happen, and the regulation is somewhat specific about it. Article 13(6) requires a manufacturer that discovers a vulnerability in an open source component to report it to the component’s maintainer. If the manufacturer builds a fix, it “shall share the relevant code or documentation” with that maintainer, in machine-readable form where appropriate.

Thousands of companies take on that duty on September 11. The maintainer on the other end is free to ignore it all.

The technical gateway of the Linux kernel is not something that you can just play around with on the weekend with an AI-assisted coding tool. I recently wrote about it:

[embed]A Trillion-dollar Company. 16 Months. Linux’s Technical Gateway. 16 months of flawless work. A real security hole closed. A board seat, a founding role, an ally inside the kernel. Then…canartuc.medium.com

Open source maintenance is already short on people and money. I have written that dozens of times before, and I have not changed my mind. Maintainers reject patches every day, often for good reasons, and a patch written to close out a European reporting deadline is not automatically a patch a subsystem wants. Even if it is a good one, someone still has to review it, test it, and carry it for years, and that someone is the volunteer who is already behind.

The regulation says nothing about that side of the exchange. I am not a lawyer; this is what I read from the regulation, and it feels that authorities have no clue how open source works. Again…

The Panic

Kroah-Hartman saw this collision coming.

The kernel became a CNA in February 2024 with his help, and he has published the running counts himself. He also took the European law to the developers around him, and he told them in Paris in September 2025: “So don’t be afraid of the CRA. These are things you should be doing anyway.”

“Manufacturers are going to care in September of next year,” he said. “They’re going to start panicking in the summer of next year, and things are going to start hitting the fan.”

He said that in September 2025, and the summer he pointed at is the one running right now.

Schaumann’s note is the panic arriving this week, exactly on the schedule Kroah-Hartman predicted.

Schaumann is right that the flood is unmanageable for a normal security team. Kroah-Hartman is right that hiding bugs to keep the count low would be worse, and that no manufacturer pays his team to sort through the flood.

The law does not care which one is right.

Watch the Faces When You Ask

The deadline was set in Brussels, and it lands in your office because the kernel is already running there, whether or not anyone on your team put it there.

If your company sells anything with a network port and a Linux kernel behind it, and most hardware companies do, your reporting clock starts on September 11 too. The kernel team will not triage those 2,308 flaws for you, rank them for your product, or sign your attestation. That work became yours in February 2024, when the kernel started issuing its own CVE numbers, and from September 11, 2026, it will carry a penalty for you.

What I can suggest now is that you open the linux-cve-announce archive, the public list Schaumann pointed at, and count what has landed since Friday against the kernel version your product ships. Then ask whoever owns that version how many of them anyone on your side has read. If you see blank faces, it means you have been sucking the blood of open source for free until now, and this blood will make you sick after September 11, 2026.

Schaumann’s post ended without an answer. The queue did not stop to wait for one to resolve.

The clock starts counting on September 11 anyway, and I wish you good luck.

1. Jan Schaumann, “432 Linux kernel CVEs,” oss-security mailing list, July 21, 2026. https://www.openwall.com/lists/oss-security/2026/07/21/8
2. Regulation (EU) 2024/2847 (Cyber Resilience Act), full text. https://eur-lex.europa.eu/eli/reg/2024/2847/oj
3. Brian Martin (“jericho”), “The Linux CNA: Red Flags Since 2022,” jericho.blog, February 26, 2024. https://jericho.blog/2024/02/26/the-linux-cna-red-flags-since-2022/