AISLE Research reported a bug in libstrongswan related to the processing of encrypted PKCS#7 containers that can lead to a denial of service.
Unbounded Iteration When Decrypting PKCS#7 Containers
The PKCS#5 implementation in libstrongswan doesn't validate the parsed iteration count, key length, and salt length parameters, which can cause the processing thread to be blocked for an unlimited amount of time or may result in a crash due to an oversized stack allocation. This can be triggered by an encrypted PKCS#7 container sent via IKEv1. Affected are all strongSwan versions since 4.6.2.
CVE-2026-78129 has been assigned for this vulnerability.
Missing Validation of PKCS#5 Parameters
When processing a structure encrypted via PKCS#5 (e.g. in PKCS#8, PKCS#7 or PKCS#12 containers), the implementation in libstrongswan parses the necessary parameters from the ASN.1 structure and stores the iteration count in a 64-bit variable without upper bound check. This value is then later used as loop counter when deriving the decryption key, where each iteration performs expensive cryptographic hash operations. By crafting a file with an astronomically large iteration count, an attacker can cause the processing thread to be blocked practically forever.
Via IKEv1 certificate payload, an attacker can send a crafted PKCS#7 container with an encrypted-data content type. Before 5.1.0, this didn't cause any issues as a secret of type SHARED_PRIVATE_KEY_PASS was necessary to start the decryption. Such secrets are only loaded by interactive commands (e.g. pki or swanctl), not by the IKE daemon. However, since 5.1.0, the pkcs7 plugin first tries to decrypt the container without a password (to load encrypted certificates in password-less PKCS#12 containers), triggering this vulnerability and causing a denial of service.
Because the key length is also parsed as 64-bit value without bounds and used via chunk_alloca() to allocate a buffer on the stack, an excessively large amount can even cause a crash.
The length of the salt is also not limited, however, that's bounded by the maximum IKE message size that's 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
Setups where the pkcs7 plugin is not loaded are not vulnerable to remote attacks via IKEv1. If the plugin is loaded, only setups where IKEv1 is accepted are vulnerable (note that configs with version = 0 still accept IKEv1 as responder even though IKEv2 is used when initiating).
The local attacks via PKCS#8 or PKCS#12 files require that the pkcs8 or pkcs12 plugins are loaded.
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 be aware that we don't provide any patches for versions older than 5.1.0 as those are not vulnerable to remote attacks.