CVE-2026-71254 in nanoMODBUS
Summary
by MITRE • 08/05/2026
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.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/05/2026
The nanoMODBUS library version 1.23.0 contains a critical out-of-bounds write vulnerability in its Modbus server-side implementation that affects the Read File Record function (FC 0x14). This flaw exists within the handle_read_file_record() function in nanomodbus.c where the software performs inadequate validation of cumulative response sizes across multiple sub-requests. While the code correctly validates that individual requests do not exceed 245 bytes and that each sub-request's record_length remains under 124 bytes, it fails to account for the total memory requirements when processing multiple sub-requests simultaneously.
The vulnerability stems from the use of a uint8_t accumulator variable named response_data_size that is incremented by the formula 2 + record_length*2 for each of up to 35 sub-requests. When processing 35 sub-requests with maximum record_length of 124, this calculation results in a cumulative demand of 8750 bytes that completely overflows the 8-bit unsigned integer accumulator. This overflow enables attackers to bypass size validation checks and proceed with processing requests that would otherwise be rejected due to excessive memory requirements.
The operational impact becomes severe during request processing as the system calls get_n(), an internal function lacking bounds checking, once per sub-request to obtain pointers into the fixed 260-byte msg.buf receive buffer. The internal buf_idx advances by up to 248 bytes per call, and subsequent swap_regs() operations write data unconditionally to these pointers. A single maliciously crafted FC 0x14 request from an unauthenticated network client can cause approximately 8490 bytes to be written past the boundaries of the 260-byte buffer, resulting in extensive memory corruption within the server process.
This vulnerability directly maps to CWE-787 Out-of-bounds Write and aligns with ATT&CK technique T1203 Exploitation for Client Execution through the use of malformed network protocols. The potential consequences range from denial of service attacks that crash the embedded system to more severe remote code execution scenarios, particularly affecting embedded and bare-metal targets lacking memory protection mechanisms. The attack surface is significant as the vulnerability requires no authentication, making it accessible to any network client with access to the Modbus server port.
The technical exploitation requires careful crafting of a single FC 0x14 request containing multiple sub-requests that collectively exceed the buffer size limits while maintaining individual request validity. This creates a sophisticated attack vector where the vulnerability manifests through legitimate protocol usage rather than through direct memory manipulation. Organizations using nanoMODBUS in industrial control systems, IoT devices, or embedded applications should immediately evaluate their exposure and implement mitigations including input validation improvements, buffer size restrictions, and network segmentation to prevent unauthorized access to Modbus services.
Mitigation strategies should focus on implementing proper bounds checking for cumulative response sizes, upgrading to patched versions of the library, and deploying network monitoring solutions that can detect anomalous Modbus traffic patterns. The vulnerability demonstrates the importance of validating aggregate data structures rather than individual components, particularly in embedded systems where memory constraints and limited protection mechanisms amplify the impact of such flaws. Security teams should also consider implementing runtime protections and input sanitization measures to prevent exploitation of similar vulnerabilities in other protocol implementations.