CVE-2025-54350 Overview
CVE-2025-54350 is a denial-of-service vulnerability in iperf3 versions before 3.19.1. The flaw resides in iperf_auth.c, where the Base64Decode function triggers an assertion failure when it receives malformed authentication data. A remote attacker can send a crafted authentication request to force the server process to exit, terminating active measurement sessions and blocking new connections. The issue is tracked under CWE-617: Reachable Assertion. The iperf3 project, maintained by ESnet, addressed the flaw in release 3.19.1 by removing the reliance on assert() for handling untrusted input.
Critical Impact
Unauthenticated remote attackers can crash the iperf3 server process by submitting malformed Base64 authentication payloads, causing service disruption on any host exposing an authenticated iperf3 endpoint.
Affected Products
- ESnet iperf3 versions prior to 3.19.1
- Debian LTS distributions shipping vulnerable iperf3 packages
- Any Linux, macOS, or FreeBSD host running iperf3 with authentication enabled
Discovery Timeline
- 2025-08-03 - CVE-2025-54350 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-54350
Vulnerability Analysis
The vulnerability exists in the authentication handling code path of iperf3, specifically inside src/iperf_auth.c. When iperf3 operates in authenticated mode, the server decodes a Base64-encoded credential blob received from the client. The Base64Decode routine used assert() calls to validate the structure and length of the input. Assertions abort the process when they fail, which is appropriate for internal invariants but unsafe when applied to attacker-controlled data. A malformed authentication attempt triggers the assertion, and the iperf3 daemon terminates immediately. Because no authentication is required to send the malformed payload, any network-reachable attacker can repeatedly crash the service. This affects long-running measurement infrastructure, research testbeds, and CI network validation pipelines that depend on iperf3 availability.
Root Cause
The root cause is improper input validation combined with the use of assert() on untrusted data. assert() statements are compiled into release binaries by default in the iperf3 build and abort the process on failure. When Base64 input violates expected format constraints, the assertion trips and the daemon exits rather than returning an error to the caller.
Attack Vector
The attack vector is network-based and requires no privileges or user interaction. An attacker sends a TCP connection to an iperf3 server started with the --rsa-private-key-path and --authorized-users-path options, then transmits a malformed Base64 credential blob during the authentication handshake. The server process terminates on the failed assertion.
// Patch excerpt from src/iperf_auth.c (iperf3 3.19.1)
#include "iperf_config.h"
#include <string.h>
-#include <assert.h>
#include <time.h>
#include <sys/types.h>
/* FreeBSD needs _WITH_GETLINE to enable the getline() declaration */
Source: esnet/iperf commit 4eab661. The patch removes the <assert.h> include and replaces assertion-based validation with graceful error returns, preventing malformed input from aborting the process.
Detection Methods for CVE-2025-54350
Indicators of Compromise
- Unexpected termination of the iperf3 server process shortly after inbound connections from untrusted sources
- SIGABRT signals recorded against the iperf3 binary in system logs, dmesg, or journalctl
- Core dumps referencing Base64Decode in iperf_auth.c stack frames
- Repeated short-lived TCP connections to the iperf3 control port (default 5201) followed by service restart events
Detection Strategies
- Monitor process lifecycle telemetry for iperf3 abnormal exits, correlating with preceding network connections
- Inspect authentication handshake payloads on port 5201 for Base64 strings that fail standard decoding
- Alert on repeated iperf3 service restart events on hosts exposing the daemon
Monitoring Recommendations
- Enable systemd Restart= policies with rate limiting to surface repeated crash cycles rather than silently masking them
- Forward host process, crash, and syslog data to a centralized analytics platform for correlation across measurement fleet nodes
- Track outbound and inbound connections to TCP/5201 in network flow logs to identify probing activity
How to Mitigate CVE-2025-54350
Immediate Actions Required
- Upgrade iperf3 to version 3.19.1 or later on all servers and clients
- Apply the Debian LTS security update where applicable via apt upgrade iperf3
- Restrict access to the iperf3 control port (TCP/5201) using host or network firewalls to trusted measurement sources
- Audit systems for exposed iperf3 daemons that were unintentionally left running
Patch Information
The fix is available in iperf3 release 3.19.1. See the GitHub release notes for 3.19.1 and the upstream commit 4eab661. Debian users should reference the Debian LTS announcement for backported package versions.
Workarounds
- Disable authenticated mode by omitting --rsa-private-key-path and --authorized-users-path if authentication is not required
- Run iperf3 under a process supervisor such as systemd with automatic restart to reduce downtime while patching
- Bind iperf3 to loopback or a management interface using --bind to limit network exposure until the patch is applied
# Upgrade iperf3 on Debian-based distributions
sudo apt update
sudo apt install --only-upgrade iperf3
iperf3 --version # verify version is 3.19.1 or later
# Restrict access to trusted subnets while patching
sudo iptables -A INPUT -p tcp --dport 5201 ! -s 10.0.0.0/8 -j DROP
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
