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

CVE-2026-71218 is an unbounded memory allocation vulnerability in iperf3's JSON_read() function that allows a remote unauthenticated attacker to trigger excessive memory consumption, leading to a Denial of Service (DoS). The flaw was discovered by AISLE Research in partnership with Red Hat 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 calls calloc() with that size plus one, without enforcing any upper bound on the allocation. The vulnerable call path is iperf_accept() → iperf_exchange_parameters() → get_parameters() → JSON_read(). Critically, optional authentication is evaluated only after get_parameters() completes, meaning the unbounded allocation occurs before any authentication check can prevent it. The upstream fix (commit 0128d03) adds a MAX_PARAMS_JSON_STRING constant of 8 KiB (8 * 1024) and validates that the received size field is both fully read and does not exceed this limit before allocating (Red Hat Bugzilla, iperf Commit).

Successful exploitation causes availability impact only — there is no confidentiality or integrity impact. An unauthenticated remote attacker can force the iperf3 server process to allocate arbitrarily large amounts of memory (e.g., 256 MiB or more per connection), resulting in severe memory pressure, significant service slowdown, or outright process termination via OOM kill. The impact is scoped to the iperf3 service itself and does not enable lateral movement, code execution, or data exfiltration; however, repeated exploitation can render the service persistently unavailable (Red Hat CVE, Red Hat Bugzilla).

No public exploit code or exploit kit integration has been reported, and CISA's SSVC assessment (as of August 11, 2026) classifies exploitation status as "none" with no evidence of in-the-wild exploitation. However, CISA notes the vulnerability is "automatable" with partial technical impact, meaning it can be triggered at scale without manual interaction. The EPSS score is approximately 0.31–0.38%, placing it in roughly the 31st percentile for exploitation likelihood within 30 days. No threat actor attribution has been reported. The vulnerability is detectable by Nessus (plugin 334498) and Qualys (detection ID 6285578) (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: Open a TCP connection to the iperf3 server on port 5201. The server expects an initial 37-byte cookie (36 bytes + null terminator) as part of the control-channel handshake.
3. Send crafted cookie: Transmit a valid-format cookie (e.g., 36 A bytes followed by a null byte) to satisfy the initial handshake step and reach the JSON_read() call path.
4. Send oversized length field: Immediately after the cookie, send a 4-byte big-endian integer representing a very large allocation size (e.g., struct.pack('!I', 256*1024*1024) for 256 MiB).
5. Send matching payload: Follow the length field with a syntactically valid JSON payload of the declared size (e.g., { + spaces padded to size - 2 + }) to ensure calloc() is called and the read proceeds.
6. Observe impact: Monitor the server's memory usage via top, ps, or container metrics. Depending on system memory and overcommit settings, the server will experience severe slowdown or be terminated by the OOM killer. Repeat connections amplify the effect (Red Hat Bugzilla).

• Network: Unexpected or repeated inbound TCP connections to port 5201 from untrusted or external IP addresses; connections that send a large initial data burst immediately after the cookie exchange without performing a legitimate bandwidth test.
• Process: iperf3 server process (iperf3 -s) exhibiting rapidly growing RSS/VSZ memory consumption visible in top or ps aux; iperf3 process being killed by the OOM killer (visible in kernel logs).
• Logs: Kernel OOM killer messages in /var/log/messages or dmesg referencing the iperf3 process (e.g., Out of memory: Kill process <pid> (iperf3)); iperf3 server restart events in systemd journal (journalctl -u iperf3).
• System: Sudden spikes in system memory utilization coinciding with iperf3 connection events; container or cgroup memory limit breach events if iperf3 is running in a containerized environment (Red Hat Bugzilla, Red Hat CVE).

The upstream fix is available in iperf commit 0128d03, which adds a MAX_PARAMS_JSON_STRING cap of 8 KiB and validates the received size before allocation; users should update to a patched iperf3 package once available from their distribution. As an immediate workaround, restrict network access to the iperf3 control port (TCP 5201) using firewall rules so only trusted clients can connect — note that authentication alone is not sufficient because the vulnerable allocation occurs before authentication is evaluated. Additionally, run the iperf3 service within environments that enforce process or container memory limits (e.g., systemd MemoryMax=, cgroup limits, or container resource constraints) to contain the impact of any exploitation attempt (Red Hat CVE, iperf Commit).

Red Hat, acting as the CNA, assigned the vulnerability and published the advisory on August 11, 2026, crediting AISLE Research (in partnership with Red Hat) for discovery. The Bugzilla report notes the issue was flagged as "Important" internally due to the unauthenticated remote DoS potential, though the CVSS score reflects a Medium severity given the limited scope of impact. No significant broader media coverage or notable researcher commentary beyond the official advisory and vulnerability database entries has been identified at this time (Red Hat CVE, Red Hat Bugzilla).