That means a blue screen. On a lab laptop, a blue screen is annoying. On a PC running a production test cell or a vehicle diagnostics station, it is lost output and maybe a ruined test run.
What's affected and what fixes it
According to CISA, the vulnerable software is:
- PEAK-System Device Driver Setup: version 5.1.2.1151 and earlier
- PCAN Windows CAN device drivers: version 5.1.2 and earlier
All six CVEs apply to both products. CISA's remediation note says HMS Networks AB has addressed the issue in version 5.1.4 and recommends that users upgrade to the newest available version.
PEAK-System's own version history backs this up. It lists Device Driver Setup 5.1.4.1200, dated October 19, 2026, with PCAN drivers updated to version5.1.4.20123, plus updated PCAN-RP1210-C (4.0.12) and PCAN-UDS (2.3.4) APIs. So the patch shipped one day before CISA published. Patch first, disclose second is how it should work.
The same history shows the affected 5.1.2.1151 setup was released on 2026-07-01. That release updated PCAN-Basic API to version 5.1.0 and PCAN-View to version 6.0.1. If you installed or refreshed PEAK drivers over the summer, assume you're on a vulnerable build until you've checked.
A note on version numbers: the installer and the drivers inside it are numbered differently. The setup package is 5.1.4.1200, but the PCAN drivers it installs are 5.1.4.20123. When you audit machines, check the driver version itself. Don't stop at a "5.1.x" label in an installed-apps list.
Which Windows machines are in scope
PEAK's driver download page lists Device Driver Setup 5.x for Windows 11 (x64/ARM64) and Windows 10 (x64). It's a bundle, not a single driver. Besides the PCAN and PLIN drivers, it installs PEAK-Settings, PCAN-View, PLIN-View Pro and Virtual PCAN-Gateway, plus the PCAN-Basic, PLIN-API and PCAN-RP1210 APIs. PEAK points older operating systems, x86 systems and some legacy interfaces to separate packages, which it says are no longer maintained. Those machines won't get this fix through the 5.x channel.
PEAK's hardware information page names the kernel drivers involved on Windows 11/10. PCAN_USB.SYS covers the USB family (PCAN-USB, PCAN-USB FD, PCAN-USB X6, PCAN-USB Pro FD, PCAN-USB XL and others). There is also PCAN_VIRTUAL.SYS for the virtual CAN device, PCAN_LAN.SYS for the Virtual PCAN-Gateway, and PCAN_PCI.SYS for the internal cards. These are the files to look for on an endpoint.
CISA lists the affected sectors as transportation systems, healthcare and public health, energy, and critical manufacturing, deployed worldwide.
The six vulnerabilities
All six CVEs share the same basic CVSS 3.1 conditions: local attack vector, low complexity, low privileges required, and no user interaction. Here's what CISA says each one does:
| CVE | Weakness | What goes wrong | CVSS 3.1 | CVSS 4.0 |
|---|---|---|---|---|
| CVE-2026-109576 | CWE-787 Out-of-bounds Write | The parser rejects a malformed record correctly, but its loop still advances the processed-bytes counter | 5.5 Medium | 6.8 Medium |
| CVE-2026-101103 | CWE-120 Classic Buffer Overflow | A diagnostic call doesn't check that the caller's output buffer is big enough for the output record | 5.5 Medium | 6.8 Medium |
| CVE-2026-94188 | CWE-120 Classic Buffer Overflow | An attacker can influence a copied source field through the file-device write path and pair it with a small output allocation | 5.5 Medium | 6.8 Medium |
| CVE-2026-103672 | CWE-129 Improper Array Index Validation | The DLC field indexes a length table without a DLC ≤ 0x0f check, then attacker data is copied into a fixed-size stack buffer | 7.1 High | 6.9 Medium |
| CVE-2026-110322 | CWE-822 Untrusted Pointer Dereference | The type 0x4030 processing path dereferences an object pointer without validating it | 5.5 Medium | 6.8 Medium |
| CVE-2026-105960 | CWE-130 Length Parameter Inconsistency | Receive-record copies use a requested or queued count without capping it to the caller's buffer length | 5.5 Medium | 6.8 Medium |
Five of the six only affect availability, which in kernel terms means a crash. CVE-2026-103672 is the outlier. Its CVSS 3.1 vector also rates integrity impact as High, because attacker-controlled bytes land on a kernel stack. That's how it gets to 7.1. Its CVSS 4.0 score of 6.9 is still labelled Medium. The two scoring systems weigh things differently, so don't treat their labels as interchangeable when you rank this in a patch queue.
CISA's header says "5 Vulnerabilities" but lists six CVEs, because CWE-120 appears twice. That's a counting quirk, not a missing bug.
For readers who don't live in CAN: the DLC (Data Length Code) is the frame field that says how much payload follows. In CAN FD, DLC values above 8 map to larger payload sizes through a lookup table, which is why there's a length table at all. Classic CAN DLC values only go up to 0x0f, so a missing bounds check means an out-of-range value reads past the end of the table and then drives an oversized copy.
How worried should you be?
Here's the reassuring part. CISA says no known public exploitation specifically targeting these bugs had been reported at publication, and that the vulnerabilities are not remotely exploitable. An attacker needs to be running code on the box first, with low privileges.
Now the less reassuring part, which is my analysis rather than CISA's. "Local, low privilege" is a common second step in real intrusions. Malware that lands as a normal user and finds a kernel driver with sloppy buffer handling has an obvious next move, even if all it does is crash the machine. Shared engineering workstations, test-bench PCs with generic logins and kiosk-style diagnostic stations are exactly where "low privileged local user" describes nearly everyone.
PEAK has been here before. An earlier flaw, CVE-2025-6217, was a time-of-check/time-of-use race in the driver's PCANFD_ADD_FILTERS IOCTL handling. That record noted an attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of the kernel. That bug was rated Low on its own. The pattern is the point: IOCTL and parsing paths in this driver family have now drawn researcher attention more than once.
Credit for this batch goes to Seyeon Bang, who reported the issues to CISA.
Section summary: the risk is real but bounded. Expect local crashes, with a possible kernel memory corruption angle on one CVE. Remote attack isn't possible and no exploitation in the wild has been reported, so this is a scheduled update, not a panic.
What Windows admins should do
- Find your PCAN machines. Search endpoint inventory for PEAK-System Device Driver Setup and for the PCAN_*.SYS driver files listed above. Engineering and test labs often sit outside normal patch tooling, so ask them directly.
- Check the driver version, not just the installer version. In Windows, Device Manager shows the installed driver version under each device's driver properties (that's standard Windows behaviour, not something from PEAK's documentation). You want the 5.1.4 driver line, which the vendor lists as 5.1.4.20123. Anything at 5.1.2 or below is affected.
- Get the update from PEAK's official driver download page. CISA's advisory says users can find software updates there. Install Device Driver Setup 5.1.4.1200 or newer.
- Test before you roll it out on production systems. The 5.1.4 setup also updates the RP1210-C and UDS APIs. If a production test station depends on specific API behaviour, validate it on a spare first. CISA itself recommends doing an impact analysis and risk assessment before making changes.
- Deal with legacy systems separately. Machines on x86, older Windows, or legacy interfaces that need PEAK's unmaintained packages won't get this fix through 5.x. Plan to retire them, isolate them, or keep untrusted local users off them.
- Cut down local access. These are local bugs, so firewalls alone don't fix them. Removing shared accounts, restricting who can log on to PCAN-equipped PCs, and controlling what software runs there all directly shrink the attack surface.
CISA's usual ICS advice still applies: keep control-system devices off the internet, put control networks behind firewalls and away from business networks, and use VPNs for remote access while remembering VPNs need patching too. That's sensible defence in depth, but it doesn't replace the update. A local kernel bug doesn't care how good your perimeter is.
The bigger picture
Every third-party kernel driver on Windows is something you're trusting to handle input safely. Specialist hardware vendors in automotive and industrial niches usually ship small driver teams, long product lifecycles, and customers who install a driver once and never touch it again. That combination is why advisories like this keep coming.
The good news is that this one went the right way: the vendor shipped a fixed build before the public advisory, versions are clearly scoped, and there's no reported exploitation. The bad news is that the fix only helps machines that actually get it. If there's a PCAN-USB dongle plugged into a dusty PC in your lab, now's the time to check its driver.