Between July 19 and 20, 2026, 440 disclosures were concentrated in the official Linux kernel CVE archive. Tracing the publication timestamps shows a span of 31 hours and 18 minutes from the first disclosure to the last, with 431 of the 440 falling on July 19 alone. However, this is not a record of 440 vulnerabilities being discovered and fixed within a single day and night. Because the Linux kernel assigns CVEs after a fix has already landed in the stable tree, this number represents the scale of a batch that disclosed past fixes all at once.
AI's contribution cannot be measured from the total count of 440 either. AI involvement can be confirmed in the disclosure text for at least 24 cases, with an additional 3 cases mentioning generic static analysis tools. The 24 cases include 23 that explicitly named Sashiko, plus one XFS case that cites AI-assisted auditing as the discovery path. None of these disclosures state that AI fully and automatically fixed the kernel on its own.
The 440 Cases Are "CVE Disclosures," Not "Fixes"
The timestamps in the official archive span from 09:10:42 UTC on July 19 to 16:28:51 UTC on July 20. Therefore, framing this as "over 400 fixes in 24 hours" misreads both the time span and the nature of the work involved. What was counted were disclosure emails assigning CVEs to issues for which a fix commit already existed.
The Linux kernel CVE team searches for fixes that could represent potential security issues during the normal stable release process and automatically assigns CVEs. Unfixed issues are not automatically assigned numbers. Because the kernel runs at the core of systems, and it's often unclear at the time of fixing whether a bug is exploitable, the team has explicitly stated a policy of erring on the side of caution and assigning numbers broadly. A large number of disclosures by itself is not evidence that an equal number of emergencies or remote attack vectors have arisen.
The scope of these 440 cases is also broad. Counting the paths listed in the "Affected files" field per disclosure, 199 cases included drivers, 114 included net, and 66 included fs. Since some disclosures span multiple directories, there is overlap in these counts, but this shows that rather than a single incident confined to networking or filesystems, these are fixes accumulated across a massive codebase.
"Fixed Versions" Spanning 402 Cases in the 7.1 Series
The "Affected and fixed versions" field in each disclosure shows, per branch, the version that introduced the issue and the version that incorporated the fix. Of the 440 disclosures, 402 listed a version in the 7.1 series as the fixed version, 352 listed the 6.18 series, 350 listed the 7.0 series, and 269 listed the 6.12 series. Since a single disclosure can span multiple branches, the total exceeds 440.
| Series Listed as Fixed Version | Number of Disclosures |
|---|---|
| 7.1 series | 402 |
| 6.18 series | 352 |
| 7.0 series | 350 |
| 6.12 series | 269 |
This distribution shows that it wasn't a single new patch version that suddenly fixed all 440 issues at once. In fact, many disclosures list 7.1, 7.0.11, 6.18.34, and 6.12.93, among others, as the fixed version, meaning fixes had already gone into multiple time periods and series. The CVE publications were simply consolidated afterward.
As of July 21, the latest stable version shown on kernel.org is 7.1.4, with the mainline at 7.2-rc4. Long-term support versions such as 6.18.39 and 6.12.96 are also maintained. 7.1.4, 6.18.39, and 6.12.96 were released on July 18, and 7.2-rc4 on July 19. However, Debian backports security fixes into its stable packages, and guidance states that whether a version is safe should be checked against the exact package version listed in the relevant Debian Security Advisory. Upstream version numbers alone cannot determine the fix status within a Debian environment.
AI Involvement Traceable in At Least 24 Cases
Upon reviewing the text of all 440 disclosures, 23 explicitly named "Sashiko," the AI code review system for the Linux kernel. Separately, CVE-2026-64187 cites AI-assisted code auditing as its discovery path. That brings the number of disclosures with directly traceable AI involvement to at least 24.
Sashiko is an open-source review system under the Linux Foundation that monitors patches posted to public mailing lists. It checks architecture and security through a multi-stage protocol, and also examines resource management and concurrency. The compute resources and LLM tokens for the public service are provided by Google.
CVE-2026-64187 offers a clear view of that boundary. XFS's recovery process could reach a NULL pointer dereference when reading a committed log item lacking an extent. This does not occur under normal operation but can happen via a crafted log, a path that AI-assisted auditing discovered; the fix was subsequently incorporated into 6.12.96, 6.18.39, 7.1.4, and 7.2-rc4.
On the other hand, CVE-2026-64206, which fixed a Bluetooth L2CAP deadlock, is described as having been discovered via a static analysis tool and manually reviewed against the current tree. The term "static analysis" alone doesn't establish whether an LLM was used. Three disclosures in this batch used this phrasing. For CVE-2026-64206, it can be confirmed that tool-based discovery and human-based triage were distinct steps.
In CVE-2026-64115, which involved Sashiko, an issue arose during vsock/VMCI connection establishment: if the peer returned a reset, a path existed that wrote again to an already-freed socket. According to the KASAN test results noted in the disclosure, the unfixed version reproduced the issue 52 times out of 100, while the fixed version reproduced it 0 times out of 100. In this case, Sashiko's finding was verified through reproduction testing before the fix was applied.
Before the Total Count: Check Your Running Configuration and Distributor Updates
The Linux kernel CVE team itself has explained that many CVEs among a large batch may not apply to individual systems. The source tree is enormous, and what's actually in use depends only on the configuration, loaded modules, connected hardware, and externally exposed interfaces for a given system. The number 440 alone cannot tell you whether every Linux machine faces the same level of risk.
Administrators should first check their running kernel package, and cross-reference it against the security advisories from their distribution or device vendor. From there, they should examine their use of Bluetooth and virtualization. Filesystem and network drivers should also be prioritized based on which areas are actually enabled. For custom-built kernels, it's necessary to verify whether the corresponding upstream commits have been incorporated.
Official policy recommends receiving bundled, tested stable updates rather than cherry-picking and applying individual commits. Administrators need to check the fixed versions indicated in their distributor's advisories. This batch of 440 cases has increased the scope of what needs to be managed. The actual priority for updating is determined, for each environment, by whether that code path is enabled and whether the distributor has incorporated the fix.