Configuration analysis answers whether a kernel CVE’s code is in your build. Attack-path triage answers whether anyone can reach it. Here is the difference on the managed switch from our start page:
414 CVEs are compiled in but have no way in on this device. 52 do. Every verdict, open or closed, names the path it was decided on, in the VEX.
How it decides
For every kernel CVE, the KernelScan Engine records its attack paths: who the attacker is and what they need on the device. Your product profile says what exists. A rule engine checks each path against it:
A CVE is only closed when every path is closed. If the profile cannot decide a path, the path stays open. Same profile, same verdict, every time.
The device
The Switch 2400: a 24-port GbE plus 4 SFP DIN-rail managed switch for OT networks, single purpose, nobody logs in.
Example 1: a privilege escalation with nobody to escalate
CVE-2026-64109, CVSS 8.8, found by Jann Horn at Google: a race in UNIX domain sockets leads to a use-after-free. Any process can trigger it, no privileges needed. UNIX sockets are in every Linux build; nobody compiles them out. But a local exploit needs a local attacker first:
On an appliance nobody logs into, this whole class of bug needs a foothold first, for example a network bug in a running service. That is why the network CVEs, like example 3, are the ones that stay red.
Example 2: five ways in, all shut
CVE-2026-43067: an ext4 bug, CVSS 9.8. There are many ways to feed a kernel a filesystem, and each one is closed by a different part of the profile:
Add a front-panel USB port to the profile and the fourth path opens. The CVE becomes exploitable again.
Example 3: the one that stays red
CVE-2026-68118, CVSS 8.2: while a TCP connection is being set up, the kernel accepts a reset that merely lands inside the window, instead of demanding the exact sequence number. Someone on the network can kill connections to the switch’s web interface before they are established. All it needs is a TCP port, and the switch has one:
Not a remote root, but real, and it works on a default configuration. The fix is in 6.6.153: a stable update closes it. Attack-path triage doesn’t make findings disappear. It tells you which ones to act on.
Across the whole switch
Most kernel CVEs are local privilege escalations. On an appliance nobody logs into, that whole class needs a foothold first. What stays open is mostly the network, which is what a switch is for.
Check it yourself
Both VEX documents behind the showcase are public CycloneDX 1.6 files, no account needed (about 7 MB each):
- Switch 2400 with product profile: 52 exploitable, 414 closed by a mitigating control
- Switch 2400, configuration only: 466 exploitable, for comparison
Any example, straight from the VEX (swap in the other two CVE IDs):
curl -s https://kernelscan.io/api/samples/showcase-ies-2408g/arm/vex \
| jq '.vulnerabilities[]
| select(.id == "CVE-2026-64109")
| .analysis.state, .properties'Verdicts are recalculated with every CVE data import. The counts here are from 12 October 2026.
For the CRA: protected_by_mitigating_control on its own is a claim. Followed by “local-unprivileged: closed — no unprivileged local actor” it is an argument your team can check against the device. More in our CRA Article 14 post.
A closed path is only as good as the profile: if the device has a reachable USB port, the profile has to say so. An attack path says how a CVE can be reached, not that it has been exploited.
Try it on your own product: 30 days free, cancel anytime. Choose Pro when you register (it includes the security factors), upload your .config, fill in the product profile, and every CVE in your VEX shows the path that keeps it open, or the factor that closed it. Start your free trial →
The 30 days start when you add a card at checkout; you are not charged if you cancel before they end.