Bug 2550255 (CVE-2026-77205)

Summary: CVE-2026-77205 libreswan: Denial of Service via sending bogus X.509 certificates
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: akhatavk, aos-team-art-private, asdas, dpaolell, echaudro, fleitner, jdelft, jupierce, ktraynor, lgarciaa, mbiarnes, ppalepu, ppostler, prdhamdh, rhel-process-autobot, rkhan, sfaye, sghai, sidsharm, suppawar, vlaad, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Libreswan's handling of malformed X.509 certificates when running in FIPS mode. A remote attacker may cause a rejected certificate to remain in the NSS certificate cache, resulting in legitimate certificates with the same serial number being rejected. This can prevent affected peers from establishing connections until the Libreswan service is restarted.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2550631    
Bug Blocks:    

Description OSIDB Bzimport 2026-10-13 07:55:12 UTC 
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