Haruki Oyama reported a bug in the eap-aka plugin related to processing an unexpected AKA-Synchronization-Failure message that can lead to a crash caused by a null-pointer dereference.
NULL-Pointer Dereference When Handling AKA-Synchronization-Failure
The eap-aka plugin processes AKA-Synchronization-Failure messages even before it issued a challenge to the client, which can cause a crash due to a NULL-pointer dereference. Affected are all strongSwan versions since 4.1.10.
CVE-2026-78126 has been assigned for this vulnerability.
Missing State Check Before Processing AKA-Synchronization-Failure in eap-aka Plugin
The eap-aka plugin implements the EAP-AKA protocol (RFC 4187). Depending on the configuration, the server either directly sends an AKA-Challenge message or it first initiates an AKA-Identity exchange to request an identity from the peer. The corresponding config option (charon.plugins.eap-aka.request_identity) is enabled by default.
When issuing a challenge, the server allocates and stores a 16-byte random value that is then sent to the client as AT_RAND attribute together with the AT_AUTN attribute that contains the AUTN value that authenticates the server to the client.
One of the errors a peer can send as response to the server's AKA-Challenge request is AKA-Synchronization-Failure, which indicates that the sequence number the server sent in AUTN was inappropriate. Unfortunately, the server implementation processed such responses also if no challenge had been issued yet (i.e. as a response to the AKA-Identity request).
Because the retry with a new sequence number attempts to reuse the previously allocated RAND value, this causes a NULL-pointer dereference.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to Haruki Oyama (Waseda University) for finding this vulnerability and reporting it responsibly. It was independently reported by AISLE Research.
Mitigation
Servers that do not use EAP-AKA (i.e. don't have the eap-aka plugin loaded or have configured other EAP methods explicitly) are not vulnerable.
If request_identity is disabled (not the default), the plugin is not vulnerable as it will initiate the conversation with an AKA-Challenge request and allocate RAND immediately.
Finally, providing EAP via a RADIUS server also prevents the issue completely.
The just released strongSwan 6.1.0 fixes this vulnerability. For older releases, we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets. Please note that we don't provide patches for versions older than 4.4.0.