TL;DR; Bishop Fox researchers took a deep dive into a new strongSwan vulnerability that allows unauthenticated attackers to take VPN services offline, with the bug impacting versions going back over 15 years. Exposure is likely anywhere EAP-TTLS is enabled. We created an easy tool to test your strongSwan deployment & recommend upgrading to version 6.0.5 and later.

Summary

Bishop Fox researchers successfully exploited an integer underflow vulnerability affecting the EAP-TTLS plugin in strongSwan versions 4.5.0 through 6.0.4. The vulnerability allows remote, unauthenticated attackers to crash the VPN server's IKE daemon through a carefully crafted EAP-TTLS message, resulting in denial of service.

What makes this vulnerability particularly interesting is that exploitation often requires a two-phase attack. In some scenarios, a single malicious packet corrupts the heap but doesn't crash the daemon; only a second connection triggers the segmentation fault. Our researchers also developed a safe detection method that identifies vulnerable servers without causing any disruption, which you can download here.

Demo of the two-phase heap corruption attack.

Background

VPN infrastructure represents one of the most critical attack surfaces in modern networks. These devices sit at the network perimeter, exposed to the internet, and serve as the gateway to internal resources. At Bishop Fox, we prioritize VPN research because vulnerabilities in these systems can have cascading effects across entire organizations. Impacts to the availability of these systems can be a nightmare for security teams who depend on VPN access for incident response and business continuity.

strongSwan is open-source IPsec VPN software widely deployed in both enterprise and embedded environments. Like many VPN solutions, it supports various authentication methods, including EAP-TTLS (Extensible Authentication Protocol - Tunneled Transport Layer Security). EAP-TTLS is designed to provide secure credential exchange by establishing a TLS tunnel and then passing authentication data through that tunnel using Attribute-Value Pairs (AVPs), simple data structures consisting of a header (containing length and type information) followed by the actual attribute data. This design allows for flexible, extensible authentication while protecting credentials from eavesdropping.

On March 23, 2026, strongSwan published an advisory for CVE-2026-25075 describing an integer underflow in the EAP-TTLS AVP parser. According to their disclosure, the vulnerability affects all versions since 4.5.0. The vulnerability affects over 15 years of strongSwan releases, meaning a significant number of VPN servers remain vulnerable.

The issue stems from improper validation of AVP length fields, allowing attackers to trigger massive memory allocations that corrupt heap structures.

Vulnerability Analysis

According to strongSwan's advisory, the vulnerability stems from the parser's handling of AVP length values:

The plugin fails to validate that AVP length values meet a minimum threshold. When processing an AVP header with an encoded length between 0-7 bytes, the code performs: this->data_len = avp_len - 8.

In the source code for version 6.0.4, the vulnerable code is found on line 133 of src/libcharon/plugins/eap_ttls/eap_ttls_avp.c. This single operation is deceptively simple but catastrophically flawed. The AVP format specifies that each attribute includes an 8-byte header followed by data, so the code attempts to calculate the data length by first subtracting 8 bytes from the total AVP length. The problem? There's no validation to ensure avp_len is at least 8 bytes. In version 6.0.5, strongSwan added a bounds check before the subtraction to prevent the underflow.

When an attacker sends an AVP with length=1, the arithmetic produces a signed integer underflow:

data_len = 1 - 8 = -7

Since data_len is stored as an unsigned 32-bit integer (uint32_t), this negative value wraps around to 0xFFFFFFFFFFFFFFF9. The code then adds 4 bytes of padding (rounding up to the nearest 4-byte boundary) before calling chunk_alloc(), resulting in this memory allocation:

chunk_alloc(0xFFFFFFFFFFFFFFFC)

For those unfamiliar with hexadecimal notation, this allocation is approximately 18 exabytes in size! Assuming the server does not have this much memory available, the malloc implementation may handle the request in one of two ways: it either returns NULL or a pointer to unmapped memory. Either way, when the code subsequently attempts to copy data into this "allocated" buffer using memcpy(), disaster strikes.

The Two-Phase Attack

Here's where things get interesting. When we first crafted our exploit and sent the malicious AVP to a test target, we expected an immediate crash. The analysis in the vendor's advisory suggested that a null-pointer dereference would occur as soon as the malicious payload was processed. Instead, the connection closed gracefully and the daemon (the background process handling VPN connections) continued running. This was initially puzzling; why didn't the process crash?

After some investigation, we found that the crash behavior depends on how the system's malloc implementation handles the impossibly large allocation request. On our test system, malloc didn't immediately return NULL. Instead, the allocation request corrupted internal heap management structures (the heap is the region of memory used for dynamic allocations during program execution). The daemon wouldn't crash until those corrupted structures were used in a subsequent allocation. To trigger a crash in this environment, the exploit required two phases:

• Phase 1: Establish an IKEv2 connection with EAP-TTLS, send the malicious AVP with length=1 followed by payload data. The integer underflow occurs, malloc is called with an impossibly large size, and heap structures are corrupted. The connection closes, but on the server side the request hangs open for a short time while the daemon remains running with a corrupted heap.
• Phase 2: Establish a second IKEv2 connection and send another malicious AVP. When malloc is called again, it attempts to use the corrupted heap structures from Phase 1. The corrupted metadata causes malloc to return NULL or an invalid pointer, and when memcpy() attempts to write to this address, the daemon crashes with a segmentation fault.

It's worth noting that on systems with different malloc implementations, the behavior may vary. If malloc immediately returns NULL on the impossibly large allocation, then memcpy(NULL, data, actual_length) would crash the daemon on the first request without requiring Phase 2. The two-phase behavior we observed is specific to our test environment but demonstrates why heap corruption bugs can be difficult to diagnose: the crash may be far removed from the root cause.

Exploit Implementation

The malicious payload itself is remarkably simple at just 4 bytes:

avp = struct.pack("!I", 1)  # AVP length = 1

That's it. When this 4-byte AVP header is sent to the vulnerable code, the parser reads the length field, performs the fatal subtraction, and triggers the integer underflow. The challenge, however, is getting those 4 bytes to the right place.

The EAP-TTLS AVP parser sits deep within the strongSwan daemon, accessible only after a successful IKEv2 negotiation and EAP-TTLS authentication exchange. To reach the vulnerable code, we must reproduce the complete IKEv2 and EAP-TTLS protocol stack:

• IKEv2 Protocol: Full implementation of the Internet Key Exchange protocol, including IKE_SA_INIT and IKE_AUTH exchanges
• Diffie-Hellman Key Exchange: MODP Group 14 (2048-bit) key agreement
• Cryptographic Primitives: SKEYSEED derivation, PRF+ key expansion, AES-CBC-256 encryption, and HMAC-SHA256-128 integrity protection
• EAP Framework: EAP-Identity exchange and EAP-TTLS negotiation
• TLS 1.2 Handshake: Establishing the TLS tunnel required by EAP-TTLS
• AVP Delivery: Properly encapsulating the malicious AVP within the EAP-TTLS tunnel

Fortunately, we can leverage some existing Python libraries (like pycryptodome for cryptographic primitives and tlslite-ng for the TLS handshake) to simplify the implementation. Running our final exploit produces the following output:

[*] Phase 1: Corrupting heap...
[1] IKE_SA_INIT...
[+] OK
[2] IKE_AUTH...
[+] OK
[3] EAP Identity...
[+] OK
[4] TLS handshake...
[+] OK
[5] Sending malicious AVP...
[+] Sent
[*] Verifying crash...
[-] Server still responding
[*] Phase 2: Triggering crash on corrupted heap...
[1] IKE_SA_INIT...
[+] OK
[2] IKE_AUTH...
[+] OK
[3] EAP Identity...
[+] OK
[4] TLS handshake...
[+] OK
[5] Sending malicious AVP...
[+] Sent
[*] Verifying crash...
[+] Server crashed!

A Safer Testing Approach

We recognized early in our research that we would need a way to test our customers' strongSwan deployments without risking disruption, so we developed a detection method that triggers the integer underflow without corrupting the heap.

The AVP length field tells the parser how many bytes of data follow the header. In our exploit, we send an AVP with length=1 followed by actual payload data, causing the parser to attempt copying that data into a corrupted or NULL buffer. This triggers the crash either immediately or in Phase 2, depending on the system's malloc behavior.

For safe testing, we send an AVP header with length=1 but no data payload. The integer underflow still occurs, and malloc still fails or returns NULL, but when the code reaches the memcpy() call, it attempts to copy 0 bytes:

memcpy(ptr, data, 0);  // This is a no-op, even if ptr is NULL

Copying zero bytes is perfectly safe: it's effectively a no-op regardless of whether the pointer is NULL, corrupted, or valid. The heap remains intact and the server continues operating normally, but we've confirmed that the vulnerable code path was reached. This approach works across different malloc implementations and system configurations. We can detect vulnerability by observing the server's behavior:

• Vulnerable servers: Process the malformed AVP and continue the EAP-TTLS exchange
• Patched servers: Reject the malformed AVP due to validation checks added in version 6.0.5

Test Your strongSwan Deployments

Our safe test script implements this approach and allows security teams to assess their exposure without any risk to production systems. Download it here and run it like so:

python3 CVE-2026-25075-test.py <TARGET IP> <TARGET UDP PORT>

The default strongSwan IPSEC port is 500.

It's important to note that successful exploitation requires several preconditions to be met:

• The target must be running a vulnerable version of strongSwan (4.5.0 through 6.0.4)
• The EAP-TTLS plugin must be enabled and configured
• The server must accept IKEv2 connections and complete the initial handshake
• The server must negotiate EAP-TTLS as an authentication method

If any of these conditions are not met, the test script will fail gracefully at the corresponding stage. For example, if EAP-TTLS is not enabled, the script will report that the server doesn't support this authentication method. If the server is patched, it will reject the malformed AVP during validation. This means the test can distinguish between truly vulnerable servers and those that are either patched or simply not configured to use EAP-TTLS.

The Patch

strongSwan addressed the vulnerability in version 6.0.5 by adding proper validation before the subtraction:

// Fixed in 6.0.5:
if (!success || avp_len < AVP_HEADER_LEN)
    return FAILED;

This simple check ensures that AVP length values are at least 8 bytes before attempting to calculate the data length, preventing the integer underflow entirely.

The fix demonstrates the importance of defensive programming, even simple arithmetic operations need bounds checking when dealing with untrusted input.

Conclusion

CVE-2026-25075 is a textbook example of an integer underflow vulnerability with system-dependent crash behavior. On some systems, the exploitation requires two phases due to how malloc handles impossible allocation requests, corrupting heap structures that only trigger a crash during subsequent allocations, but on others the crash can occur after processing a single request.

For organizations running strongSwan, the remediation steps are straightforward:

• Test your deployment: Use our safe detection script to determine if you're vulnerable.
• Upgrade immediately: 6.0.5 and later versions include the fix.
• Consider disabling EAP-TTLS: If you're not using this authentication method, disable the plugin entirely.

Given the ease of exploitation and the potential for denial of service, we strongly encourage all strongSwan users to upgrade as soon as possible.

Our affected Cosmos customers were notified of this vulnerability shortly after the vendor disclosure, and we continue to monitor for new threats to VPN infrastructure. If you're interested in learning more about managed services delivered through our Cosmos platform, visit bishopfox.com/services/cosmos.

Our safe testing tool is available on GitHub: https://github.com/BishopFox/CVE-2026-25075-check.

For more vulnerability intelligence insights, visit the Bishop Fox Blog.