EUVD-2026-53331
GHSA-29rm-wvww-5gjv
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Unauthenticated single-packet network trigger against a default server handler gives AV:N/AC:L/PR:N/UI:N; OOB write reliably yields A:H and, via potential RCE on unprotected targets, C:H/I:H.
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 server-side handle_read_file_record() function (FC 0x14, Read File Record) in nanomodbus.c. The function validates that the total request size does not exceed 245 bytes and that each sub-request's record_length is at most 124, but it never validates the CUMULATIVE response size across all sub-requests before processing them. The accumulator response_data_size is declared as uint8_t and is incremented by 2 + record_length*2 for each of up to 35 sub-requests; with 35 sub-requests of record_length=124, the cumulative demand is 8750 bytes, which overflows the uint8_t accumulator. A subsequent loop then calls get_n(), an internal function with no bounds checking, once per sub-request to obtain a pointer into the 260-byte msg.buf receive buffer and advances the internal buf_idx by up to 248 bytes per call; swap_regs() then writes to that pointer unconditionally. A single crafted FC 0x14 request from an unauthenticated network client can cause up to ~8490 bytes to be written out of bounds past the 260-byte buffer, corrupting adjacent memory in the server process and leading to denial of service or potential remote code execution, particularly on embedded/bare-metal targets without memory protection.
AnalysisAI
Out-of-bounds heap/stack write in nanoMODBUS through v1.23.0 lets an unauthenticated network client corrupt memory in the Modbus server via a single crafted Read File Record (FC 0x14) request. The server-side handle_read_file_record() function validates per-request and per-sub-request sizes but never checks the cumulative response size, and a uint8_t accumulator (response_data_size) silently overflows, allowing swap_regs() to write up to ~8490 bytes past the 260-byte receive buffer. There is no public exploit identified at time of analysis, but the flaw yields reliable denial of service and, on embedded/bare-metal targets lacking memory protection, potential remote code execution.
Technical ContextAI
nanoMODBUS is a small, dependency-light C implementation of the Modbus protocol (RTU and TCP) intended for embedded and bare-metal devices (CPE cpe:2.3:a:debevv:nanomodbus). The bug is a classic CWE-787 out-of-bounds write rooted in an integer-truncation/accumulator design error: the running total of response bytes is stored in a uint8_t (max 255), yet up to 35 sub-requests each contributing 2 + record_length*2 bytes (record_length up to 124) can demand 8750 bytes. Because the overflow wraps the accumulator instead of triggering a size rejection, the subsequent processing loop repeatedly calls the internal get_n() helper - which performs no bounds checking - advancing buf_idx by as much as 248 bytes per sub-request into the fixed 260-byte msg.buf, and swap_regs() then writes through that unchecked pointer. Modbus itself carries no authentication or transport encryption, so any client that can reach the server's TCP port (typically 502) can submit the malicious function code.
RemediationAI
No vendor-released patch version was identified at time of analysis - the only references are the upstream repository root and nanomodbus.c on master, with no tagged fixed release or fix commit/PR provided, so monitor https://github.com/debevv/nanoMODBUS for a release that adds a cumulative-response-size check and widens the response_data_size accumulator beyond uint8_t. Until a fixed version is confirmed, restrict network reachability of the Modbus endpoint: place the device behind a firewall or ACL that permits TCP/502 (or the RTU-over-TCP port in use) only from known-trusted engineering hosts, and segment OT/ICS networks so untrusted clients cannot reach the server - the trade-off is that legitimate remote polling stations must be explicitly whitelisted. If Read File Record (FC 0x14) is not needed operationally, disable or reject that function code at the application layer or via a Modbus-aware firewall/DPI proxy, which blocks this attack path at the cost of losing file-record functionality. As a stopgap for maintainers building from source, patching handle_read_file_record() to sum the sub-request response sizes in a wider integer and reject requests exceeding the 260-byte buffer before calling get_n() removes the primitive.
More in Nanomodbus
View allArbitrary-address memory write in the nanoMODBUS Modbus client library (through v1.23.0) allows a malicious or compromis
Memory corruption in nanoMODBUS through v1.23.0 allows a malicious or compromised Modbus server to crash or potentially
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 allShare
External POC / Exploit Code
Leaving vuln.today