CVE-2026-71218: iperf3 Denial of Service Vulnerability

CVE-2026-71218 Overview

A flaw in iperf3 allows a remote unauthenticated attacker to exhaust memory on a target host running the network performance measurement tool. The vulnerability resides in the JSON_read() function, which accepts a peer-controlled message length and allocates memory without enforcing an upper bound [CWE-789]. An attacker who can connect to the iperf3 service can send a crafted size prefix that causes the process to allocate excessive memory. The result is a Denial of Service (DoS) through memory exhaustion, severe slowdown, or termination of the iperf3 service.

Critical Impact
Remote unauthenticated attackers can trigger memory exhaustion against any reachable iperf3 server, disrupting network measurement infrastructure and colocated workloads on the same host.

Affected Products

iperf3 (ESnet) — versions prior to the fix in commit 0128d035
Linux distributions packaging vulnerable iperf3 builds (Red Hat tracking issued)
Any host exposing an iperf3 server socket to untrusted networks

Discovery Timeline

2026-08-11 - CVE-2026-71218 published to NVD
2026-08-11 - Last updated in NVD database

Technical Details for CVE-2026-71218

Vulnerability Analysis

The iperf3 control protocol begins a session by exchanging a JSON parameters block. The server calls JSON_read() to receive the block, reading a 32-bit network-order length prefix followed by that many bytes of JSON payload. The pre-patch implementation trusted the length prefix supplied by the peer and passed it directly to a memory allocation without sanity checking.

A remote attacker who connects to the control port can send an arbitrarily large length value, causing iperf3 to request a correspondingly large buffer. The allocation itself, combined with subsequent read operations, drives the process into memory exhaustion. On resource-constrained hosts the impact extends beyond the iperf3 process to co-tenant services and the operating system.

The weakness is classified as [CWE-789] Memory Allocation with Excessive Size Value. No authentication is required, and the attack requires only network reachability to the iperf3 server socket.

Root Cause

The root cause is the absence of an upper bound on the JSON payload size read from the network. The JSON_read() routine in src/iperf_api.c used the peer-supplied hsize value (converted via ntohl()) directly as the allocation size. There was no check that the value fit a plausible parameters block, and no verification that the length prefix itself was fully received.

Attack Vector

The attack vector is a single TCP connection to the iperf3 control port. The attacker writes a 4-byte big-endian length field set to a large value (for example near 0xFFFFFFFF) as the first bytes of the session. The server-side JSON_read() decodes this value and attempts to allocate hsize + 1 bytes, triggering exhaustion behavior.

// Security patch in src/iperf.h — introduces an upper bound constant
#define UDP_BUFFER_EXTRA 1024

#define MAX_PARAMS_JSON_STRING 8 * 1024

/* constants for command line arg sanity checks */
#define MB (1024 * 1024)
#define MAX_TCP_BUFFER (512 * MB)

// Security patch in src/iperf_api.c — validates read size and enforces bound
     * Then read the JSON into a buffer and parse it.  Return a parsed JSON
     * structure, NULL if there was an error.
     */
-    if (Nread(fd, (char*) &nsize, sizeof(nsize), Ptcp) >= 0) {
-	hsize = ntohl(nsize);
+    rc = Nread(fd, (char*) &nsize, sizeof(nsize), Ptcp);
+    hsize = ntohl(nsize);
+    if (rc == sizeof(nsize) && hsize <= MAX_PARAMS_JSON_STRING) {
 	/* Allocate a buffer to hold the JSON */
 	strsize = hsize + 1;              /* +1 for trailing NULL */
 	if (strsize) {

Source: GitHub iPerf Commit Details

Detection Methods for CVE-2026-71218

Indicators of Compromise

Sudden spikes in resident memory for the iperf3 process, followed by out-of-memory kills or service termination
Inbound TCP sessions to the iperf3 control port (default 5201) from unexpected sources, immediately followed by connection reset
Kernel OOM-killer log entries referencing iperf3 in /var/log/messages or journalctl

Detection Strategies

Monitor process memory growth for iperf3 and alert when RSS exceeds a low fixed threshold, since legitimate parameters blocks are small
Inspect the first four bytes of new connections to port 5201 at a network sensor; values above 0x00002000 (8 KiB) indicate an out-of-spec parameters length
Correlate short-lived TCP sessions to iperf3 ports with subsequent process restarts to identify probing behavior

Monitoring Recommendations

Log all inbound connections to iperf3 listeners and forward them to a central analytics platform for baselining
Track systemd or service manager restart counts for iperf3 units and alert on repeated crashes
Review firewall telemetry for scanning activity against TCP 5201 from untrusted network segments

How to Mitigate CVE-2026-71218

Immediate Actions Required

Restrict network access to the iperf3 control port so only trusted measurement clients can connect, using host firewalls or network ACLs
Stop or disable long-running public iperf3 servers that are not actively required
Upgrade to a distribution package that includes commit 0128d035 or a later fixed release

Patch Information

The upstream fix is available in the ESnet iperf repository as commit 0128d0357b7e8916fe39e980e455729bc0e5fd4e. The patch introduces the MAX_PARAMS_JSON_STRING constant (8 KiB) in src/iperf.h and modifies JSON_read() in src/iperf_api.c to verify that the length prefix was fully received and that hsize does not exceed the maximum. Refer to the Red Hat CVE-2026-71218 advisory and Red Hat Bug Report #2463003 for distribution package status.

Workarounds

Bind iperf3 to loopback or a management VLAN using the -B option instead of exposing it on all interfaces
Run iperf3 on demand from a shell rather than as a persistent daemon or service
Apply per-process memory limits with systemdMemoryMax= or ulimit -v so a single crash cannot destabilize the host

bash

# Configuration example — restrict iperf3 exposure and cap memory
# 1. Bind to a management interface only
iperf3 -s -B 10.0.0.10

# 2. Apply a memory ceiling via systemd drop-in
mkdir -p /etc/systemd/system/iperf3.service.d
cat > /etc/systemd/system/iperf3.service.d/limits.conf <<'EOF'
[Service]
MemoryMax=64M
Restart=on-failure
EOF
systemctl daemon-reload
systemctl restart iperf3

# 3. Firewall the control port to trusted sources
iptables -A INPUT -p tcp --dport 5201 -s 10.0.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 5201 -j DROP