CVE-2026-71217: 
Linux Red Hat Analyse et atténuation des vulnérabilités

CVE-2026-71217 is an improper input validation vulnerability in iperf3 that allows a remote, unauthenticated attacker to cause a Denial of Service (DoS) by sending crafted control-channel JSON messages with oversized numeric parameters such as parallel and len. The flaw was reported on April 23, 2026 (under embargo) and publicly disclosed on August 11, 2026. Affected versions include iperf3 3.17.1 and likely earlier releases; Red Hat Enterprise Linux 7, 8, 9, and 10 are all listed as affected. It carries a CVSS v3.1 base score of 7.5 (High) (Red Hat Advisory, Github Advisory).

The root cause is CWE-20 (Improper Input Validation) in iperf3's get_parameters() function (src/iperf_api.c). When the server receives control-channel JSON from a connecting client, it assigns peer-supplied numeric fields such as parallel and len directly to internal test parameters without applying the same bounds checks enforced during CLI parsing (e.g., MAX_STREAMS, MAX_BLOCKSIZE). During CREATE_STREAMS processing, the server calls iperf_new_stream(), which uses the unvalidated len value to size per-stream buffers via ftruncate() and mmap(), and uses parallel to determine how many streams and worker threads to create. An attacker can exploit this by connecting to an exposed iperf3 server and submitting JSON such as "parallel": 100000 and "len": 1073741824 during the normal parameter exchange handshake, triggering massive memory allocations, heavy readentropy() CPU work, and excessive thread creation. No authentication is required unless the server has explicitly enabled iperf3's optional authentication feature (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation results in a high availability impact against the iperf3 server process: oversized parallel and len values drive excessive stream and thread creation, large per-stream buffer allocations, and heavy CPU consumption via readentropy(), which can render the service unavailable. An attacker can repeatedly trigger resource-intensive or failing tests to keep the service degraded or fully unavailable. There is no demonstrated confidentiality or integrity impact; the scope is limited to the iperf3 service itself (Red Hat Bugzilla, Red Hat Advisory).

No public exploit code or exploit kit has been identified at this time, and there is no evidence of in-the-wild exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.33%, indicating a low near-term probability of exploitation. Exploitation requires only network reachability to an exposed iperf3 server and the ability to send crafted control-channel JSON — no credentials or user interaction are needed when authentication is not configured (Feedly, Red Hat Bugzilla).

1. Reconnaissance: Identify internet-facing or network-accessible iperf3 servers (default port TCP 5201) using tools such as Shodan, Censys, or nmap (nmap -p 5201 <target>).
2. Verify server accessibility: Confirm the server is running iperf3 without authentication enabled by attempting a standard connection (iperf3 -c <target>).
3. Craft malicious control-channel JSON: Modify an iperf3 client or write a custom TCP client that intercepts and replaces the parameter JSON sent during the control handshake, injecting oversized values such as "parallel": 100000 and "len": 1073741824.
4. Initiate connection and send crafted parameters: Connect to the server on port 5201 and transmit the crafted JSON during the parameter exchange phase (before CREATE_STREAMS).
5. Trigger resource exhaustion: The server's get_parameters() function accepts the oversized values without bounds checking, causing iperf_new_stream() to attempt massive ftruncate()/mmap() allocations per stream, heavy readentropy() CPU work, and excessive thread creation.
6. Repeat to sustain DoS: Send repeated crafted connections to keep the server's memory, CPU, and thread resources exhausted, preventing legitimate clients from using the service (Red Hat Bugzilla).

• Network: Repeated inbound TCP connections to port 5201 from unexpected or untrusted source IPs; connections that establish the control channel but do not complete normal test flows.
• Process: Abnormally high number of threads spawned by the iperf3 server process; iperf3 process consuming excessive CPU or memory as observed via top, htop, or system monitoring tools.
• Logs: System logs (/var/log/messages, dmesg) showing out-of-memory (OOM) events or failed mmap()/ftruncate() calls attributed to the iperf3 process; iperf3 server output showing repeated test abort or reset events.
• File System: Unusually large temporary files or shared memory segments created by the iperf3 process in /tmp or /dev/shm corresponding to oversized buffer allocations.

An upstream patch has been committed to the esnet/iperf repository (commit 494dd37) that adds JSON value bounds checks in get_parameters() for parameters including parallel and len, enforcing the same limits applied during CLI parsing (iperf commit). Users should update to a patched version of iperf3 once available from their distribution or upstream. As an immediate workaround, Red Hat recommends restricting network access to the iperf3 server to trusted clients or networks using firewall rules (e.g., firewalld or iptables), and disabling the iperf3 service entirely if it is not required (Red Hat Advisory). Enabling iperf3's optional authentication feature also raises the bar for unauthenticated exploitation.

The vulnerability was discovered by AISLE Research in partnership with Red Hat and reported through coordinated disclosure, with an embargo period to allow upstream time to develop a fix before public release (Red Hat Bugzilla). The upstream fix was credited to contributor swlars with acknowledgment to Dirk Müller for directing attention to the issue (iperf commit). No significant broader media coverage or notable social media discussion has been identified at this time.