REDHAT-BUG-2550255: Low severity libreswan Libreswan vulnerability

Published Oct 13, 2026

Updated

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

Affected Software

1 affected component

libreswan Libreswan=5.3, =5.3.1, =5.3.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade Libreswan to a version that resolves this vulnerability.
Fixed in 5.4
Compensating control
If using a private Root CA for IPsec VPNs, verify that it uses randomized certificate serial numbers.

Event History

Oct 13, 2026

Data Sourced

via Red Hat·07:55 AM

DescriptionSeverityAffected Software

Frequently Asked Questions

Which deployments are realistically exposed to this issue?

Deployments running Libreswan 5.3, 5.3.1, or 5.3.2 in FIPS mode are affected. The issue concerns certificate-based IPsec VPN peers and can prevent legitimate peers from connecting.

What does an attacker need to do to cause a denial of service?

The attacker must send a malformed certificate using a serial number that matches a legitimate certificate. The rejected malformed certificate remains in the NSS cache, causing the legitimate certificate with that serial number to be rejected until the service is restarted.

Does using randomized certificate serial numbers eliminate the risk?

Randomized serial numbers are recommended for private root CAs and make serial-number prediction more difficult. They do not fully eliminate the risk because an attacker may be able to learn a serial number by tricking a peer into connecting first.

What can be done if an affected service is already being blocked?

Restarting the service clears the cached bogus certificates and allows legitimate certificates with those serial numbers to connect again. Upgrade to Libreswan 5.4 or later to address the issue.

Which versions are not vulnerable?

Libreswan versions 3.0 through 5.2 are not vulnerable, and versions 5.4 and later are not vulnerable.

REDHAT-BUG-2550255: Low severity libreswan Libreswan vulnerability

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are realistically exposed to this issue?

What does an attacker need to do to cause a denial of service?

Does using randomized certificate serial numbers eliminate the risk?

What can be done if an affected service is already being blocked?

Which versions are not vulnerable?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are realistically exposed to this issue?

What does an attacker need to do to cause a denial of service?

Does using randomized certificate serial numbers eliminate the risk?

What can be done if an affected service is already being blocked?

Which versions are not vulnerable?