CVE-2026-71254: nanoMODBUS RCE Vulnerability

CVE-2026-71254 Overview

CVE-2026-71254 is an out-of-bounds write vulnerability in the nanoMODBUS library through version v1.23.0. The flaw resides in the server-side handle_read_file_record() function that processes Modbus function code 0x14 (Read File Record) in nanomodbus.c. An unauthenticated network attacker can send a single crafted Modbus request that writes up to approximately 8490 bytes past the end of a 260-byte receive buffer. The root cause is a uint8_t accumulator that silently overflows when computing the cumulative response size across sub-requests. nanoMODBUS is widely deployed on embedded and bare-metal targets, where the absence of memory protection increases the likelihood that memory corruption escalates to remote code execution.

Critical Impact
A single unauthenticated Modbus request can corrupt server memory, producing denial of service and potential remote code execution on embedded devices running nanoMODBUS through v1.23.0.

Affected Products

nanoMODBUS library, all releases through v1.23.0
Modbus server implementations built on nanoMODBUS handling FC 0x14 (Read File Record)
Embedded and bare-metal devices linking the vulnerable nanomodbus.c without memory protection

Discovery Timeline

2026-08-05 - CVE-2026-71254 published to the National Vulnerability Database (NVD)
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-71254

Vulnerability Analysis

The defect is classified as an out-of-bounds write [CWE-787] in the Modbus Read File Record handler. handle_read_file_record() validates two per-request limits: the total request size must not exceed 245 bytes, and each sub-request's record_length must be at most 124. It never validates the cumulative response size across all sub-requests before processing them.

The function tracks the running response size in an accumulator named response_data_size, declared as uint8_t. For each sub-request the code adds 2 + record_length * 2. With the maximum of 35 sub-requests at record_length = 124, the true cumulative demand is 8750 bytes. That value cannot fit in a uint8_t, so the accumulator wraps around and any downstream size check based on it passes.

A subsequent loop calls get_n() 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. get_n() performs no bounds checking. swap_regs() then writes to that pointer unconditionally, producing writes far outside the receive buffer.

Root Cause

The root cause is an incorrect data type for the size accumulator combined with missing cumulative validation. Individual per-sub-request limits are enforced, but the aggregate arithmetic overflows a uint8_t. The truncated value is then trusted by later code paths, so the loop iterates 35 times and writes well past the receive buffer.

Attack Vector

An unauthenticated attacker with network reachability to the Modbus TCP server sends one crafted FC 0x14 request. The request contains 35 sub-requests, each with record_length = 124, while keeping the total request under the 245-byte check. The server accepts the frame, the uint8_t accumulator wraps, and roughly 8490 bytes are written out of bounds. Adjacent stack or heap structures are corrupted, causing crashes on hardened platforms and enabling potential remote code execution on embedded targets without a memory management unit.

No verified public exploit code is available. The vulnerability mechanism is documented in the nanoMODBUS source at nanomodbus.c on GitHub.

Detection Methods for CVE-2026-71254

Indicators of Compromise

Inbound Modbus TCP frames on port 502 carrying function code 0x14 with a sub-request count near 35 and record_length values at or near 124.
Unexpected restarts, watchdog resets, or crash logs on embedded devices immediately after receiving a Modbus Read File Record request.
Memory corruption artifacts such as corrupted task control blocks, stack canary violations, or heap metadata errors in device diagnostics.

Detection Strategies

Deploy a Modbus-aware deep packet inspection rule that parses FC 0x14 requests and flags any frame where the sum of 2 + record_length * 2 across sub-requests exceeds 250 bytes.
Alert on Modbus requests with more than a small number of sub-requests within a single FC 0x14 frame, since legitimate clients rarely issue maximum-size batched reads.
Correlate Modbus traffic anomalies with device availability telemetry to surface probe-then-crash patterns typical of exploitation attempts.

Monitoring Recommendations

Log all Modbus TCP sessions at the perimeter of operational technology (OT) segments and retain full payloads for FC 0x14 requests.
Baseline the set of clients that legitimately issue Read File Record commands and alert on new source addresses.
Monitor embedded device uptime and reboot counters; sudden clusters of reboots on nanoMODBUS-based devices warrant investigation.

How to Mitigate CVE-2026-71254

Immediate Actions Required

Inventory all devices and firmware images that embed nanoMODBUS and confirm the library version against v1.23.0.
Restrict Modbus TCP exposure to trusted management networks using firewall rules or OT segmentation, and block port 502 from untrusted networks.
Disable FC 0x14 (Read File Record) handling in the server build if the application does not require it.
Rate-limit and inspect Modbus traffic to affected devices while a fixed build is prepared.

Patch Information

No fixed release is referenced in the NVD entry at publication. Track the upstream project at the nanoMODBUS repository for a corrected version. Any fix must widen the response_data_size accumulator beyond uint8_t, validate the cumulative response size before entering the sub-request loop, and add bounds checking inside get_n() against the msg.buf length.

Workarounds

Apply a local source patch that changes response_data_size to uint16_t (or larger) and rejects requests whose cumulative response size exceeds the receive buffer.
Add a defensive check inside get_n() to fail closed if buf_idx + n exceeds the buffer length.
Place vulnerable devices behind a Modbus-aware gateway that normalizes or drops FC 0x14 requests with more than a safe sub-request count.
Where feasible, enable memory protection or stack canaries in the toolchain to convert corruption into a controlled fault.

bash

# Example firewall rule to restrict Modbus TCP to a trusted management host
iptables -A INPUT -p tcp --dport 502 -s 10.10.0.25 -j ACCEPT
iptables -A INPUT -p tcp --dport 502 -j DROP