CVE-2026-101283 in iperf3
Summary
by MITRE • 10/01/2026
iperf3 3.20–3.21 (esnet/iperf) has a pre-auth heap buffer overflow in decrypt_rsa_message(): a 256-byte RSA buffer is BIO_read with the attacker-controlled ciphertext length (guard warns only), so an unauthenticated client overflows the heap via an oversized authtoken; fixed in 3.22
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/01/2026
The vulnerability identified in iperf versions 3.20 through 3.21 represents a critical pre-authentication heap buffer overflow located within the decrypt_rsa_message function of the esnet/iperf codebase. This flaw arises from an insufficient validation mechanism when processing RSA-encrypted authentication tokens during the initial handshake phase of the connection establishment process. Specifically, the application allocates a fixed-size 256-byte buffer on the heap to hold decrypted data but relies solely on a guard check that warns rather than strictly validates or bounds the input length derived from attacker-controlled ciphertext parameters. This architectural oversight allows an unauthenticated client to supply an oversized authtoken that exceeds the allocated memory capacity, resulting in a write operation beyond the boundaries of the designated buffer region.
From a technical perspective, this issue is classified under CWE-120, which denotes Buffer Copy without Checking Size of Input Classic Buffer Overflow. The root cause lies in the failure to enforce strict length constraints on input data prior to copying it into fixed-size memory structures. In the context of iperf3, the RSA decryption routine expects a ciphertext that corresponds to an authentication token of predictable size. However, because the implementation does not rigorously verify that the decrypted output or the source ciphertext fits within the 256-byte limit before performing the BIO_read operation, it permits arbitrary-length data writes into a constrained heap allocation. This type of memory corruption is particularly dangerous as it can lead to control flow hijacking if an attacker carefully crafts the overflow payload to overwrite adjacent heap metadata or function pointers, potentially achieving remote code execution on the target system running iperf3.
The operational impact of this vulnerability is severe due to its pre-authentication nature and network accessibility. Since the exploit does not require prior authentication credentials, any external actor with network connectivity to the iperf3 service can attempt exploitation without needing valid user accounts or tokens. This significantly lowers the barrier for entry compared to post-exploitation attacks that rely on compromised credentials. Successful exploitation could allow an attacker to execute arbitrary code within the context of the process running iperf3, potentially leading to full system compromise depending on the privileges under which the service operates. Furthermore, even if remote code execution is not achieved, heap corruption can cause application crashes or instability, resulting in a denial-of-service condition that disrupts network performance testing activities for legitimate users.
In terms of threat modeling and industry standards, this vulnerability aligns with MITRE ATT&CK technique T1190, Exploit Public-Facing Application, as it targets a service exposed to networks where adversaries can interact directly. The attack vector is classified as Network (ATT&CK T1078) combined with Initial Access via Vulnerability in Software (T1195). Defense-in-depth strategies should prioritize immediate patching of the iperf3 software to version 3.22 or later, where this logic error has been corrected by implementing proper bounds checking and input validation before memory operations occur. Additionally, administrators should restrict access to iperf3 services using firewall rules or network segmentation to limit exposure to untrusted networks until patches are applied. Monitoring for anomalous connection patterns involving unusually large authentication payloads can also serve as a temporary detection mechanism for exploitation attempts in environments where immediate patching is not feasible.