CVE-2026-13214: Stack buffer overflow in OCPP GetConfiguration key parsing
The OCPP 1.6 client in subsys/net/lib/ocpp/ocppj.c contains a stack buffer overflow in parsegetconfigmsg(). When handling a GetConfiguration request from the central system, the handler copied the attacker-controlled JSON "key" string into the caller's fixed 50-byte stack buffer (skey[CISTR50], declared in subsys/net/lib/ocpp/ocpp.c) using an unbounded strcpy(). The parsed key value points directly into the receive buffer, so its length is bounded only by the message size (CONFIGOCPPRECVBUFFERSIZE, default 2048).
The GetConfiguration message is delivered over the WebSocket connection that the charge point opens to its configured central system. The reader thread ocppwsreader() reads the message into ui->recvbuf and dispatches it to parsegetconfigmsg() via the PDU function table. An attacker who controls the central system endpoint, or a man-in-the-middle on an unencrypted connection, can send a GetConfiguration request whose "key" field exceeds 50 bytes and overflow the reader thread's stack with attacker-chosen bytes.
The consequence is a remotely triggerable stack smash on the OCPP reader thread: at minimum a denial of service, and plausibly remote code execution depending on build-time hardening such as stack canaries and MPU configuration. The fix replaces the strcpy() with a bounded strncpy(key, payload.key[0], CISTR50 - 1) followed by explicit NUL termination, matching the bounded copies already used by the sibling handlers.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Ensure the receive buffer used by ocpp_wsreader() for GetConfiguration parsing is set to a value not exceeding the default (CONFIG_OCPP_RECV_BUFFER_SIZE, default 2048), since the parsed key points into the receive buffer and its length is bounded by the message size.
OCPP reader thread (ocpp_wsreader / GetConfiguration handling in subsys/net/lib/ocpp/ocpp.c) CONFIG_OCPP_RECV_BUFFER_SIZE = 2048
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
OCPP 1.6 clients using the affected GetConfiguration handler are exposed when they accept messages over the WebSocket connection to their configured central system. The charge point initiates that connection, so the relevant trust boundary is the central-system endpoint it connects to.
What does an attacker need to trigger the overflow?
An attacker must control the configured central-system endpoint or be able to modify traffic on an unencrypted connection. They can then send a GetConfiguration request with a JSON "key" value longer than 50 bytes.
How large can the attacker-controlled key be?
The key is copied into a fixed 50-byte stack buffer without a length check. Its effective upper bound is the OCPP receive-message size, which defaults to CONFIG_OCPP_RECV_BUFFER_SIZE of 2048 bytes.
Does transport encryption address the risk?
Encryption prevents the specifically described man-in-the-middle path on an unencrypted connection. It does not protect a charge point if its configured central-system endpoint is attacker-controlled or compromised.