High priorityDisclosed

Advisory · CVE-2026-102253

iperf3 UDP worker can be locked in an infinite loop by one packet exchange

iperf3 before 3.22 crashes its UDP receive worker into an unrecoverable infinite loop when it receives a crafted control-channel parameter message followed by a single 16-byte UDP datagram, pinning a thread at 100 percent CPU until SIGKILL.

Advisory published September 29, 2026Independent summary
Vendor
ESnet
Product
iperf3
Identifier / CWE
CVE-2026-102253
CWE-835
Action timing
Immediate
ELI5

Explain it like I’m five

iperf3 listens for network tests. A stranger sends it one confusing setup message and one tiny packet, and the worker that receives UDP data starts spinning in circles forever, eating a whole CPU core and ignoring every attempt to shut it down politely.

SIMPLIFIED_ATTACK_PATH04 STEPS
  1. 01Unauthenticated control message

    An attacker sends a crafted control-channel parameter message to the iperf3 server.

  2. 02Single UDP datagram

    One 16-byte UDP datagram follows on the data channel.

  3. 03Worker loops

    The per-stream UDP receive worker enters an unrecoverable infinite loop (CWE-835).

  4. 04CPU pinned

    The thread sits at roughly 100 percent CPU until the process is forcibly killed with SIGKILL.

What happened

A denial-of-service vulnerability was disclosed in iperf3. Versions before 3.22 allow an unauthenticated remote attacker to crash-loop the server’s UDP receive worker into an unrecoverable infinite loop by sending a single crafted control-channel parameter message followed by one 16-byte UDP datagram. The affected per-stream receive thread is permanently pinned at approximately 100 percent CPU and the process does not respond to normal control-channel closure. It carries a CVSS 4.0 score of 8.7 (high).

What to do

  1. Upgrade iperf3 to 3.22 or later.
  2. Restrict network access to iperf3 servers: they should only be reachable from trusted measurement endpoints.
  3. Monitor iperf3 hosts for single threads pinned at 100 percent CPU with unresponsive UDP workers.
  4. Restart affected servers with SIGKILL and confirm worker threads exit cleanly after the upgrade.

Management note

iperf3 servers are usually left running and forgotten on measurement hosts, which makes a one-packet denial of service disproportionately annoying. This is an availability issue only, so the priority is patching and access control, not data forensics.