If you run Debian 13 and opened the security advisory that landed on September 29, you probably scrolled for a while. DSA-6528-1, which moves the Trixie kernel to version 6.12.111-1, lists 1,313 CVE identifiers in a single update. Debian's own summary still calls them "several vulnerabilities," which has become a small joke among the people who read these things for a living.
The number made headlines this week, mostly as a single eye-popping figure. We wanted to know whether it was a one-off or part of a trend, so we went to the source. Debian keeps every security advisory it has ever issued in a public, machine-readable list in its security tracker repository, and we parsed every kernel advisory in it, then checked the results against the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog (the October 4 edition). The short version is that 1,313 is not a fluke, and it is also not 1,313 emergencies.
What Debian's own data shows
Start with the advisory itself. Of its 1,313 identifiers, 1,295 were assigned in 2026, 15 in 2025 and 3 in 2024, so this is overwhelmingly a batch of recent fixes rather than old debt finally being paid off. Debian had issued 17 kernel advisories for Trixie before this one, from August 2025 through August 2026, and together they listed 1,353 CVEs. The largest of those, in April, had 396. That means one September advisory carried almost as many identifiers (97%) as the previous 17 combined, and about 3.3 times the previous record.
Zoom out to every kernel advisory Debian has published, across all the releases it supports, and the shape of the problem gets clearer. These are unique CVE identifiers per calendar year:
| Year | Unique kernel CVEs in Debian security advisories |
|---|---|
| 2021 | 30 |
| 2022 | 137 |
| 2023 | 70 |
| 2024 | 783 |
| 2025 | 802 |
| 2026 (through Oct 6) | 2,648 |
Two caveats so you can read that table fairly. Debian also ships some kernel fixes through its regular point releases rather than security advisories, so this counts what went out as advisories, not every bug ever fixed. And the jump between 2023 and 2024 has a clear, non-AI explanation, which we'll get to in a second. Even with those caveats, 2026 is already more than three times last year's total with almost three months to go.
Why the count exploded, in two steps
The first step happened in February 2024, when the Linux kernel project became its own CVE Numbering Authority. Its official CVE documentation is unusually frank about how it works. Because almost any kernel bug could turn out to be exploitable, the team says it is "overly cautious and assign[s] CVE numbers to any bugfix that they identify." Identifiers are handed out automatically once a fix reaches a stable kernel tree. That policy alone explains the leap from 70 to 783.
The second step is the one everyone is arguing about, and it's the rise of AI-assisted bug hunting. Nobody has measured exactly how much of the 2026 surge it accounts for, and we haven't either, so treat this part as context rather than proof. But the people closest to the kernel have been describing the same pressure all year:
| When | What happened |
|---|---|
| Feb 2024 | The kernel project starts assigning its own CVEs to almost every identified bug fix. |
| May 2026 | Linus Torvalds says the flood of AI-found reports has made the kernel security list "almost entirely unmanageable," with many people finding the same bugs with the same tools. |
| Sep 23, 2026 | Canonical moves Ubuntu to overlapping two-week kernel update cycles, which means a new kernel every week, citing AI-driven bug discovery. |
| Sep 29, 2026 | Debian ships DSA-6528-1 with 1,313 CVEs. |
| Oct 1, 2026 | Google pauses part of its open-source bug bounty after a wave of mostly invalid automated reports. |
| Oct 3, 2026 | Kernel 6.12.112 arrives with a changelog of more than 27,000 lines, according to The Register. |
Put those together and you get a pipeline that is being fed far faster than before at the top (more bugs found, more fixes written) while the bottom (distributions testing and shipping kernels, admins rebooting machines) still moves at human speed. Debian's September advisory looks like what happens when a backlog from that pipeline gets released in one go.
How many of these are actually being exploited?
This is the number we think matters more than 1,313. We checked every identifier in DSA-6528-1 against CISA's catalog of vulnerabilities known to be exploited in the wild, and none of them appear on it. Widening the lens to all 2,648 kernel CVEs Debian has shipped in advisories this year, exactly two are on the list (CVE-2026-31431 and CVE-2026-53362). That works out to roughly 0.08%. For a broader sense of scale, CISA has added eight Linux kernel entries to the catalog in all of 2026, and some of those are older bugs from 2018 and 2022.
None of that means the other fixes are useless. Plenty of kernel bugs matter a lot on specific hardware or configurations, and a bug that nobody exploits today can become tomorrow's problem. It does mean the raw count tells you very little about risk, which is exactly what the kernel's own documentation warns: most assigned CVEs "are not relevant" to any given system, and the team says it can't tell you which ones apply to yours.
What we'd do if you run Linux
Here's our take. If you run Debian 13, install the update (sudo apt update && sudo apt full-upgrade) and reboot, because a new kernel does nothing until you boot into it. Don't try to triage 1,313 entries one by one. The kernel team's own advice is to take whole stable releases rather than cherry-pick fixes, and at this volume that's the only approach that scales.
If you look after a fleet, the bigger change is rhythm rather than any single advisory. Ubuntu is about to ship kernels weekly, Debian's batches are getting bigger, and reboot windows that used to be monthly will start to feel slow. It's worth deciding now whether you'll reboot more often or lean on live patching where you have it. And if anyone on your team still reports "number of open CVEs" as a security metric, this is a good week to retire it in favor of something like "known-exploited bugs still unpatched," which on most Linux machines should be a much smaller and much more useful number.