Alessandro Mantovani reported a bug in the openssl plugin related to the processing of PKCS#7 containers that can lead to a crash.
Undefined Memory Access When Handling PKCS#7 Containers
The openssl plugin doesn't properly initialize stack variables when parsing a PKCS#7 signerInfo or recipientInfo structure. If such a structure encodes issuerAndSerialNumber instead of subjectKeyIdentifier, this can cause a crash. Affected are all strongSwan versions since 5.0.2.
CVE-2026-78123 has been assigned for this vulnerability.
Uninitialized Stack Pointers Passed to OpenSSL Parsing Function
The openssl plugin can parse PKCS#7/CMS containers with signed or encrypted data. The information on the signer or recipient is encoded in signerInfo or recipientInfo structures, respectively. The OpenSSL library provides functions to parse these structures and get the encoded information.
For instance, the code to parse a signerInfo structure in verify_signature() looks something like this:
X509_NAME *name;
ASN1_INTEGER *snr;
if (CMS_SignerInfo_get0_signer_id(si, NULL, &name, &snr) != 1)
{
return NULL;
}
issuer = openssl_x509_name2id(name);
if (!issuer)
{
return NULL;
}We pass two uninitialized pointers to retrieve the encoded name and serial number (snr) from the structure and then process the name further.
The problem is that the identity can be encoded in one of two formats (ASN.1CHOICE). Either as issuerAndSerialNumber, which is what strongSwan generally supports and the code here expects, or as subjectKeyIdentifier. OpenSSL supports both formats and if the latter is found, CMS_SignerInfo_get0_signer_id() provides the subjectKeyIdentifier via its second argument (ASN1_OCTET_STRING **keyid). However, even if NULL is passed, it returns 1. And it leaves the two pointers we pass unchanged.
So the subsequent call to openssl_x509_name2id() operates on an uninitialized stack value. While the function has a NULL-pointer check, the uninitialized pointer is unlikely to be NULL and is passed to i2d_X509_NAME() that dereferences it, which likely causes a segmentation fault. In case it doesn't, the serial number is passed to openssl_asn1_str2chunk() right afterwards, which likewise dereferences the pointer after a NULL-check.
The code in the decrypt() function that handles recipientInfo structures is basically the same. It calls CMS_RecipientInfo_ktri_get0_signer_id() with uninitialized pointers and processes them as described above.
Remote code execution is likely not possible due this issue.
As mentioned in the introduction, credit to Alessandro Mantovani for finding and reporting this vulnerability responsibly.
Mitigation
The remote 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).
Installations that don't have the openssl plugin loaded are also not vulnerable. Having the pkcs7 plugin loaded before the openssl plugin won't help because the former doesn't support the subjectKeyIdentifier encoding and will fail parsing the container, so there is an automatic fallback to the openssl plugin.
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.