What Happened

A high-severity denial-of-service vulnerability has been disclosed in strongSwan, the widely deployed open-source IPsec VPN implementation. Tracked as CVE-2026-25075 with a CVSS score of 7.5, the bug is an integer underflow in the EAP-TTLS authentication plugin’s Attribute-Value Pair (AVP) parser. It has lurked in the codebase for over fifteen years, affecting every release from 4.5.0 through 6.0.4.

The strongSwan project disclosed the flaw on March 23 and shipped a fix in version 6.0.5. Bishop Fox published a detailed technical writeup and released a public detection tool on GitHub shortly after. Major distributions including Debian, SUSE, and Ubuntu have begun shipping patched packages.

How the Bug Works

EAP-TTLS is a two-phase authentication method commonly used in enterprise VPN deployments. It establishes a TLS tunnel between client and server, then passes authentication credentials through that tunnel using Attribute-Value Pairs — simple type-length-value structures with an 8-byte header followed by payload data.

The vulnerability sits in the AVP parsing routine inside the eap-ttls plugin. When the parser reads an incoming AVP, it extracts the length field from the header and computes the payload size by subtracting the 8-byte header length:

1

this->data_len = avp_len - 8;

The problem: there is no check that avp_len is actually at least 8. If an attacker sends a crafted AVP with a length field between 0 and 7, the subtraction wraps around as an unsigned 32-bit integer. A length of 0 becomes 4,294,967,288 bytes. The parser then attempts to allocate or read that much memory, leading to either massive heap allocation (resource exhaustion) or a NULL pointer dereference — both of which crash the charon IKE daemon.

According to Bishop Fox’s analysis, reliable exploitation uses a two-phase approach: the first malicious packet corrupts heap state, and the second triggers a segmentation fault that brings down the daemon. Because the attack targets the authentication phase, no valid credentials are needed. An unauthenticated remote attacker can take down the VPN gateway with a handful of packets.

Who Is Affected

Any strongSwan deployment using EAP-TTLS authentication is vulnerable. This is a common configuration in enterprise and campus VPN environments, particularly those authenticating against RADIUS backends with an inner EAP method.

The following are not vulnerable:

  • Deployments that do not use EAP-TTLS at all (e.g., pure certificate or PSK authentication)
  • Configurations where EAP-TTLS is terminated on a RADIUS server rather than the strongSwan daemon itself

strongSwan is shipped as the default or recommended IPsec stack on many Linux distributions and is a core component of numerous commercial VPN appliances and SD-WAN products. If you run IKEv2 VPN infrastructure on Linux, there is a reasonable chance strongSwan is in the path.

What To Do

Patch immediately. Upgrade to strongSwan 6.0.5, which adds a bounds check before the subtraction:

1
2

if (!success || avp_len < AVP_HEADER_LEN)
    return FAILED;

Distribution packages are available or in progress for Debian, Ubuntu, SUSE, and Fedora. Check your distribution’s security tracker for the latest status.

Detect exposure. Bishop Fox has released a free scanning tool at github.com/BishopFox/CVE-2026-25075-check that can identify vulnerable strongSwan instances in your environment.

Mitigate if patching is delayed. If you cannot patch immediately:

  • Disable EAP-TTLS authentication and switch to certificate-based or other EAP methods that do not use AVP parsing
  • Restrict IKEv2 initiation to known IP ranges at the firewall level to reduce the unauthenticated attack surface
  • Monitor for charon daemon crashes — repeated unexpected restarts are a strong indicator of exploitation attempts

Audit your configuration. Review your ipsec.conf or swanctl.conf for eap-ttls references. If EAP-TTLS is configured but not actively used, remove it to eliminate the attack surface entirely.

Why This Matters

Fifteen years is a long time for a bug to hide in a security-critical component. The root cause — a missing bounds check on a length field before arithmetic — is one of the most basic classes of C programming errors. It is a reminder that even well-maintained, security-focused projects accumulate technical debt in parsing code that rarely gets adversarial scrutiny.

VPN gateways are single points of failure for remote access infrastructure. A denial-of-service condition that can be triggered without authentication, from the internet, with minimal effort, is a serious operational risk. If your VPN goes down, your remote workforce goes dark.

Patch, scan, and verify. If you are running strongSwan with EAP-TTLS, treat this as a priority.