What is the CVSS score of CVE-2026-71263?

CVE-2026-71263 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. EPSS exploitation probability: 0.3%.

Which versions of FreeModbus are affected by CVE-2026-71263?

FreeModbus LINUXTCP demo port (CVE-2026-71263, CVSS 9.1) contains a critical buffer overflow allowing remote, unauthenticated attackers to corrupt parser state and cause denial of service.

How to fix or mitigate CVE-2026-71263?

Within 24 hours: conduct network inventory to identify all systems running FreeModbus cwalter-at fork with LINUXTCP port enabled, confirm exposure status, and immediately network-isolate any publicly or untrusted-network-accessible instances. Within 7 days: implement network access controls restricting Modbus TCP port 502 to designated trusted hosts only using firewall rules; deploy inline or reverse-proxy-based MBAP frame validation to reject frames declaring Length ≥ 263 bytes; enable network segmentation to prevent lateral movement from compromised systems. Within 30 days: replace FreeModbus with an actively maintained Modbus TCP library with complete patch coverage, or perform code hardening of xMBPortTCPPool() validation logic to use '>=' instead of '>' operator if continued use is unavoidable; complete security assessment of all systems that were exposed during the 24-hour inventory window.

FreeModbus CVE-2026-71263

EUVD-2026-53348 CRITICAL

Out-of-bounds Write (CWE-787)

2026-08-05 TuranSec

GHSA-cjvm-2pqq-6v6h

Buffer Overflow Memory Corruption Freemodbus

9.1

CVSS 3.1 · Vendor: TuranSec

Severity by source

Vendor (TuranSec) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

vuln.today AI

8.2 HIGH

Remote, unauthenticated, single-packet trigger (AV:N/AC:L/PR:N/UI:N); bounded 7-byte overflow into one adjacent static var gives limited integrity impact (I:L) but reliable crash/DoS (A:H), no data disclosure (C:N).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (TuranSec).

CVSS VectorVendor: TuranSec

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 05, 2026 - 13:33 vuln.today

CVE Published

Aug 05, 2026 - 12:26 cve.org

CRITICAL 9.1

DescriptionCVE.org

The LINUXTCP port of FreeModbus contains an off-by-one bounds check in xMBPortTCPPool() (demo/LINUXTCP/port/porttcp.c). The check if (usTCPFrameBytesLeft > MB_TCP_BUF_SIZE) uses a strict greater-than comparison instead of greater-than-or-equal against the 263-byte MB_TCP_BUF_SIZE limit. An MBAP frame with a Length field of 264 makes usTCPFrameBytesLeft equal to 263, which passes the flawed check, and the subsequent recv() call writes up to 263 bytes starting at buffer offset 7 into the 263-byte static buffer aucTCPBuf, overflowing it by 7 bytes into the adjacent static variable usTCPBufPos. A single crafted, unauthenticated Modbus TCP packet triggers the overflow, since Modbus has no built-in authentication.

AnalysisAI

Out-of-bounds write in the LINUXTCP demo port of FreeModbus (cwalter-at fork) lets a remote, unauthenticated attacker overflow the static aucTCPBuf receive buffer by sending a single crafted Modbus TCP (MBAP) frame. Because the xMBPortTCPPool() length validation uses a strict '>' instead of '>=' against the 263-byte MB_TCP_BUF_SIZE, a frame declaring Length 264 passes the check and recv() writes 7 bytes past the buffer into the adjacent usTCPBufPos variable, corrupting parser state. CVSS is 9.1 (I:H/A:H); there is no public exploit identified at time of analysis and it is not on CISA KEV.

Technical ContextAI

FreeModbus is an open-source implementation of the Modbus RTU/ASCII/TCP protocol stack widely embedded in industrial and IoT device firmware. The flaw lives in the reference LINUXTCP transport port (demo/LINUXTCP/port/porttcp.c), which buffers incoming Modbus Application Protocol (MBAP) frames into a fixed 263-byte static buffer aucTCPBuf. Modbus TCP frames carry a 7-byte MBAP header (transaction ID, protocol ID, length, unit ID) followed by the PDU; the code reads the header-declared Length field to size the remaining recv(). The root cause is CWE-787 (out-of-bounds write) caused by a classic off-by-one boundary error: 'if (usTCPFrameBytesLeft > MB_TCP_BUF_SIZE)' should be '>=', so the maximum-plus-one case where usTCPFrameBytesLeft equals 263 slips through and recv() writes starting at offset 7, exceeding the 263-byte capacity by 7 bytes into the adjacent static usTCPBufPos.

RemediationAI

No vendor-released patch identified at time of analysis. The correct fix is to change the bounds check in xMBPortTCPPool() from 'if (usTCPFrameBytesLeft > MB_TCP_BUF_SIZE)' to '>=', or equivalently to reject any MBAP frame whose declared Length would make usTCPFrameBytesLeft reach or exceed MB_TCP_BUF_SIZE (263) before the recv() call; rebuild affected firmware from the corrected source at https://github.com/cwalter-at/freemodbus/blob/master/demo/LINUXTCP/port/porttcp.c. Where patching is not immediately possible, restrict network exposure of the Modbus TCP service (default port 502) with firewall rules so only trusted control-network hosts can connect, and place the device behind a Modbus-aware gateway or IDS that drops MBAP frames with a Length field larger than the protocol maximum (253 for the PDU / 260 total) - the trade-off is that any legitimate over-length client traffic is dropped, but well-formed Modbus never needs Length 264. Network segmentation of OT/ICS assets away from general IT and the internet is the primary compensating control given Modbus lacks authentication.