KernelScan now monitors public exploit code for Linux kernel CVEs and rolls the evidence into an Exploit Maturity signal. It appears in the UI and, with the latest release, travels with owner-facing CycloneDX VEX downloads and Dependency-Track pushes.
The first production crawl found 282 public-code sightings across 185 CVEs. After consolidating multiple sources and exploit variants, 114 CVEs reached the stronger Weaponized tier and 71 were classified as PoC.
Four questions, two urgency signals
The four labels shown together in KernelScan do not describe the same thing:
- CVSS estimates the vulnerability’s potential technical severity.
- Applicability says whether the vulnerable code is present and reachable in this product.
- Exploit Maturity says what kind of public exploit code KernelScan has found: PoC or Weaponized.
- CISA KEV says that CISA has evidence of exploitation in the wild.
Exploit Maturity and KEV are the two urgency signals. They can raise patch priority, but neither changes the affected/not-affected verdict. Public exploit code cannot make a disabled subsystem reachable, and a KEV listing cannot add code that the product did not compile.
How PoC, Weaponized and KEV combine
PoC and Weaponized are the two levels of one Exploit Maturity signal. PoC means public code exists but may be incomplete, unreliable or limited to one build. Weaponized means KernelScan has stronger evidence for an end-to-end working exploit.
KEV remains a separate signal. When CISA lists a CVE for which public code is already known, KernelScan raises the effective maturity to Weaponized and keeps the KEV marker visible. If a KEV-listed CVE has no known public code, it remains KEV-only: KernelScan does not invent an Exploit Maturity badge.
| Evidence KernelScan holds | Exploit Maturity | KEV |
|---|---|---|
| Indexed public code | PoC | No |
| Curated end-to-end exploit | Weaponized | No |
| Public code plus a CISA KEV listing | Weaponized | Yes |
| CISA KEV listing, but no known public code | None | Yes |
None of the three CVEs used below was in CISA KEV when rechecked on August 23, 2026. The two PoC examples therefore stay PoC, while the curated exploit example is Weaponized on the strength of its exploit evidence alone.
What counts as stronger exploit evidence
One curated source is kernelCTF, Google’s Linux kernel exploit bounty and verification program. Researchers must make their exploit capture a flag on a controlled Linux target. Published submissions include the exploit and a technical write-up and pass automated checks plus review. That makes a kernelCTF entry materially stronger evidence than a repository discovered by a broad index.
Popularity alone does not produce the stronger label. A repository with hundreds of stars can still be incomplete or unverified, so index-source results remain PoC regardless of star count.
Recent examples: two PoCs and one Weaponized exploit
The screenshots below show the current production UI. Public CVE pages use the labels Public PoC and Public Exploit; signed-in detail views add the evidence source and repository link.
CVE-2026-68398: PPPoL2TP receive-path use-after-free
Published on August 10, CVE-2026-68398 is a race between PPPoL2TP receive processing and destruction of an unattached PPP channel. The public implementation targets a specific Ubuntu 22.04 kernel build and documents escalation from an unprivileged user to root in a disposable virtual machine. Exposure depends on an affected kernel and the relevant PPP and L2TP support.
KernelScan labels it PoC. The implementation is detailed and publicly reproducible, but controlled testing is not evidence of exploitation in the wild.
CVE-2026-68138: traffic-control rate-table race
Also published on August 10, CVE-2026-68138 affects the Linux traffic-control rate-table implementation. Concurrent requests can race a global list and reference count, potentially producing a use-after-free or double-free.
A public implementation documents local privilege escalation in tested virtual machines. Applicability still depends on the affected traffic-control path, kernel configuration and the attacker’s ability to reach the required namespace and Netlink operations. It is neither universal exposure nor a KEV: it is a recent, technically supported PoC that deserves attention on matching systems.
CVE-2026-23271: perf event-overflow race
The newest live Weaponized entry, published on March 20, CVE-2026-23271 is a race between perf-event overflow handling and removal of the same event from its context. An overflow path can continue using resources, including an attached BPF program, after another path has freed them. The result is a use-after-free with potential for kernel memory corruption, local privilege escalation or a crash.
This is a local attack, not a network one. A user must be able to open the relevant
perf events; hardened systems commonly restrict that with capabilities and the
perf_event_paranoid setting. Product teams should
check for CONFIG_PERF_EVENTS, local or workload access,
and whether their branch includes the fix: 6.1.167, 6.6.130, 6.12.77, 6.18.17,
6.19.7 or mainline 7.0.
KernelScan grades it Weaponized because the curated kernel-exploit-factory entry contains an end-to-end exploit together with the exact Linux 6.12.69 target image and configuration. It is still not a KEV: a working, packaged exploit demonstrates capability, while KEV requires evidence of attacks in the wild.
How KernelScan sources the evidence
KernelScan watches three complementary sources. kernelCTF is the Google-run program described above: researchers exploit controlled Linux targets, capture a flag, and publish reviewed code and documentation. The kernel-exploit-factory is a curated collection of end-to-end exploits packaged with concrete target artifacts. Entries from either collection can support the Weaponized tier.
The broader PoC-in-GitHub index is handled more cautiously. Repositories must pass deterministic age, description, fork and activity checks. Detector, mitigation and patch repositories are rejected where they can be identified. Results from this source remain PoC.
A scheduled watcher now checks all three sources for new and updated exploit evidence. Every accepted sighting is stored in KernelScan’s CVE database with its source and provenance. When evidence appears, changes or is suppressed, KernelScan recalculates the CVE’s effective Exploit Maturity so the public badge, filters, API responses, product results and exported VEX stay current.
Multiple sightings are retained independently. A CVE may have several implementations, several kernelCTF targets or evidence from more than one source. KernelScan rolls these up to the strongest supported maturity without discarding provenance. Incorrect evidence can be suppressed without deleting its history, after which the CVE’s maturity is recalculated.
Public badge, gated evidence
The Exploit Maturity badge is public. Any visitor can see that public code exists and understand its confidence level.
The underlying proof links and source details are available to signed-in users with a verified email address. The repositories themselves are public, but this approach prevents KernelScan from becoming an anonymous, crawler-friendly directory of kernel exploit code.
The signal now travels with the VEX
The UI is no longer the only place that carries these urgency signals. Owner-facing CycloneDX VEX exports now append two namespaced properties to each vulnerability when they apply:
"properties": [
{
"name": "kernelscan.io:exploit_maturity",
"value": "poc"
},
{
"name": "kernelscan.io:kev",
"value": "true"
}
]
kernelscan.io:exploit_maturity carries the effective
value, poc or
weaponized, so an existing PoC promoted by KEV cannot
disagree with the badge. kernelscan.io:kev remains a
separate boolean property, present only when the CVE is in the CISA catalog.
KernelScan joins both properties when the document is downloaded or pushed, rather than baking them into the cached analysis. A PoC discovered after an analysis ran, or a new KEV listing, therefore appears on the next job download, product VEX, MCP retrieval or Dependency-Track push without regenerating the VEX. The stored document remains unchanged.
These are properties rather than CVSS modifiers. They preserve the evidence for filtering and policy without quietly changing the vulnerability’s severity score. Anonymous showcase VEX files deliberately remain undecorated; authenticated product exports carry the same signal the product owner sees in the UI.
What changes in triage
Exploit Maturity adds urgency, not applicability.
For an affected product, Weaponized deserves immediate attention because exploit development may no longer be a meaningful barrier. PoC should trigger a review of the code, its target assumptions and whether they match the product’s kernel, configuration and attacker model. A KEV badge raises the priority again: it means exploitation is no longer confined to research environments.
For a product where the vulnerable subsystem is absent or unreachable, the correct outcome can still be not affected—even when public exploit code exists.
The goal is to present and export configuration-aware applicability, severity, public-code maturity and confirmed real-world exploitation together—without asking one signal to answer every question.