iperf3 CVE-2026-101283

Exploitable only against an iperf3 server (3.20 or 3.21) explicitly started in RSA-authentication mode - i.e., launched with --rsa-private-key-path and --authorized-users-path so that decrypt_rsa_message() processes client-supplied authtokens. Default iperf3 servers run WITHOUT authentication and never reach the vulnerable code path, so they are not affected. Within auth-enabled deployments there are no further limiters: the overflow occurs before credential validation, so the attacker needs no valid account (PR:N) and no user interaction (UI:N), only network reachability to the listening port. Primary limiting factor is the rarity of the opt-in authentication configuration; secondary is the general difficulty of turning a heap overflow into reliable code execution.

Signals are mixed and must be read together. The vendor CVSS 4.0 base of 9.2 (AV:N/AC:L/AT:P/PR:N/UI:N with VC:H/VI:H/VA:H) reflects a network-reachable, pre-authentication heap overflow yielding full technical impact - genuinely severe on paper. The AT:P (Attack Requirements: Present) metric is the key qualifier: exploitation is NOT possible against a default iperf3 server, because the vulnerable decrypt_rsa_message() path is only reached when the server is explicitly started in optional RSA-authentication mode (--rsa-private-key-path + --authorized-users-path). iperf3 authentication is opt-in and uncommon, so the real-world exposed population is a small subset of installs. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no signal of active or imminent mass exploitation; treat exploitation status as 'no public exploit identified at time of analysis'. There is also a semantic tension worth verifying: the flaw is described as 'pre-auth' (overflow occurs during authtoken decryption before credential validation, hence PR:N), yet it is only reachable when the operator has enabled authentication - 'unauthenticated attacker against an auth-enabled server.' Net: a high-severity memory-corruption bug that is a real priority for the minority of deployments running iperf3 as an auth-enabled server, but low practical risk for the vast default-config majority.

An organization exposes an iperf3 server started in RSA-authentication mode (e.g., a shared throughput-test endpoint requiring credentials). An unauthenticated attacker who can reach the listening port sends a connection with an oversized RSA authtoken; the server BIO_reads the attacker-controlled ciphertext length into a fixed 256-byte heap buffer (the length guard only logs a warning), corrupting the heap and potentially achieving remote code execution as the iperf3 process. No public exploit code is identified at time of analysis, and reliable heap-overflow-to-RCE weaponization is non-trivial.