AISLE Research reported a bug in the openssl plugin related to the enumeration of certificates in PKCS#7 containers that can lead to memory leaks.
Memory Leak When Processing Certificates in PKCS#7 Containers
The openssl plugin's PKCS#7 implementation doesn't clean up properly after enumerating certificates contained in the container, which causes a memory leak for each certificate. Affected are all strongSwan versions since 5.0.2.
CVE-2026-78124 has been assigned for this vulnerability.
Missing Cleanup After Enumerating Certificates in openssl Plugin
When instructed to enumerate the certificates in a PKCS#7/CMS container, the openssl plugin uses CMS_get1_certs() to retrieve the certificate stack from the parsed PKCS#7/CMS structure. This increases the refcount for the stack and all its contained X509 certificate structures.
Unfortunately, the enumerator's destructor did not call sk_X509_pop_free() to properly release that refcount, so the memory for the stack and all contained certificates was leaked.
Because strongSwan's IKEv1 implementation supports the "PKCS #7 wrapped X.509 certificate" encoding type for certificate payloads, an attacker can trigger such leaks pre-authentication by sending a PKCS#7 container containing one or more certificates. But it does require at least two messages even if aggressive mode is accepted.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to AISLE Research for finding this vulnerability and reporting it responsibly.
Mitigation
The main attack path is via IKEv1, so servers that don't accept IKEv1 connections are not vulnerable (note that configs with version = 0 still accept IKEv1 as responder even though IKEv2 is used when initiating).
Servers that don't use the openssl plugin are not vulnerable either. If the pkcs7 plugin is loaded before the openssl plugin (the default if both are enabled), the leak is likely avoided. However, if the former fails to parse the container for some reason, there will be a fallback to the latter.
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.