A critical vulnerability in Zephyr OCPP allows a malicious or compromised host to cause an outage in electric vehicle charging devices. CVE-2026-10848 affects the experimental Zephyr OCPP 1.6 client and was published on August 2.
According to the NVD entry, the issue is classified as an out-of-bounds read and write, with codes CWE-125 and CWE-787. The SecNews technical team points out that the immediate consequence is primarily a remote denial of service, not confirmed code execution.
See also: CVE-2026-10666: Stack Overflow in Zephyr via net_ipaddr_parse
How the Zephyr OCPP vulnerability works
The flaw is located in the OCPP 1.6 client code, in subsys/net/lib/ocpp. The parse_rpc_msg() processes incoming WAMP RPC frames, while the extract_string_field() and extract_payload() handle message values.
In the problematic path, the uid or action is copied into a 128-byte buffer with strncpy(). When the input reaches or exceeds 127 characters, the function does not guarantee a null-termination. Then, strchr() continues searching beyond the buffer boundaries.
A specially crafted message without a closing quote can thus cause adjacent memory to be read. If a quote is found beyond the end, an out-of-bounds byte is written. A similar risk exists when the receive buffer is filled by a maximum-size frame without a terminating null character.
Which Zephyr OCPP users are at risk?
The attack requires sending data from the OCPP central system to the device. Therefore, the focus is on installations where the server is malicious or compromised, as well as environments where an attacker can intercept the connection.
The issue is made more important because OCPP is also encountered over plain ws://, without transport encryption. Using wss:// limits tampering along the path, but does not protect against a malicious or compromised host. Zephyr's OCPP feature is experimental and must be explicitly enabled with CONFIG_OCPP.
NVD does not list specific affected versions, so manufacturers should not assume a version is secure just because it is not listed in the product table. It is necessary to check the branch and patches that have been incorporated into the firmware of each charger or embedded device.
The public assessment of CVE-2026-10848 is high severity, with a CVSS 3.1 score of 7.0. The score primarily reflects the remote possibility of causing a disruption, while data leakage is considered limited because the bytes read are not returned to the sender.
At the same time, the existence of the bug should not be confused with confirmed remote code execution. On devices with different memory protections and different ways of integrating Zephyr, the final impact may differ. The safest practice is to treat the issue as a network risk until the specific design is tested.
See also: Ubiquiti: Critical vulnerability in UniFi OS – Update now
Fix and protect against CVE-2026-10848
The fix replaces the hand-crafted parser with json_mixed_arr_parse(), which implements bounds checks. At the same time, the exported uid value is explicitly terminated so that no character lookups continue in contiguous memory. The changes are recorded in the upstream Zephyr commit.
Teams maintaining firmware with Zephyr OCPP should detect if CONFIG_OCPP is enabled, check websocket usage, and apply available patch code. Until the update is complete, disabling OCPP where not needed and limiting central servers will reduce exposure.
🔒 Protect your privacy with Proton VPN
Swiss VPN from the creators of Proton Mail — strict no-logs policy, strong encryption, and built-in NetShield that blocks ads, trackers, & malware.
- ✔ No-logs, based in Switzerland (except 14-Eyes)
- ✔ NetShield: blocks ads, trackers & malicious domains
- ✔ Covers all devices — free version available
The link is an affiliate link — SecNews may receive a commission at no additional cost to you. It does not affect the independence of our article writing.
Charging infrastructure administrators should also ensure that connections to central systems only allow the necessary addresses and ports. Logging failed OCPP frames, repeated disconnections, and unexpected reboots can help identify an attempt to trigger the error. Monitoring is not a substitute for updating, but it provides useful reaction time until new firmware is distributed.
At an architectural level, isolating chargers from the rest of the corporate network limits the potential for lateral movement. Administrators can combine segmentation, strict certificate management, central system authentication, and least privilege policies. Where possible, new firmware should be tested first on a small, representative set of devices.
See also: Serious vulnerabilities in WatchGuard Firebox: Risk of firewall compromise
CVE -2026-10848 is not in itself proof that every EV charger is vulnerable. But it does show the risk posed by insecure parsing routines in firmware with network communication. The SecNews technical team recommends immediate inventory, patching, and monitoring for unusual disconnections.
