CVE-2026-78135 is a medium severity (CVSS 5.6) flaw in strongSwan's libcharon. A CREATE_CHILD_SA request can create a usable Child SA before authentication finishes. Versions since 5.9.7 are affected. The fix is strongSwan 6.1.0, and the project offers a patch for older releases.
What's affected
strongSwan from 5.9.7 onward. The record says 5.9.7 through 6.0.7. The project's blog post says all versions since 5.9.7 are affected and names 6.1.0 as the release that fixes it. Treat any build from 5.9.7 up to the fix as in range.
The project says versions before 5.9.7 also accepted the request early, but authentication failed there and no Child SA was created.
The maintainers also describe who is not exposed. Servers that do not accept EAP authentication are not vulnerable. Common roadwarrior setups that use EAP are not vulnerable if they use a virtual IP address pool and remote_ts set to dynamic, which is the default.
How to check if you're exposed
ipsec version
swanctl --version
Then review your connection configuration. Look for connections that use EAP authentication on the responder side, and check whether they define a virtual IP pool and leave remote_ts at its default. The advisory says a Child SA only comes up when the responder has no address pool or sets an explicit remote traffic selector.
What to do now
- Upgrade to strongSwan 6.1.0, or apply the patch the project provides for older releases through your distribution.
- If you cannot patch quickly, check your EAP connections against the maintainers' safe configuration: a virtual IP pool and dynamic remote traffic selectors.
- Ask your distribution whether it has backported the fix, since packaged versions often keep older numbers.
- Restart the charon daemon after the update.
Why it matters
The record classes this as CWE-841, improper enforcement of behavioral workflow. The IKEv2 state machine has a check that rejects CREATE_CHILD_SA requests while the connection is still being set up. The project explains that the check only ran when no exchanges were already in progress. With EAP authentication, tasks stay queued while authentication is pending, so the check was skipped and the request was handled as if the session were established.
The maintainers say remote code execution is not possible through this issue, and that the half-open session and any installed IPsec state are removed after the default 30 second timeout. The weakness is an old pattern: a 2014 bug of the same family was fixed in the initiator, and this one lived in the responder path. No KEV listing.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Can this give an attacker code execution?
The strongSwan maintainers say no. The risk is an unauthenticated peer getting a usable Child SA for a short time.
Does the 30 second timeout make this harmless?
It limits the window, but a usable tunnel before authentication still breaks the trust model, so patch.
Sources
Last reviewed: 18 October 2026.
