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

CVE-2026-71218 is an unbounded memory allocation vulnerability in iperf3's JSON_read() function that allows a remote unauthenticated attacker to trigger a Denial of Service (DoS) via memory exhaustion. The flaw was discovered by AISLE Research in partnership with Red Hat, reported on April 26, 2026, and publicly disclosed on August 11, 2026. Affected versions include iperf3 as packaged in Red Hat Enterprise Linux 7, 8, 9, and 10 (confirmed affected version: iperf3-3.17.1-5.el10_1). It carries a CVSS v3.1 base score of 5.3 (Medium), assigned by Red Hat as the CNA (Red Hat CVE, GitHub Advisory).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value). In src/iperf_api.c, the JSON_read() function reads a 4-byte big-endian length field directly from the peer-controlled control channel and passes it to calloc() without enforcing any upper bound, allowing allocation of up to ~4 GiB per connection. The vulnerable call path is iperf_accept() → iperf_exchange_parameters() → get_parameters() → JSON_read(). Critically, optional authentication is evaluated only after get_parameters() returns, meaning the unbounded allocation occurs before any authentication check can block the request. The upstream fix (commit 0128d03) introduces a MAX_PARAMS_JSON_STRING constant of 8 KiB and validates that the received size field is both fully read and within this limit before allocating (Red Hat Bugzilla, iperf Commit).

Successful exploitation causes excessive memory consumption in the iperf3 server process, leading to severe performance degradation, service slowdown, or outright process termination via OOM (out-of-memory) kill. The impact is limited to availability — there is no confidentiality or integrity impact, and the vulnerability does not enable code execution or lateral movement. The practical severity depends on the host's memory overcommit policy and whether container or process memory limits are enforced (Red Hat CVE, Red Hat Bugzilla).

No public exploit code or exploit kit integration has been reported as of the disclosure date. CISA's SSVC assessment (added August 11, 2026) classifies exploitation as "none" currently, though the attack is rated "automatable" due to the lack of authentication requirements. The EPSS score is 0.00314 (~0.3%), indicating low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Red Hat CVE, GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible hosts running iperf3 in server mode (default port TCP 5201) using tools like Shodan, Censys, or nmap (nmap -p 5201 <target>).
2. Establish control connection: Connect to the iperf3 control port (TCP 5201) and send a valid 37-byte cookie (36 bytes + null terminator) to initiate the control channel handshake, as required by the iperf3 protocol.
3. Send oversized length field: Immediately after the cookie, transmit a 4-byte big-endian integer representing a very large JSON message length (e.g., 0x10000000 for 256 MiB) using struct.pack('!I', 256*1024*1024).
4. Send matching payload: Follow the length field with a syntactically valid JSON payload of the declared size (e.g., { + spaces + }) to satisfy the Nread() call and trigger the full calloc() allocation.
5. Observe impact: Monitor the server's memory usage via top, ps, or container metrics — the server process will attempt to allocate the declared amount of memory, causing slowdown, OOM termination, or service disruption depending on available system memory (Red Hat Bugzilla).

• Network: Unexpected or repeated inbound TCP connections to port 5201 from untrusted or external IP addresses; connections that send a 37-byte cookie followed immediately by a large 4-byte length value and a large data payload without completing a legitimate iperf3 test.
• Process: Sudden spike in memory usage of the iperf3 process visible in top or ps; OOM killer events in system logs (dmesg or /var/log/messages) referencing the iperf3 process.
• Logs: System journal entries (journalctl) showing iperf3 process termination or restart; kernel OOM messages such as Out of memory: Kill process [PID] (iperf3).
• File System: Core dump files generated by an OOM-killed iperf3 process in the working directory or configured core dump path.

A patch has been committed upstream to the esnet/iperf repository (commit 0128d03), which caps the accepted JSON control message size at 8 KiB (MAX_PARAMS_JSON_STRING = 8 * 1024) and validates the size field is fully received before allocation. Packaged fixes for Red Hat Enterprise Linux distributions were not yet released as of the disclosure date. Until a patched package is available, Red Hat recommends restricting network access to the iperf3 control port (TCP 5201) using firewall rules so only trusted clients can connect. Additionally, running iperf3 within environments that enforce process or container memory limits (e.g., cgroups, Kubernetes resource limits) can contain the impact. Note that enabling iperf3 authentication is not a sufficient mitigation, as the vulnerable allocation occurs before authentication is evaluated (Red Hat CVE, iperf Commit).

Red Hat, acting as the CNA, assigned and disclosed this vulnerability and credited AISLE Research (in partnership with Red Hat) for discovery. The Red Hat advisory explicitly notes that authentication is insufficient as a mitigation, which is a notable operational clarification for administrators who may assume iperf3's optional auth feature provides protection. No significant broader media coverage or notable researcher commentary beyond the official advisory and bugzilla report has been identified as of the disclosure date (Red Hat CVE, Red Hat Bugzilla).