CVE-2025-24356: Fastd VPN Daemon DoS Vulnerability

CVE-2025-24356 Overview

CVE-2025-24356 is an Amplification Attack vulnerability in fastd, a VPN daemon that tunnels IP packets and Ethernet frames over UDP. The vulnerability exists in the "fast reconnect" mechanism, where receiving a data packet from an unknown IP address/port combination causes fastd to initiate a reconnect by sending a handshake packet. This design flaw allows attackers to use fastd instances as amplifiers in Distributed Denial of Service (DDoS) attacks by sending minimal UDP packets with spoofed source addresses.

Critical Impact

A 1-byte UDP packet can trigger a ~150 byte handshake response, resulting in a 12-13x amplification factor that can be leveraged for DDoS attacks against arbitrary targets.

Affected Products

• fastd_project fastd (versions prior to v23)

Discovery Timeline

• January 27, 2025 - CVE-2025-24356 published to NVD
• August 27, 2025 - Last updated in NVD database

Technical Details for CVE-2025-24356

Vulnerability Analysis

The vulnerability resides in fastd's connection handling logic, specifically in the "fast reconnect" feature designed to improve user experience when peers change network addresses. When fastd receives a data packet from an unrecognized source, it assumes an existing peer has migrated to a new address and proactively sends a handshake packet to re-establish the session. This behavior, while beneficial for legitimate reconnection scenarios, creates an amplification vector.

The attack is particularly effective because the handshake response (~150 bytes of UDP payload) is significantly larger than the minimal trigger packet (as small as 1 byte containing just the fastd packet type header). When accounting for IPv4 and UDP headers, the amplification factor reaches approximately 12-13x, making fastd instances attractive reflectors for volumetric DDoS attacks.

Root Cause

The root cause is the unconditional triggering of handshake responses for data packets from unknown sources without proper rate limiting or source validation. The backoff_unknown() function, which was intended to prevent flooding hosts with handshakes, was insufficient as it did not properly track and rate-limit responses per source IP address, instead allowing the port to vary and bypass restrictions.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Identifying internet-reachable fastd instances
2. Crafting minimal UDP packets (1 byte minimum) with the fastd packet type header
3. Spoofing the source IP address to target a victim
4. Sending these packets to multiple fastd instances
5. The amplified handshake responses are directed at the victim's IP address

// Vulnerable code path in src/receive.c (before patch)
// When receiving data from unknown address, handshake is sent unconditionally
} else if (is_data_packet(packet_type)) {
	if (!backoff_unknown(remote_addr)) {
		pr_debug("unexpectedly received payload data from %I", remote_addr);
		conf.protocol->handshake_init(sock, local_addr, remote_addr, NULL, FLAG_INITIAL);
	}
}

Source: GitHub Commit 1f233bee

The patch modifies this behavior to send only the appropriate handshake type based on the packet received:

// Patched code - determines handshake type based on packet
} else if (is_data_packet(packet_type)) {
	if (!backoff_unknown(remote_addr)) {
		pr_debug("unexpectedly received payload data from %I", remote_addr);

		/* In theory, PACKET_DATA_COMPAT could also be a valid first byte for
		 * a future L2TPv3 extension, but as no such extensions exist and
		 * Linux is unlikely to just enable such extensions by default in
		 * the L2TP kernel implementation, we assume that suchs packets must
		 * be generated by a pre-v22 fastd version without L2TP support. */
		unsigned flags = packet_type == PACKET_DATA_COMPAT ? 0 : FLAG_L2TP_SUPPORT;
		conf.protocol->handshake_init(sock, local_addr, remote_addr, NULL, flags);
	}
}

Source: GitHub Commit 1f233bee

Detection Methods for CVE-2025-24356

Indicators of Compromise

• Unusual volume of small UDP packets (1-10 bytes) arriving at fastd listening ports
• Disproportionate outbound handshake traffic compared to legitimate peer connections
• Multiple incoming packets from diverse IP addresses within short time windows
• Elevated handshake packet generation rates without corresponding session establishments

Detection Strategies

• Monitor UDP traffic ratios on fastd ports for incoming/outgoing byte count anomalies
• Implement network flow analysis to detect amplification patterns (small inbound, large outbound)
• Configure IDS/IPS rules to alert on excessive handshake initiation attempts from unknown sources
• Track failed session establishments that originate from handshake responses

Monitoring Recommendations

• Establish baseline metrics for normal fastd handshake-to-session ratios
• Deploy network traffic analysis tools to monitor fastd UDP port activity
• Enable logging of unknown source reconnection attempts in fastd configurations
• Set up alerts for sudden spikes in outbound UDP traffic from fastd instances

How to Mitigate CVE-2025-24356

Immediate Actions Required

• Upgrade fastd to version v23 or later immediately
• If upgrade is not immediately possible, consider restricting internet exposure of fastd instances
• Implement rate limiting at the network level for UDP traffic to fastd ports
• Review and audit all internet-exposed fastd deployments

Patch Information

The vulnerability is fixed in fastd version v23. Multiple commits address different aspects of the amplification issue:

• Commit ce1b79b - Initial fix implementation
• Commit 5f63fcf - Ignores port for backoff_unknown() to prevent bypass
• Commit 3940150 - Unblocks unknown handshakes after successful connection

For complete details, see the GitHub Security Advisory GHSA-pggg-vpfv-4rcv.

Workarounds

• Place fastd instances behind firewalls with stateful packet inspection
• Implement BCP38/BCP84 anti-spoofing measures at network boundaries
• Use network-level rate limiting to cap UDP packet rates to fastd services
• Restrict fastd accessibility to known peer IP ranges where operationally feasible

# Example iptables rate limiting for fastd UDP port (adjust port as needed)
iptables -A INPUT -p udp --dport 10000 -m hashlimit \
  --hashlimit-above 50/sec --hashlimit-burst 100 \
  --hashlimit-mode srcip --hashlimit-name fastd_limit \
  -j DROP