CVE-2026-77205: Denial of Service via sending bogus X.509 certificates
Libreswan in FIPS mode has a vulnerability where badly formed received certificates are rejected, but not deleted from the NSS cache. As a result, any real certificates with the same serial number are rejected as well. This can be abused to lock out legitimate peers from connecting. The adddecodedcert() function missed a call to CERTDestroyCertificate() due to an incorrect fix for CVE-2026-14957. Sending bogus certificates with new serial numbers could prevent the real certificates with those serial numbers from connecting until the service has restarted.
Other sources
The Libreswan Project received a report about an issue in the libreswan 5.3 series related to badly formed received certificates while running in FIPS mode. While being rejected, the certifiates were not deleted from the NSS cache, resulting in any real certificates with the same serial number being rejected as well. This can be abused to lock out legitimate peers from connecting.
Sending bogus certificates with new serial numbers could prevent the real certificates with those serial numbers from connecting until the service has restarted. While there is no RFC that dictates Certificate Authority (CA) should use randomized serial numbers, it is considered best practise and it is a requirement of the CA/Browser Forum. If using a private Root CA for IPsec VPNs, it is recommended to verify it uses randomized serial numbers. However, an attacker could still trick a peer into connecting to them first, thus learning the serial number.
Vulnerable versions : 5.3, 5.3.1, 5.3.2 Not vulnerable : 3.0 - 5.2, 5.4 and higher
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
alpine/libreswanto a version that resolves this vulnerability.Fixed in 5.3.3-r0 - Upgrade
Upgrade
Libreswanto a version that resolves this vulnerability.Fixed in 5.3.3 - Configuration
Verify that the private Root CA uses randomized certificate serial numbers.
Private Root CA used for IPsec VPNs Certificate serial numbers = randomized
Event History
Frequently Asked Questions
Which deployments are affected?
The issue affects Libreswan operating in FIPS mode. The provided information does not identify affected versions.
What must an attacker do to disrupt peer connections?
An attacker must send badly formed X.509 certificates using serial numbers that correspond to certificates legitimate peers will use. The malformed certificates are retained in the NSS cache, causing later real certificates with those serial numbers to be rejected.
Is authentication required to exploit this issue?
No privileges or user interaction are required according to the supplied vector. Exploitation is network-based, although the attack complexity is rated high.
What is the immediate workaround if a peer has been locked out?
Restart the affected service. The supplied information states that the blocked legitimate certificates can connect again only after the service has restarted.