Zephyr RTOS OCPP EUVD-2026-52008

Three concrete conditions must all be satisfied for exploitation. First, the target Zephyr firmware must have been compiled with CONFIG_OCPP=y; this is an experimental feature disabled by default, so standard Zephyr builds are entirely unaffected. Second, the attacker must either directly control the OCPP 1.6 central server (CSMS) that the victim device is configured to connect to - for example by compromising the EV charging network management backend - or occupy an on-path network position capable of injecting WebSocket frames into an unencrypted ws:// OCPP session; OCPP commonly operates over plain ws:// in practice, making on-path injection a realistic threat model on untrusted network segments. Third, the attacker must craft a WAMP RPC frame in which the uid or action field is at least 127 bytes and contains no closing double-quote character within the first 127 bytes. The CVSS vector (PR:N) correctly reflects that no authentication to the OCPP client device is required from the attacker's perspective, since the malicious frame originates from the server side. Exploitation is further limited to the version range Zephyr 4.3.0 to pre-4.5.0.

The NVD-assigned CVSS 3.1 score of 8.6 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H) reflects network reachability without authentication but overstates real-world risk in several respects. The most significant mitigating factor is that CONFIG_OCPP is an EXPERIMENTAL Kconfig option that is disabled by default - the overwhelming majority of Zephyr deployments never compile in this code path and are entirely unaffected; this condition is not reflected in the CVSS score. The C:L sub-score is questionable given the vendor advisory explicitly states the over-read data is not reflected to the peer; I:L and A:H are more defensible. Practical exploitation further requires either control of the OCPP central server the device connects to, or on-path network positioning to inject WebSocket frames into an unencrypted ws:// session - while OCPP-over-ws:// is common in EV charging infrastructure, achieving either position is not trivial. EPSS at 0.19% (10th percentile) confirms negligible observed exploitation activity, and SSVC classifies technical impact as only partial with automatable exploitation assessed as 'no.' Against that, SSVC does flag POC availability, which meaningfully lowers the skill barrier for any attacker targeting OCPP infrastructure; operators who have CONFIG_OCPP compiled in and are running affected versions should treat patching as urgent regardless of the low prevalence signal. No CISA KEV listing has been identified, so active in-the-wild exploitation is not confirmed.

An attacker who has compromised or operates a rogue OCPP 1.6 central server sends a WAMP RPC CallRequest frame over the established WebSocket connection in which the uid field is exactly 127 bytes long and contains no closing double-quote character. The Zephyr OCPP client's parse_rpc_msg() passes the token to extract_string_field(), which copies 127 bytes via strncpy() without writing a NUL terminator; the subsequent strchr() call then scans past the end of the 128-byte stack buffer into adjacent memory and, depending on the stack layout, either faults on an unmapped page (crashing the device) or writes a NUL byte over a critical adjacent value such as a saved return address. SSVC data indicates proof-of-concept exploit code exists, which lowers the technical bar for an attacker familiar with OCPP and Zephyr internals.