CVE-2026-71217: 
CBL Mariner vulnerability analysis and mitigation

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 affects iperf3 version 3.17.1 and is confirmed present through the inspected current HEAD; Red Hat Enterprise Linux 7, 8, 9, and 10 are listed as affected products. It was reported on April 23, 2026, publicly disclosed on August 11, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (Red Hat CVE, Github Advisory).

The root cause is CWE-20 (Improper Input Validation) in iperf3's get_parameters() function (src/iperf_api.c), which reads peer-controlled numeric fields from the control-channel JSON and assigns them directly to internal test parameters without applying the same bounds checks enforced during CLI parsing. Specifically, fields like parallel and len are accepted without validation against constants such as MAX_STREAMS and MAX_BLOCKSIZE. When the server processes a CREATE_STREAMS request, the oversized parallel value drives excessive stream and thread creation, while an oversized len value causes large per-stream ftruncate()/mmap() calls and heavy readentropy() work, exhausting memory, CPU, and file descriptors. Exploitation requires only network reachability to the iperf3 control port (default TCP 5201) and the ability to send crafted JSON; no authentication is needed unless the server is configured with iperf3 authentication (Red Hat Bugzilla, Red Hat CVE).

Successful exploitation results in a complete loss of availability for the targeted iperf3 server — the service can be rendered degraded or fully unavailable through repeated resource-exhausting requests. There is no demonstrated confidentiality or integrity impact; the vulnerability is scoped to the iperf3 service itself and does not provide code execution or data access. However, because iperf3 is commonly used in network performance testing infrastructure, disruption could affect network diagnostics and monitoring workflows (Red Hat CVE, Red Hat Bugzilla).

No public exploit code or active in-the-wild exploitation has been reported as of the disclosure date. CISA's SSVC assessment classifies the vulnerability as "automatable: yes" with "exploitation: none" currently observed, indicating it could be scripted but has not been weaponized (Red Hat CVE). The EPSS score is approximately 0.33–0.42%, placing it in roughly the 35th percentile for exploitation likelihood within 30 days (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. A Nessus detection plugin (ID 334504) is available for scanning.

1. Reconnaissance: Identify internet-facing or network-accessible iperf3 servers using tools like Shodan or Censys, searching for the default iperf3 control port (TCP 5201). Confirm the server is running without authentication enabled.
2. Craft malicious control-channel JSON: Prepare a modified iperf3 client or a custom TCP client that intercepts and overwrites the parameter JSON before it is sent to the server. Set oversized values such as "parallel": 100000 and "len": 1073741824 (1 GB).
3. Initiate connection and parameter exchange: Connect to the target iperf3 server on TCP 5201 and proceed through the normal control handshake, injecting the crafted JSON during the parameter exchange phase.
4. Trigger resource exhaustion: The server's get_parameters() function accepts the oversized values without bounds checking. During CREATE_STREAMS processing, the server attempts to create 100,000 streams/threads and allocate 1 GB buffers per stream via ftruncate()/mmap(), exhausting memory, CPU, and file descriptors.
5. Sustain DoS: Repeatedly send crafted requests to keep the service degraded or unavailable, as each connection attempt re-triggers the resource-intensive allocation path (Red Hat Bugzilla).

• Network: Unusual or repeated inbound TCP connections to port 5201 from unexpected or untrusted source IPs; high-frequency connection attempts from a single source.
• Process/System: Sudden spike in memory consumption or CPU utilization by the iperf3 server process; large numbers of threads spawned by the iperf3 process visible via ps or top; excessive open file descriptors associated with the iperf3 PID.
• Logs: System logs (/var/log/messages, journalctl) showing ftruncate or mmap failures, out-of-memory (OOM) killer events targeting iperf3, or repeated test abort/reset messages from the iperf3 server.
• File System: Temporary files or shared memory segments of unusually large size created by the iperf3 process in /tmp or /dev/shm (Red Hat Bugzilla).

The upstream fix is available as commit 494dd37 in the esnet/iperf repository, which adds JSON value bounds checks in get_parameters() for fields including parallel and len (iperf commit). Red Hat has acknowledged the issue and patches for affected RHEL versions are expected; users should monitor Red Hat errata for updated iperf3 packages. 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 rules limiting TCP 5201 access), or disabling the iperf3 service entirely if it is not required (Red Hat CVE). Enabling iperf3 authentication (--rsa-private-key-path / --authorized-users-path) also raises the bar for unauthenticated exploitation.

The vulnerability was discovered by AISLE Research in partnership with Red Hat and was initially embargoed to allow upstream coordination before public disclosure (Red Hat CVE). 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 commentary has been identified beyond standard vulnerability database aggregation.