PEAK-System PCAN Driver CVEs: CVE-2026-103672 and the 5.1.4 Fix

CISA published ICSA-26-293-01 on 20 October 2026 for six vulnerabilities in HMS Networks PEAK-System PCAN Windows CAN drivers, fixed in driver setup 5.1.4. The headline flaw, CVE-2026-103672, is a missing DLC bound check in the parser: the record's length code is used to index a length table and then to copy attacker payload into a fixed-size stack buffer, earning CVSS 3.1 7.1 (high). All six bugs require local access, none is remotely exploitable, and CISA reports no public exploitation. The practical question is not whether the robot controller is exposed — it is which engineering laptops, HIL benches and Windows IPC cells still carry the 5.1.2 driver.
Key takeaways
- Six CVEs, five weakness classes: one high-severity array-index bug (CVE-2026-103672, 7.1) and five medium-severity memory-safety bugs (5.5 each under CVSS 3.1).
- Affected: PEAK-System Device Driver Setup 5.1.2.1151 and earlier, and PCAN Windows CAN device drivers 5.1.2 and earlier.
- Fixed: driver setup 5.1.4, released 19 October 2026 — one day before the advisory.
- Local only: the CVSS vector is AV:L/AC:L/PR:L/UI:N. No remote vector, no user interaction, no reported exploitation.
- Impact is kernel-level: CISA says successful exploitation could crash the Windows kernel. CVE-2026-103672's vector also shows high integrity impact, which is consistent with memory corruption rather than a crash alone.
- Action: inventory every Windows host that loads a PCAN interface, upgrade to 5.1.4, reboot, and verify the driver file version — not just the entry in Apps & Features.
What CISA actually published
The advisory is short and unusually specific for an ICS notice: it names the driver packages, lists six CVE identifiers, gives a CVSS 3.1 and 4.0 score for each, and points to version 5.1.4 as the fix. It does not name individual PCAN adapters, publish a proof of concept or describe the fix commit. The reporter is credited as Seyeon Bang. At the time of writing, the advisory is at revision 1, dated 20 October 2026.
| Field | Value |
|---|---|
| Advisory | ICSA-26-293-01, initial publication 20 October 2026 |
| Vendor | HMS Networks (PEAK-System is an HMS brand; HMS acquired PEAK-System in 2024) |
| Affected products | PEAK-System Device Driver Setup ≤5.1.2.1151; PCAN Windows CAN device drivers ≤5.1.2 |
| Fixed version | PEAK-System driver setup 5.1.4, published 19 October 2026 |
| Highest CVSS 3.1 | 7.1 High — CVE-2026-103672 |
| Attack vector | Local, low privileges, no user interaction (AV:L/AC:L/PR:L/UI:N) |
| Remote exploitation | No; CISA states the vulnerabilities are not exploitable remotely |
| Public exploitation | None reported to CISA at the time of publication |
| Impact summary | Successful exploitation could crash the Windows kernel |
| Sectors listed | Transportation Systems, Healthcare and Public Health, Energy, Critical Manufacturing |
| Credit | Seyeon Bang |
Two details in that table matter for planning. First, the affected range is expressed against the driver and the setup package, not against a hardware list. Any Windows machine that loads one of these drivers with a PCAN interface falls inside the scope until proven otherwise. Second, the advisory says "could crash the Windows kernel" in its summary, but the CVSS vector for CVE-2026-103672 includes a high integrity impact (I:H). A pure denial-of-service bug would normally score C:N/I:N/A:H. The 7.1 score is a signal that the parser can write beyond the intended buffer, not only that it can stop the machine.
The six vulnerabilities in plain English
All six sit in the Windows kernel driver's parsing and copy paths. Five of them produce the same practical result — a malformed record or undersized output buffer causes an out-of-bounds access, and the machine bugchecks. The sixth, CVE-2026-103672, combines an out-of-bounds table read with a stack copy, which is why it stands apart.
| CVE | CWE | CVSS 3.1 | CVSS 4.0 | What fails |
|---|---|---|---|---|
| CVE-2026-103672 | CWE-129, improper validation of array index | 7.1 High | 6.9 Medium | The parser indexes a length table with an attacker-controlled DLC value without enforcing DLC ≤ 0x0F, then copies payload from record+0x1C into a fixed-size stack destination. |
| CVE-2026-109576 | CWE-787, out-of-bounds write | 5.5 Medium | 6.8 Medium | The parser detects a malformed record, but the loop still advances its processed-bytes counter as if the record had been accepted. |
| CVE-2026-101103 | CWE-120, classic buffer overflow | 5.5 Medium | 6.8 Medium | A diagnostic call does not verify that the caller-supplied output buffer can hold the complete output record. |
| CVE-2026-94188 | CWE-120, classic buffer overflow | 5.5 Medium | 6.8 Medium | The file-device write path lets a caller combine a small output allocation with attacker-influenced source bytes. |
| CVE-2026-110322 | CWE-822, untrusted pointer dereference | 5.5 Medium | 6.8 Medium | The type 0x4030 processing path dereferences a selected or returned object pointer without validating it first. |
| CVE-2026-105960 | CWE-130, length parameter inconsistency | 5.5 Medium | 6.8 Medium | A variable-length receive-record copy uses the requested or queued count without capping it to the caller's actual output length. |
Why CVE-2026-103672 is the one to fix first
CAN uses a four-bit data length code to describe how many bytes follow. Classic CAN defines values 0–8. CAN FD reuses 9–15 to mean 12, 16, 20, 24, 32, 48 and 64 bytes. Drivers therefore keep a small lookup table that maps a DLC value to a byte count. The advisory says the PCAN parser uses the record's DLC as an index into that table without checking that it is at most 0x0F, then copies data from a fixed offset in the record into a stack buffer.
That sequence explains the severity. An out-of-range index can read a length from beyond the table, and the subsequent copy uses the attacker's payload and that length. If the chosen length exceeds the stack destination, the copy overwrites adjacent stack memory. CISA's CVSS vector records no confidentiality impact but high integrity and availability impact, which fits a controlled write into kernel stack memory followed by a crash. The advisory does not claim privilege escalation, and no public exploit exists, but a local low-privileged process that can reach this IOCTL path should be treated as a potential route from user mode to kernel mode until HMS publishes its own root-cause analysis.
This is also why "it only crashes the machine" is the wrong risk model for a test bench. A bugcheck loses unsaved work, interrupts a validation run and can leave a robot cell or HIL rig in an undefined state. On a shared engineering PC, a crash is an availability event; on a machine controller, it can become a production and safety event.
Who is actually exposed
The advisory's vector is local, which narrows the threat model but does not make it irrelevant. The vulnerable code runs in kernel mode on any Windows host that loads the PCAN driver. In industrial automation that usually means an engineering workstation, not the robot controller. Yaskawa, FANUC, KUKA and ABB controllers run their own real-time operating systems; PCAN adapters typically sit on the Windows PC used for commissioning, vision development, HIL testing or vehicle network logging.
That PC is often the least controlled asset in the cell. It is shared by integrators, maintenance technicians and process engineers; it runs vendor tools, Python scripts and diagnostic utilities downloaded from multiple sites; and it may accept a USB adapter from whoever is on shift. A local low-privileged process — malware, a compromised test script, a malicious utility or an insider — is enough to reach the driver. Remote access is not required, but a remote desktop session into a shared engineering PC still gives the attacker the local foothold the vector describes.
CISA does not list adapter models, so the safe assumption is that every Windows PCAN interface is in scope if the host runs driver 5.1.2 or earlier. That includes PCAN-USB, PCAN-USB FD and PCAN-USB Pro FD adapters, PCIe and PCI cards, miniPCIe and PC/104 formats, and the CAN channels on multi-protocol PEAK devices. The Linux driver is a separate code base and is not named in this advisory.
How to find affected Windows hosts
The version that matters is the driver package, not the PCAN-View application version and not the adapter's firmware. Use at least two checks per host: the installed setup entry tells you what the user ran, while the driver file and PnP record tell you what the kernel actually loaded.
| Check | Where or command | Affected result |
|---|---|---|
| Installed setup | Settings > Apps > Installed apps, search for PEAK or PCAN; or Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -match 'PEAK|PCAN' | Select-Object DisplayName, DisplayVersion | Setup version 5.1.2.1151 or earlier |
| Driver packages in the store | pnputil /enum-drivers, then filter for pcan or PEAK | A published PCAN driver package at version 5.1.2 or earlier |
| Driver files | Get-ChildItem C:\Windows\System32\drivers\pcan*.sys | Select-Object Name, @{n='FileVersion';e={$_.VersionInfo.FileVersion}}, LastWriteTime | File version 5.1.2 or earlier |
| Device Manager | Open the PCAN device > Driver tab > Driver Version | 5.1.2 or earlier |
| PnP signed driver view | Get-CimInstance Win32_PnPSignedDriver | Where-Object { $_.DeviceName -match 'PCAN' } | Select-Object DeviceName, DriverVersion, DriverDate, InfName | DriverVersion 5.1.2 or earlier |
| Fleet inventory | Query the uninstall registry keys and driver file versions through your endpoint management tool | Any hit below 5.1.4, including hosts where the adapter is currently unplugged |
Record four fields per host: PCAN adapter model, driver version, setup package version and the person responsible for the machine. The adapter is often unplugged, so a device-only scan will miss laptops that still have the driver installed. The setup entry will catch those, which is why the registry query belongs in the baseline.
Upgrade to 5.1.4 and verify the result
HMS addressed all six issues in driver setup 5.1.4, released 19 October 2026. The setup package also carries RP1210-C API 4.0.12 and UDS API 2.3.4, so treat it as a platform update rather than a single file swap. The 5.x line supports Windows 11 (x64 and ARM64) and Windows 10 (x64).
- Download from PEAK-System, not from a mirror or a machine builder's share. Keep a hash and an offline copy in your software repository so a site visit does not depend on internet access.
- Stage the update. Test 5.1.4 on one bench host with the same adapter model and the same vendor tools as production. Run a basic transmit and receive test in PCAN-View, then run the actual application for at least one full cycle.
- Install as administrator and reboot. A driver update is not complete until the new kernel image is loaded. Do not accept "pending reboot" as done.
- Verify three things: the setup entry reads 5.1.4, the pcan*.sys file version reads 5.1.4, and Device Manager reports the new driver date. If the setup says 5.1.4 but the loaded file is older, another package in the driver store is winning.
- Update the golden image and the deployment package. Otherwise the next reimage reintroduces 5.1.2. Add a driver-version check to the build validation, not only to the manual checklist.
- Close the loop with suppliers. If a machine builder supplies the IPC, ask for the PCAN driver version and evidence of the 5.1.4 update in writing.
One version question is worth raising with HMS or PEAK directly. CISA writes the affected range as "≤5.1.2," and the final 4.x setup (4.6.4) is numerically lower but belongs to an older branch. The advisory does not discuss 4.x. If any host still runs 4.x for a legacy Windows build, request a written statement rather than assuming the 5.x fix covers it.
If you cannot patch immediately
Some benches are frozen for customer validation, and a driver change requires a requalification window. In that case, reduce the local attack surface rather than pretending the risk is zero.
| Asset | Why it is exposed | Action |
|---|---|---|
| Shared engineering laptop with a PCAN-USB adapter | Multiple users, vendor tools, internet access, travels between sites | Upgrade to 5.1.4 first; remove local admin from day-to-day accounts; rebuild from a patched image |
| HIL or validation bench IPC | Runs third-party scripts and test frameworks; often on a flat lab network | Upgrade, revalidate the harness, isolate the bench VLAN, keep a known-good disk image |
| Robot cell or production IPC with a PCAN card | Continuous operation and remote support access; a bugcheck stops the cell | Schedule the driver update in a maintenance window; verify after reboot; restrict remote logon to named accounts |
| Service laptop used on customer sites | Connects to many networks and unknown USB devices | Patch before the next visit; carry the 5.1.4 installer offline; do not install drivers from site shares |
| Host pinned to 5.1.2 pending requalification | Known vulnerable driver remains loaded | Remove or disable the adapter when not in use; restrict interactive logon; block older driver packages with WDAC or AppLocker; document the exception and expiry date |
Two controls are worth more than they cost. First, separate the engineering account from the administrator account. The CVSS vector requires low privileges, so removing local admin does not eliminate the bug, but it removes the easiest path from a compromised tool to a driver install. Second, use application control to block older PCAN setup packages. If an attacker cannot load 5.1.2, the vulnerable code cannot run, even on a host that has not been rebuilt.
Detection is limited but not useless. A successful exploit of the availability-only bugs looks like a kernel crash: Event ID 41 (unexpected shutdown), BugCheck 1001 and a minidump naming the PCAN driver. Treat repeated bugchecks on a host with a PCAN adapter as a possible exploitation signal, not only as a hardware fault. Preserve the dump and the driver version before rebuilding.
What the advisory does not say
For engineering teams and for AI assistants summarizing this event, the gaps are part of the record. As of 3 November 2026, the public advisory does not provide:
- A list of affected PCAN adapter models. The scope is defined by the driver package, not the hardware.
- A confirmation that CVE-2026-103672 can escalate privileges. The CVSS integrity impact suggests memory corruption, but CISA describes the outcome as a kernel crash.
- Any statement about the Linux PCAN driver, which is a separate code base.
- A proof of concept, exploit code or the specific fix commit.
- A statement on the 4.x driver branch, whose final release predates 5.1.2 numerically.
- Evidence of in-the-wild exploitation. CISA explicitly reports none, and the vulnerabilities are not remotely exploitable.
- Guidance on whether PCAN-View, PCAN-Basic or the RP1210-C API need separate updates. They ship inside the setup package, so the setup version is the control point.
The absence of exploitation is good news, not a reason to defer. Kernel driver bugs in engineering tools have a long shelf life: the adapter stays in a drawer, the laptop is reimaged from an old golden image, and the same 5.1.2 package reappears two years later. The inventory is the durable fix.
The supply-chain angle: golden images and site laptops
Most organizations will patch the hosts they know about and miss the ones they do not. Three patterns are common. A machine builder ships an IPC with a Windows image that includes the PCAN setup used during factory acceptance, and the customer never sees the driver version. A service team keeps a laptop on 5.1.2 because a legacy diagnostic tool refuses to start after an upgrade. A validation lab clones a VM snapshot that predates the advisory and restores it for every test campaign.
The countermeasure is a driver bill of materials. Add PCAN driver version to the asset record for every Windows host that touches a CAN network, and make 5.1.4 the minimum for new builds. For incoming equipment, request the driver version with the FAT documentation. For outgoing service, attach the installer hash to the work order. That is a small amount of paperwork compared with tracing a bugcheck on a customer's line.
The physical layer still needs spares
A driver update does not change the adapters, cables, gateways and CANopen devices around the PC. Test cells that mix PCAN interfaces with PLC communication modules, USB-to-fieldbus converters and CANopen sensors still need nameplate-level spares, and a patched laptop will not replace a failed gateway.
For CANopen networks, the SICK DL100-23HA2109 300 m CANopen sensor is one example of a field device that sits behind a CAN interface. On the control side, the Honeywell TC-FCCN01 ControlNet gateway and the Bently Nevada 3500/92 Modbus gateway handle protocol conversion in process and machinery cabinets. Yokogawa users can source the ALE111-S50 Ethernet communication module and the ALR111-S01 serial communication module; Allen-Bradley and Schneider cells commonly use the 1784-U2DN USB-to-DeviceNet cable, the 1784-U2DHP USB-to-controller converter and the BMXNOC0401 M340 Ethernet module.
For controller and network hardware, the ProSoft MVI56E-MNET Modbus TCP/IP module, the GE Fanuc IC695NIU001 Ethernet NIU, the IC695SPC100 PROFINET scanner and the Yokogawa VI702 Vnet/IP interface card cover common integration points. An Emerson DeltaV VE6071F05C1 industrial switch or a Mitsubishi GT2712 HMI may be the next hop from the engineering PC. More options sit in our controllers and CPUs, drives and motion control, HMI and operator interface, sensor and transducer and I/O module archives.
PetroPartsOnline does not supply PEAK-System PCAN adapters or driver licences. The links above are for the controllers, gateways, HMIs and field devices around a PCAN-based test cell. For the driver itself, use the PEAK-System download page and verify the version after installation.
Frequently asked questions
What is CISA ICSA-26-293-01?
ICSA-26-293-01 is a CISA ICS advisory published on 20 October 2026 for six vulnerabilities in HMS Networks PEAK-System PCAN Windows CAN drivers. It covers driver setup versions up to 5.1.2.1151 and driver versions up to 5.1.2, rates CVE-2026-103672 at CVSS 3.1 7.1, and directs users to version 5.1.4.
Which PEAK-System PCAN versions are affected?
PEAK-System Device Driver Setup 5.1.2.1151 and earlier, and PCAN Windows CAN device drivers 5.1.2 and earlier. The fix is driver setup 5.1.4, released 19 October 2026. Because the advisory scopes the driver package rather than individual adapters, any Windows host running an affected driver with a PCAN interface should be treated as in scope.
Is CVE-2026-103672 remotely exploitable?
No. The CVSS vector is AV:L/AC:L/PR:L/UI:N, which means local access with low privileges and no user interaction. CISA states that the vulnerabilities are not exploitable remotely and reports no public exploitation at the time of publication.
Does this advisory affect the PCAN Linux driver?
The advisory names PEAK-System PCAN Windows drivers and the Windows driver setup package. The Linux PCAN driver is a separate code base and is not named in ICSA-26-293-01. Do not assume that a Windows driver advisory automatically covers a Linux host, and do not assume the reverse either; check the product you actually run.
How do I check whether a Windows PC has an affected PCAN driver?
Check both the installed setup and the loaded driver. In Settings, look for PEAK-System Device Driver Setup and compare it with 5.1.2.1151. Then run pnputil /enum-drivers or inspect the version of the pcan*.sys files in C:\Windows\System32\drivers. A host is affected if either the setup package or the loaded driver is 5.1.2 or earlier.
Does upgrading to 5.1.4 fix all six CVEs?
HMS Networks states that version 5.1.4 addresses the issues in the advisory, and CISA lists 5.1.4 as the remediation for every affected product entry. After installation, reboot and verify that the driver file version is 5.1.4, because an older package in the Windows driver store can still win the load even when the setup entry looks correct.
Sources
- CISA: ICSA-26-293-01, HMS Networks PEAK-System PCAN Windows drivers — advisory text, affected versions, CVSS scores and remediation.
- CISA: ICSA-26-293-01 CSAF JSON — machine-readable CVE, CWE and score data.
- PEAK-System: driver downloads — Windows driver setup and supported operating systems.
- PEAK-System: driver setup version history — version 5.1.4 dated 19 October 2026, with bundled driver, RP1210-C and UDS API versions.
- PEAK-System: about the company — company history and HMS Networks ownership.
- MITRE CWE-129: Improper Validation of Array Index — weakness definition behind CVE-2026-103672.
- Microsoft Learn: PnPUtil — driver package enumeration used in the inventory table.
- CVE.org: CVE-2026-103672 — record for the high-severity array-index vulnerability.
Talk to us
Replacing a controller, gateway or HMI after a failed update? Send the nameplate, model code and a photo of the label. PetroPartsOnline supplies current-production and legacy automation spares across Allen-Bradley, Siemens, Schneider, Yokogawa, Honeywell, Bently Nevada, SICK, Mitsubishi and other platforms, with revision and firmware matching before shipment.
Contact PetroPartsOnline for a quote or a cross-reference.
