Zephyr OCPP CVE-2026-13217

Exploitation requires that the target device runs Zephyr with the OCPP subsystem compiled in (CONFIG_OCPP enabled) and that the OCPP connection uses an unencrypted ws:// WebSocket transport (enabling MitM) OR that the attacker has already compromised or controls the OCPP central system the charge point is configured to trust. No additional authentication is required beyond occupying one of these two positions. Observable denial-of-service impact is further conditioned on the Zephyr target having an MMU, MPU, or CONFIG_NULL_POINTER_EXCEPTION_DETECTION configured - bare-metal targets without null-pointer trapping are not impacted, as reading address 0 returns 0 and execution continues normally. The fix in commit 4d8a9eb removes only the first exploitable path; a uid with exactly one hyphen-delimited token still triggers the identical bug via the second unguarded atoi() call in the same function.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H scores 5.9, reflecting network reachability tempered by high attack complexity: the attacker must either control or compromise the OCPP central system, or occupy a MitM position on an unencrypted ws:// connection. This AC:H rating appropriately captures the constraint. EPSS data was not supplied, so exploitation probability cannot be quantified numerically; however, OCPP-over-plain-WebSocket deployments in poorly segmented networks (common in legacy EV infrastructure) lower the practical bar for MitM. The vulnerability is not listed in CISA KEV and no public exploit or proof-of-concept code has been identified at time of analysis. The impact is strictly availability and platform-conditional, significantly limiting blast radius: bare-metal Zephyr targets are immune, and the affected scope is a single charge point device rather than a backend server. The partial patch status is a material risk factor - applying only the first commit (4d8a9eb) leaves the second strtok_r/atoi path reachable via a carefully shaped uid. Defenders should treat this as a medium-priority embedded-IoT issue elevated by the patch incompleteness.

An attacker occupying a MitM position on an unencrypted ws:// OCPP connection - achievable via ARP spoofing on a shared charging-station LAN or via a rogue access point - waits for the charge point to issue a CALL request, then returns a CALLRESULT whose uid field contains no hyphen delimiter or is empty. The ocpp_process_server_msg() function calls strtok_r on the malformed uid, receives NULL, and passes it directly to atoi(); on an MMU-equipped Zephyr device, the resulting NULL dereference faults the OCPP reader thread and invokes the fatal handler, taking the charge point offline. No public proof-of-concept code exists, but the attack primitive is straightforward network packet injection requiring no binary exploit skill.