EUVD-2026-53332
GHSA-9rfp-q4v5-653h
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
AV:N because client contacts attacker's server over network; PR:N as attacker needs no privileges on the victim client; A:H for reliable memory corruption; C:L and I:L for secondary adjacent-memory impact.
Primary rating from Vendor (TuranSec).
CVSS VectorVendor: TuranSec
Lifecycle Timeline
5DescriptionCVE.org
nanoMODBUS through v1.23.0 contains an out-of-bounds write in the Modbus client-side recv_read_device_identification_res() function (FC 0x2B/MEI 0x0E, Read Device Identification) in nanomodbus.c. The server-supplied object_length field (0-246) is validated only against the remaining PDU size (res_size_left) and is never validated against the caller-supplied buffers_length parameter. After copying data with strncpy(buffers_out[buf_index], str, buffers_length), the code unconditionally writes a NUL terminator at buffers_out[buf_index][object_length]. When a malicious or compromised Modbus server sends a response with object_length greater than or equal to the client's buffers_length, this NUL write lands past the end of the caller-provided buffer, corrupting adjacent stack or heap memory on the client.
AnalysisAI
Memory corruption in nanoMODBUS through v1.23.0 allows a malicious or compromised Modbus server to crash or potentially execute arbitrary code on connecting clients by sending a crafted Read Device Identification response (FC 0x2B/MEI 0x0E) that triggers an out-of-bounds NUL byte write in recv_read_device_identification_res(). Any application embedding this library and invoking the Device Identification client function is exposed when connecting to an attacker-controlled server. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis, though the off-by-one NUL write primitive into adjacent heap or stack memory represents a realistic path to both denial of service and, depending on allocator layout, code execution.
Technical ContextAI
nanoMODBUS (CPE: cpe:2.3:a:debevv:nanomodbus:*:*:*:*:*:*:*:*) is a lightweight, single-file C library implementing both Modbus RTU and TCP for embedded and IoT targets, maintained at https://github.com/debevv/nanoMODBUS. The affected code path in nanomodbus.c processes FC 0x2B/MEI 0x0E Read Device Identification responses, which return vendor and product metadata as variable-length ASCII objects. The root cause is CWE-787 (Out-of-Bounds Write): after correctly limiting the data copy with strncpy(buffers_out[buf_index], str, buffers_length), the code unconditionally writes a NUL terminator at buffers_out[buf_index][object_length] using the server-controlled object_length value instead of buffers_length - 1. The server-supplied object_length (valid range 0-246 per protocol spec) is checked only against the remaining PDU window res_size_left, never against the caller-supplied buffers_length parameter. Any response where object_length is greater than or equal to buffers_length results in a single NUL byte written past the end of the caller-provided buffer, corrupting adjacent stack or heap memory on the client.
RemediationAI
No vendor-released patched version has been confirmed in the available references; the upstream repository at https://github.com/debevv/nanoMODBUS should be monitored for a fix. The correct code-level remedy is to replace the unconditional NUL write at buffers_out[buf_index][object_length] with a write at buffers_out[buf_index][min(object_length, buffers_length - 1)], ensuring the terminator never exceeds the caller-provided boundary. As an interim compensating control, callers can pass a buffers_length value of at least 247 bytes (the maximum protocol object_length of 246 plus one NUL) to eliminate the overflow window - though this does not fix the underlying missing check and may not be practical on memory-constrained targets. If Read Device Identification is not operationally required, disabling or removing calls to the affected function entirely eliminates exposure with no side effects. At the network layer, restricting Modbus client connections to allowlisted trusted server IP addresses and segmenting OT networks to prevent lateral movement reduces the attacker's ability to position a malicious server; note that Modbus itself has no authentication, so network-level controls are the primary mitigation boundary.
More in Nanomodbus
View allOut-of-bounds heap/stack write in nanoMODBUS through v1.23.0 lets an unauthenticated network client corrupt memory in th
Arbitrary-address memory write in the nanoMODBUS Modbus client library (through v1.23.0) allows a malicious or compromis
Off-by-one buffer overflow in nanoMODBUS through v1.23.0 lets remote unauthenticated attackers write one attacker-contro
Same weakness CWE-787 – Out-of-bounds Write
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today