One Debian kernel update lists 1,313 CVEs, 97% of the previous 17 combined. None is on CISA's KEV list

1,313 identifiers against 1,353 in the previous 17

Debian's security advisory DSA-6528-1, posted on 29 September 2026, lists 1,313 CVE identifiers for one package, the Linux kernel on Debian 13 (Trixie), fixed in version 6.12.111-1. The 17 earlier Trixie kernel advisories, from the first on 13 August 2025 to the last on 29 August 2026, list 1,353 between them, and the largest of those listed 396. No identifier appears in more than one of the 18. One advisory therefore lists 97% as many as the other 17 put together, and 3.3 times the previous largest.

That is the number behind The Register's headline of 5 October. Here is what it does not establish.

• It does not show that 1,313 flaws were found or written in 6.12.111. The Register says so itself, and the kernel CNA's own records give a first affected mainline kernel before 6.12 for 1,238 of the 1,313, and before 5.0 for 570.
• It does not show that any of them is exploited. None is in CISA's Known Exploited Vulnerabilities (KEV) catalogue, version 2026.10.04, released 4 October 2026 at 18:52 UTC and unchanged when re-read at 06:16 UTC on 6 October. That describes the catalogue, not the world: KEV lists only what CISA has reliable evidence of.
• It does not give a Debian severity. Debian's tracker reads "not yet assigned" for all 1,313, and Debian's FAQ says it does not provide CVSS scores.
• It does not show that AI-assisted bug hunting caused the volume. That is The Register's suspicion, and no source I read measures it.

The friendly name is the trap. A CVE count reads as a measure of danger, or of how well a kernel is written. The kernel's own documentation describes something else: its CVE assignment team is "overly cautious and assign CVE numbers to any bugfix that they identify". The 1,313 counts assigned identifiers, which is a policy outcome. It measures how much a policy and its tooling produce, not how much risk the update removes. The update still has to be applied in full, because the kernel ships as one package and the kernel documentation says its changes are "tested together in a unified whole". Its advice is to take all released changes.

What the advisory says, and what it leaves out

The advisory is short. It is dated 29 September 2026 and names the package linux. It says several vulnerabilities in the kernel "may lead to a privilege escalation, denial of service or information leaks", that for the stable distribution (trixie) they are fixed in 6.12.111-1, and that Debian recommends upgrading the linux packages. A list of 1,313 identifiers follows, under one bug number. The list in the advisory as posted and the list on Debian's tracker page for DSA-6528-1 are the same set: both hold 1,313 distinct identifiers.

What DSA-6528-1 states, and what it leaves out, read on 6 October 2026

1. Topic

   Package and fix

   Stated

   linux, Debian 13 (trixie), fixed in 6.12.111-1, posted 29 September 2026

   Not stated

   Which of the 1,313 apply to a given configuration or hardware

2. Topic

   Impact

   Stated

   "may lead to a privilege escalation, denial of service or information leaks", for the set as a whole

   Not stated

   How many identifiers fall under each effect

3. Topic

   Severity

   Stated

   Nothing. Debian's FAQ: it "does not provide CVSS scores". Tracker urgency for all 1,313: not yet assigned

   Not stated

   A rating, urgency or priority for any single identifier

4. Topic

   Remote or local

   Stated

   Nothing. Debian's FAQ says the "Problem type" field in advisory mails has not been used since April 2014

   Not stated

   Which identifiers can be reached over a network

5. Topic

   Exploitation

   Stated

   Nothing

   Not stated

   Whether any is exploited. KEV lists none of the 1,313 (version 2026.10.04)

6. Topic

   Action

   Stated

   "We recommend that you upgrade your linux packages."

   Not stated

   A reboot. A kernel takes effect only when the host boots it, which is how kernels work and not something the advisory says

Topic	Stated	Not stated
Package and fix	linux, Debian 13 (trixie), fixed in 6.12.111-1, posted 29 September 2026	Which of the 1,313 apply to a given configuration or hardware
Impact	"may lead to a privilege escalation, denial of service or information leaks", for the set as a whole	How many identifiers fall under each effect
Severity	Nothing. Debian's FAQ: it "does not provide CVSS scores". Tracker urgency for all 1,313: not yet assigned	A rating, urgency or priority for any single identifier
Remote or local	Nothing. Debian's FAQ says the "Problem type" field in advisory mails has not been used since April 2014	Which identifiers can be reached over a network
Exploitation	Nothing	Whether any is exploited. KEV lists none of the 1,313 (version 2026.10.04)
Action	"We recommend that you upgrade your linux packages."	A reboot. A kernel takes effect only when the host boots it, which is how kernels work and not something the advisory says

Two further Debian records are worth reading beside it, because each can be mistaken for a rating. The changelog entry for the 6.12.111-1 upload reads "trixie-security; urgency=high", but that is the upload's urgency, and every one of the 19 trixie-security uploads in the same changelog carries it. It is not a score for any identifier. And the changelog annotates 626 CVE identifiers against individual fixes, 624 of them in the advisory's list, so the other 689 in the list carry no annotation there. Debian does not say how those were matched, which is a reason to read the list as a bookkeeping result and not as 1,313 reviewed findings.

How the 1,313 divide, by every cut a primary supports

Four cuts have a primary source behind them. All four are computed from Debian's tracker data (fetched at 05:37 UTC on 6 October 2026), the 1,313 CVE.org records, and the kernel's own release logs.

The 1,313 cut four ways; counts by script

1. Cut

   By Debian urgency, Trixie

   Result

   1,313 not yet assigned

   Source and caveat

   Debian tracker data. All 19,709 kernel entries: 17,166 not yet assigned, 2,450 unimportant, 93 low, none medium or high

2. Cut

   By upstream release that fixed it, 6.12 line

   Result

   6.12.108: 59. 6.12.109: 276. 6.12.110: 569. 6.12.111: 407. No 6.12 fix recorded: 2

   Source and caveat

   CVE.org records. The four releases came out between 2 and 21 September 2026

3. Cut

   By first affected mainline kernel

   Result

   Before 5.0: 570. 5.x: 354. 6.0 to 6.11: 314. 6.12: 26. After 6.12: 46. None given: 3

   Source and caveat

   The CNA's records. 61 give 2.6.12, the oldest value. It is the CNA's version range, not a date

4. Cut

   By CVE identifier year

   Result

   2026: 1,295. 2025: 15. 2024: 3

   Source and caveat

   The year an identifier was reserved says nothing about when the bug was written

Cut	Result	Source and caveat
By Debian urgency, Trixie	1,313 not yet assigned	Debian tracker data. All 19,709 kernel entries: 17,166 not yet assigned, 2,450 unimportant, 93 low, none medium or high
By upstream release that fixed it, 6.12 line	6.12.108: 59. 6.12.109: 276. 6.12.110: 569. 6.12.111: 407. No 6.12 fix recorded: 2	CVE.org records. The four releases came out between 2 and 21 September 2026
By first affected mainline kernel	Before 5.0: 570. 5.x: 354. 6.0 to 6.11: 314. 6.12: 26. After 6.12: 46. None given: 3	The CNA's records. 61 give 2.6.12, the oldest value. It is the CNA's version range, not a date
By CVE identifier year	2026: 1,295. 2025: 15. 2024: 3	The year an identifier was reserved says nothing about when the bug was written

Subsystem is the cut readers ask for first. Debian's tracker gives no subsystem field, so the table below groups the first word of each identifier's description, which is the prefix of the fixing commit's title. It is my grouping, not Debian's or the CNA's, and a prefix is a rough guide to where code lives.

Largest commit-title prefixes among the 1,313, grouped by script

1. Prefix

   net (includes net/sched, net/rds, net/smc)

   Identifiers

   93

2. Prefix

   wifi

   Identifiers

   69

3. Prefix

   media

   Identifiers

   44

4. Prefix

   nfsd

   Identifiers

   43

5. Prefix

   drm

   Identifiers

   41

6. Prefix

   rdma

   Identifiers

   37

7. Prefix

   usb

   Identifiers

   35

8. Prefix

   scsi

   Identifiers

   34

9. Prefix

   bpf

   Identifiers

   28

10. Prefix

    alsa

    Identifiers

    28

Prefix	Identifiers
net (includes net/sched, net/rds, net/smc)	93
wifi	69
media	44
nfsd	43
drm	41
rdma	37
usb	35
scsi	34
bpf	28
alsa	28

There are 272 distinct prefixes. The ten above cover 452 identifiers, 34%, so the rest is a long tail across drivers, filesystems and protocols. A host that never loads a Wi-Fi, Bluetooth or graphics driver has no use for the code behind those prefixes, yet the package still carries it and the update still replaces it. Whether that code is reachable on a given machine is the host's question, and the kernel's documentation says so: applicability "is up to the user of Linux to determine".

Remote versus local. No primary splits all 1,313. Debian's tracker data holds a scope field that reads "local" for 19,704 of 19,709 kernel entries, all 1,313 included, so a field that never varies cannot separate anything. The kernel CNA's CVSS vectors cover 500 of the 1,313 (next section): 301 local, 151 network and 48 adjacent, meaning same-network or radio reach such as Wi-Fi or Bluetooth. The network ones sit in code that serves a network, led by 31 in nfsd, 11 in sunrpc, 9 in ceph and 7 in svcrdma. Those matter on hosts that run such a service, which is a judgement to make per host, not a count to read off. Exposure can hinge on a single setting: an earlier briefing found an ARM64 KVM escape that mattered only where nested virtualisation was switched on at boot.

Who scored the 1,313, and who did not

The record answers "how severe" in four different ways, and only one of them is Debian's.

Debian does not rate them. Its FAQ, last modified 17 September 2026, answers a scanner question directly: Debian "does not provide CVSS scores and doesn't use CVSS scores from external sources when triaging security issues". Its tracker documentation says Debian does not use severity levels, with old low, medium and high annotations "no longer applied to current data". So "not yet assigned" is the standard state of a kernel entry, 87% of Trixie's, and not a backlog on this advisory.

The kernel CNA scores 500, which departs from what it said in February. A post of 16 February 2026 by a member of the CNA team under the heading "We can not assign severity" argues that only the integrator who knows the use case can judge it, and says the team has asked NIST to stop assigning scores. In the CVE.org records I read, the CNA's own container carries a CVSS 3.1 vector, a base score and a paragraph of scenario text for 500 of the 1,313: 414 high and 86 critical, none below 7.0, 22 of them at exactly 7.0. A branch of the CNA's repository holds commits titled "Add CVSS 3.1 score", dated 25 September 2026. I found no CNA statement that explains the change, and the kernel's CVE documentation is silent on scoring. Both are the CNA's words, and both are on the record. The 813 with no score are not low-scored. They are unscored, and I found no explanation from the CNA of why.

NVD mostly relays, and has barely started. NVD shows the CNA's 500 as secondary scores. NIST's own CVSS 3.1 score is on 28 of the 1,313, 25 medium and 3 high, and NVD's status is still "Received" for 1,211 of them (read between 05:47 and 05:59 UTC). NVD's source 134c704f-9b21-4f2e-91b3-4a467353bcc0 is CISA-ADP, not the vendor: it supplies a decision-point block on 5 records, each reading "Exploitation: none", and a CVSS of 5.5 on two. Red Hat's enrichment adds a rating of Important and a CVSS of 7.0 on one. CISA's directive BOD 26-04 of 10 June 2026 says CISA publishes KEV status, automatability and technical impact for every CVE identifier, and on these records that is 5 of 1,313 so far.

KEV lists none, and lists late. CISA's criteria require "reliable evidence that the vulnerability has been actively exploited in the wild", and say a public proof of concept or scanning does not count. The catalogue holds 31 Linux kernel entries, none of them in this advisory, and Debian's tracker shows 30 of the 31 resolved for both Trixie and Debian 12; the other, CVE-2010-3904, is not filed under the linux package. The three added on 18 September 2026 were fixed in Trixie at 6.12.57-1, 6.12.94-1 and 6.12.48-1. The last of those, CVE-2025-39682, was fixed in DSA-6008-1 on 22 September 2025, 361 days before CISA listed it. KEV is a lagging list, which is a reason to patch the kernel on a calendar and not to wait for it.

Why the number is this size

The count follows the CNA's output, and that output has risen sharply. The kernel CNA published 2,115 CVE records in September 2026, against 246 in January, according to NVD's publication dates (rejected records excluded). A February post by a member of the CNA team put the rate at about 60 a week; September's figure is about 494 a week, my arithmetic. 1,256 of the 1,313 in this advisory carry a CVE.org publication date in September, on eight days, and 1,203 of them on five days: 11, 16, 17, 24 and 25 September. NVD listed none for 1 to 6 October at 06:04 UTC, so September is one month and not yet a trend.

More fixes do not explain it alone. The four upstream 6.12 releases behind this advisory hold 2,943 commits between them, counted from the kernel's release logs: 100, 396, 1,362 and 1,085. 6.12.110 is the largest of the 112 releases in the 6.12 line, and the median release holds about 160. But the number of identifiers per commit moved far more than the number of commits.

Upstream 6.12 releases, their commits, and the CVE identifiers Debian lists against each, derived by script

1. Release and date

   6.12.91, 23 May

   Commits

   663

   CVE ids in Debian advisories

   19

2. Release and date

   6.12.97, 24 July

   Commits

   1,204

   CVE ids in Debian advisories

   67

3. Release and date

   6.12.101, 3 August

   Commits

   591

   CVE ids in Debian advisories

   27

4. Release and date

   6.12.103, 9 August

   Commits

   338

   CVE ids in Debian advisories

   115

5. Release and date

   6.12.104, 19 August

   Commits

   180

   CVE ids in Debian advisories

   98

6. Release and date

   6.12.109, 7 September

   Commits

   396

   CVE ids in Debian advisories

   276

7. Release and date

   6.12.110, 14 September

   Commits

   1,362

   CVE ids in Debian advisories

   569

8. Release and date

   6.12.111, 21 September

   Commits

   1,085

   CVE ids in Debian advisories

   407

Release and date	Commits	CVE ids in Debian advisories
6.12.91, 23 May	663	19
6.12.97, 24 July	1,204	67
6.12.101, 3 August	591	27
6.12.103, 9 August	338	115
6.12.104, 19 August	180	98
6.12.109, 7 September	396	276
6.12.110, 14 September	1,362	569
6.12.111, 21 September	1,085	407

6.12.97 held 1,204 commits and 67 identifiers; 6.12.110 held 1,362 and 569. The ratio is not one identifier per commit and the table is a derived comparison, not a measured rate, but it shows the identifier count tracking the CNA's assignment pace more than the volume of fixes. The kernel's documentation says assignment follows any bugfix "that they identify", and a February post says CVE identifiers are assigned after the fix has been in a released kernel, so the count depends on a process with its own pace.

What each source says about AI-assisted bug hunting and the volume of kernel CVEs

1. Source

   The Register, 5 October 2026

   Says

   "strongly suspect" LLM bots are behind the number; it did not examine every entry

   Does not say

   Any measurement. It is the outlet's inference

2. Source

   Kernel lead maintainer, 7.1-rc4 mail, 17 May 2026

   Says

   AI reports have made the security mailing list "almost entirely unmanageable", with heavy duplication

   Does not say

   Anything about CVE counts or the share of fixes found that way

3. Source

   Kernel CNA post, 16 February 2026

   Says

   Of three core CNA members, one uses a custom tool that queries "some LLM oracles" to review commits for CVE assignment

   Does not say

   How many assignments result, or that this drives volume

4. Source

   NCSC chief technology officer, 1 May 2026

   Says

   AI is showing the ability to exploit technical debt "at scale and at pace"; expect a patch wave across all severities

   Does not say

   Kernel figures, or Debian's

5. Source

   Debian advisory and tracker

   Says

   Nothing about cause

   Does not say

   Why this advisory is the size it is

Source	Says	Does not say
The Register, 5 October 2026	"strongly suspect" LLM bots are behind the number; it did not examine every entry	Any measurement. It is the outlet's inference
Kernel lead maintainer, 7.1-rc4 mail, 17 May 2026	AI reports have made the security mailing list "almost entirely unmanageable", with heavy duplication	Anything about CVE counts or the share of fixes found that way
Kernel CNA post, 16 February 2026	Of three core CNA members, one uses a custom tool that queries "some LLM oracles" to review commits for CVE assignment	How many assignments result, or that this drives volume
NCSC chief technology officer, 1 May 2026	AI is showing the ability to exploit technical debt "at scale and at pace"; expect a patch wave across all severities	Kernel figures, or Debian's
Debian advisory and tracker	Nothing about cause	Why this advisory is the size it is

None of these ties the 1,313 to AI-assisted discovery by measurement, so the cause stays open. Several facts fit the suspicion and several fit other explanations: two of the three largest of the 112 stable releases in the 6.12 line landed in the window, the CNA assigns for any bugfix it identifies, and it now attaches scores to some records. No vendor's tooling is named by any source as the cause, and this briefing names none. The wider pattern of AI-found reports straining volunteer projects is in an earlier briefing on Google pausing an open-source bounty.

What it means for UK estates running Debian

The people affected are anyone who runs Debian 13 on servers, container hosts or appliances. I have no count of UK Debian estates. Universities, councils, internet service providers and suppliers to health services are the places one would expect them, and that is judgement, not a measured list. Debian-based systems such as Ubuntu publish their own kernel packages and notices, and this advisory covers Debian's package only; see the earlier briefing on Ubuntu's cadence.

Cyber Essentials. Version 3.3 (April 2026), section 3, says software must be "updated, including vulnerability fixes, within 14 days" of release where one of three things holds: the update fixes vulnerabilities "described by the vendor as critical or high risk"; it addresses vulnerabilities "with a CVSS v3 base score of 7 or above"; or "there are no details of the level of vulnerabilities that the update fixes provided by the vendor". It adds a caution: a single update covering several severities must be installed within 14 days if it covers any critical or high risk issue.

Debian describes none of the 1,313 as critical or high and provides no CVSS, so my reading is that the third condition applies. The second is also met if an assessor accepts the kernel CNA's scores, which are 7.0 or above on 500 of them; the scheme text does not say whose CVSS score counts, so I do not rely on it alone, as in an earlier briefing on a vendor sentence that named no level. Fourteen days from 29 September is 13 October 2026. On 6 October, about 07:00 BST, that is day 7. What an assessor decides is for the assessor, and nothing here is certification advice.

NCSC best-practice timescales applied to the 29 September release date

1. Type of estate (NCSC)

   Internet-facing services and software

   Update completed within

   5 days

   Date from 29 September

   4 October

2. Type of estate (NCSC)

   Operating system and applications

   Update completed within

   7 days

   Date from 29 September

   6 October

3. Type of estate (NCSC)

   Internal and air-gapped

   Update completed within

   14 days

   Date from 29 September

   13 October

Type of estate (NCSC)	Update completed within	Date from 29 September
Internet-facing services and software	5 days	4 October
Operating system and applications	7 days	6 October
Internal and air-gapped	14 days	13 October

The NCSC's timescales "apply to all updates, regardless of the vulnerability severity", so on the NCSC's own page the question "how severe is it" does not set the clock. I read a kernel as part of the operating system, which makes today the seventh day; an internet-facing Debian host was due on 4 October. The NCSC also says organisations "shouldn't make decisions based purely on a single severity score, such as CVSS", and its patch wave blog of 1 May 2026 expects "an influx of updates" across all severities and asks for hot patching to be enabled "as a priority" where it exists. I found no live-patching service in Debian's advisory or FAQ. That is a gap in what I read, not a finding that none exists.

Scanners and dashboards. A scanner that counts each CVE separately can put up to 1,313 findings against a host that has not updated, and clear them when it has. That is accurate, and unhelpful as a priority signal. Three effects are worth knowing. First, clearing does not reach zero: Debian's tracker listed 813 further kernel identifiers as open for Trixie at 05:37 UTC, none of them in this advisory, so a patched host still shows a count. Second, a clock that starts at the CVE's publication date is already running: 395 of the 1,313 were published at least 15 days before Debian released its fix, whereas Cyber Essentials counts from the release of the update. Third, the previous 17 advisories listed 1,353 identifiers over 13 months and this one lists 1,313 on a single day, so any trend line or risk score built on counts will spike for a reason that has nothing to do with exposure. Group findings by advisory and package, as the NCSC suggests when it says to group "similar findings together", and start the clock at the vendor's release.

Reboots and containers. The advisory does not mention a reboot, and a new kernel runs only once the host boots it, so the reboot window has to sit inside the 14 days. Containers use the host's kernel, so patch and reboot the hosts and ignore kernel findings inside images. Debian 12 is a separate decision: its kernel advisories are now numbered DLA, the latest for the linux package being DLA-4777-1 on 8 September with 601 identifiers, and Debian's tracker listed 975 of this advisory's 1,313 as still open for Debian 12 at 05:37 UTC. Hosts on Debian 12 that run the backported linux-6.12 kernel follow a further series of their own, most recently DLA-4817-1 on 4 October.

Debian 12 (bookworm) advisories for the linux package in 2026, identifiers per advisory, from the tracker's page for each

1. Posted

   9 February

   Advisory

   DSA-6127-1

   CVE ids

   250

2. Posted

   12 March

   Advisory

   DSA-6163-1

   CVE ids

   52

3. Posted

   1 May

   Advisory

   DSA-6243-1

   CVE ids

   302

4. Posted

   9 May

   Advisory

   DSA-6258-1

   CVE ids

   2

5. Posted

   15 May

   Advisory

   DSA-6275-1

   CVE ids

   1

6. Posted

   28 May

   Advisory

   DSA-6306-1

   CVE ids

   3

7. Posted

   3 July

   Advisory

   DLA-4665-1

   CVE ids

   496

8. Posted

   18 July

   Advisory

   DLA-4688-1

   CVE ids

   18

9. Posted

   5 August

   Advisory

   DLA-4720-1

   CVE ids

   188

10. Posted

    8 September

    Advisory

    DLA-4777-1

    CVE ids

    601

Posted	Advisory	CVE ids
9 February	DSA-6127-1	250
12 March	DSA-6163-1	52
1 May	DSA-6243-1	302
9 May	DSA-6258-1	2
15 May	DSA-6275-1	1
28 May	DSA-6306-1	3
3 July	DLA-4665-1	496
18 July	DLA-4688-1	18
5 August	DLA-4720-1	188
8 September	DLA-4777-1	601

What to do, in the order worth doing it

uname -r
dpkg -l 'linux-image-*'
apt-cache policy linux-image-amd64

Method, interest and limits

I counted the identifiers in the advisory text and on Debian's tracker page by script, compared the two sorted lists, and joined them by identifier to Debian's tracker data, the 1,313 CVE.org records, the NVD records and the KEV catalogue. The Register's dates and figures were each checked against a primary source: Debian 13.7 was released on 12 September, upstream 6.12.111 on 21 September, the kernel became a CNA on 13 February 2024, and the 6.12.112 changelog runs to 29,457 lines. The sources are a distribution's security team, the kernel's own CNA, two government agencies and a news outlet, and I found no stake in the count for any of them; The Register's LLM point is its own inference. Scanner vendors, whose products count identifiers, are not sources here. Where AI-assisted discovery is concerned, every claim is attributed to a source and no vendor is singled out.

Limits. I did not verify the cause of the volume, why the CNA began scoring or how it chooses which records to score, how Debian matched the 689 identifiers its changelog does not annotate, what Debian's tracker scope field means, how many UK organisations run Debian, or how an assessor would apply the three Cyber Essentials conditions to an upstream CNA's score. The advisory text and the Debian mailing list archive sit behind a browser check, which a normal browser passed; no check was bypassed.

The question that exposes the gap

If one package update can put 1,313 findings on a dashboard and none of them says whether a single one is exploited, what is the number you report to your board measuring: the risk the update removes, or the pace at which identifiers are assigned?

Key facts