Puru Kulkarni reported a bug in the eap-peap and eap-ttls plugins related to the propagation of authentication details from inner EAP methods that can result in incorrect identity binding and potential authorization bypass.
Missing Inner EAP Method Authentication Details
The eap-peap and eap-ttls plugins don't correctly propagate authentication details from the inner EAP method (phase 2) to the IKE SA, which can cause a mismatch between IKE or EAP-Identity and the actual identity used for the authentication. Depending on the configuration and how identities are used, this may result in an authorization bypass. Affected are all strongSwan versions since 4.5.0.
CVE-2026-78134 has been assigned for this vulnerability.
Incomplete or Missing Auth-Cfg in Tunneling EAP Methods
When EAP-PEAP or EAP-TTLS are used as tunneling authentication protocols, the inner EAP method may override the EAP-Identity with the actual identity used by the client. The only method this applies to is EAP-MSCHAPv2, which exchanges the username of the client and stores it as EAP-Identity. If the method is used without a tunneling EAP method, the identity is correctly propagated.
The
eap_method_t::get_auth() method is the interface through which the EAP authenticator retrieves authentication details, including the authenticated identity, which is then stored on the IKE SA. For EAP-TTLS, this method was introduced with 5.3.0 but only returned the TLS-level authentication results, omitting the inner EAP method's authentication details entirely. For EAP-PEAP, the
get_auth() method was never implemented, so no authentication details were returned at all.
A similar issue affects inner EAP methods that don't override the identity (like EAP-MD5). That's because both EAP-PEAP and EAP-TTLS exchange an inner EAP-Identity before phase 2 is started. That identity is forwarded directly to the inner EAP method, which uses it to e.g. look up a shared secret. This identity was also never propagated back.
That the two plugins use the inner EAP-Identity directly when instantiating the inner EAP method also affects EAP-TNC if client certificates are used during the first phase of EAP-PEAP/TTLS. While the initial IKE/EAP identity has to be confirmed by the client's certificate in this case, the proclaimed inner EAP-Identity is just forwarded without confirmation to the EAP-TNC method. So it might operate on an unverified identity.
Because the IKE or EAP-Identity is used for authorization decisions (e.g. config selection in the ike-auth task), the missing or mismatched inner EAP identity means the SA could be bound to an incorrect and unauthenticated identity. So a client could impersonate another user by e.g. claiming ownership of their identity during the outer EAP-Identity exchange, while authenticating with their own identity during the tunneled EAP exchange.
The IKE/EAP identity is also used for other decisions like uniqueness checks or virtual IP assignment. So the vulnerability may allow a client to kick out another and claim their virtual IP.
Note that the attacker must be able to authenticate successfully with valid credentials.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to Puru Kulkarni (puru1761) for finding this vulnerability and reporting it responsibly.
Mitigation
Servers that don't accept EAP authentication are not vulnerable.
Servers that don't use EAP-PEAP or EAP-TTLS are not vulnerable (e.g. if the plugins are not loaded or a different EAP method is configured explicitly). To avoid that clients can select these methods via EAP-Nak, make sure that either the eap-dynamic plugin is not used or loaded, or that the two vulnerable plugins are not loaded so they can't be instantiated by the eap-dynamic plugin.
Setups that provide EAP via a RADIUS server are also not directly vulnerable. However, they could be vulnerable to similar identity binding issues.
The just released strongSwan 6.1.0 fixes this vulnerability. For older releases, we provide patches that fix the vulnerability and should apply with appropriate hunk offsets. Please note that we don't provide patches for versions prior to 5.3.0 as they lack the eap_method_t::get_auth() method.