Cipher / Causal Security reported a bug in libcharon related to the the handling of IKEv2 rekeying collisions that can lead to a use-after-free and potentially remote code execution.
Use-After-Free During Multi-KE Rekey Collision
The IKEv2 implementation in the libcharon library doesn't correctly handle certain IKE and Child SA rekey collisions that involve multiple key exchanges, which can cause a use-after-free that could potentially be exploited for remote code execution by an authenticated peer. Affected are all strongSwan versions since 6.0.0.
CVE-2026-78133 has been assigned for this vulnerability.
Dangling Pointer in Collision Handling After Task Failure in libcharon
IKE or Child SA rekeyings can collide if both peers decide to rekey the same SA concurrently. With IKEv2, such collisions can be resolved by comparing the nonces of all involved SAs. For that purpose, the active rekeying task (the one that initiated a rekeying) keeps a reference to the passive rekeying task (the one that responded to a rekeying). Once the active task processes the peer's response it has all the information to decide who "won" the collision, the nonces from its own exchange and those it can retrieve from the passive task.
During a classic rekeying, the passive task is completed immediately because all it has to do is process the CREATE_CHILD_SA request and respond appropriately. So if the exchange was successful, the passive task is adopted by the active task (the task manager releases it and doesn't free it).
With multiple key exchanges this gets a bit more complicated. During a multi-KE rekeying the passive task is not immediately done after processing CREATE_CHILD_SA as it has to process further KE payloads in IKE_FOLLOWUP_KE exchanges. But since the nonces were already exchanged, the active task already holds a reference to the passive task in order to potentially abort the active rekeying once the CREATE_CHILD_SA response is received and all nonces are known.
If that CREATE_CHILD_SA response is delayed or actively withheld by the peer, the active task stores this reference while the passive task is concurrently in progress. If it subsequently fails, e.g. due to a missing or invalid KE payload, which the peer can control, and completes, the task manager passes the task to the active task again. At that point the active task only sees that the passive rekeying is not yet complete but it previously had no means to recognize that the task is done because the rekeying failed. So it keeps the reference but does not adopt the task from the task manager. The latter, in turn, destroys the task because it's not adopted but complete from its perspective.
Later, when the active rekeying progresses and the collision is resolved, the dangling pointer gets dereferenced for an indirect function call (get_lower_nonce() method of the ike_init_t or child_create_t instance stored in the passive task's private struct).
Remote code execution might be possible due to this issue. The attacker has to be authenticated and must get two indirections right to exploit this flaw for a potential RCE. Otherwise, the effects are a crash or undefined behavior triggered by the method call.
As mentioned in the introduction, credit to Cipher / Causal Security for finding this vulnerability and reporting it responsibly.
Mitigation
Servers that don't accept multiple key exchanges are not vulnerable.
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.