CVE-2026-50721: Libreswan IKEv1 RSA Signature Verification Flaw – Forgery & DoS

Technical summary

The vulnerability resides in the RSA_authenticate_hash_signature_raw_rsa() function, which implements PKCS #1 RSA signature verification for IKEv1 authentication payloads as defined in RFC 2313. The flaw manifests as insufficient length validation of the hash component within RSA-signed structures. When systems use small public exponents (e=3 being a practical example), this creates exploitability via a Bleichenbacher-style attack: an attacker can construct a valid-appearing signature with a manipulated hash structure that passes verification despite being cryptographically invalid. Separately, an attacker sending an intentionally shortened hash triggers an unguarded assertion in the verification logic, causing immediate daemon termination. The cryptographic weakness is specific to raw RSA signature validation and does not propagate to certificate chain validation, which uses the X.509 PKI stack.

Business impact

For organizations relying on Libreswan for site-to-site IPsec tunnels, VPN gateway functionality, or remote access infrastructure, this vulnerability creates operational and security risk. The forgery path allows attackers to impersonate legitimate IPsec endpoints, potentially enabling lateral movement across trusted networks, data interception within tunnels, or rerouting of encrypted traffic. The denial-of-service path disrupts tunnel availability; while automatic daemon restart provides some resilience, sustained exploitation—such as via a botnet or persistent attacker—degrades connectivity and may be used as cover for other intrusions. Organizations with certificate-pinning or mutual TLS authentication as their primary peer validation remain partially protected, but those relying on RSA signature verification as the sole authentication method face full compromise risk.

Affected systems

Libreswan users across all deployment contexts are affected, including: Linux-based VPN gateways, containerized IPsec endpoints, cloud VPN appliances, and hybrid network architectures using Libreswan for IKEv1 termination. The vulnerability applies to any Libreswan instance configured to perform IKEv1 authentication with RSA signatures. Systems exclusively using IKEv2, ECDSA signatures, or pre-shared key authentication are not vulnerable to the forgery attack but may still experience denial of service if they handle legacy IKEv1 traffic. Verify your Libreswan version and active IKEv1 signature algorithms via 'ipsec --version' and IPsec configuration policy review.

Exploitability

Exploitability is constrained by three factors: (1) the attacker must have network access to the IPsec endpoint, (2) the target system must use small RSA public exponents (e=3 is common in some deployments but not universal), and (3) for the forgery attack, the attacker must know or guess a valid peer identity. The denial-of-service vector is less constrained—any remote attacker can send a malformed IKEv1 SIG payload. Real-world exploitability for forgery is therefore 'possible but requires knowledge of peer configuration'; denial-of-service exploitability is 'immediate and low-friction.' The CVSS 3.1 score of 8.1 (HIGH) reflects the combination of high confidentiality and integrity impact (forgery) with achievable but not trivial attack conditions.

Remediation

Upgrade Libreswan to a patched release that includes length validation hardening in RSA signature verification. Verify the exact patched version against the upstream Libreswan security advisory. Until patching is feasible, implement network-level mitigations: restrict IKEv1 SIG payload sources via firewall rules, prefer IKEv2 with ECDSA or other non-RSA algorithms where possible, and consider certificate-based mutual authentication as an additional verification layer. Monitor IPsec daemon logs for assertion failures (indicators of the DoS attack) and set up automated alerting on daemon restarts. For high-security environments, isolate Libreswan endpoints on dedicated network segments and disable IKEv1 entirely if all peers support IKEv2.

Patch guidance

Contact the Libreswan project directly or monitor libreswan.org security advisories for the specific patched version addressing CVE-2026-50721. The patch must include updated hash length validation logic in RSA_authenticate_hash_signature_raw_rsa(). After patching, verify daemon functionality with existing IKEv1 tunnels before removing temporary mitigations. Test certificate-based authentication separately to confirm X.509 path validation was not inadvertently affected by the patch.

Detection guidance

Monitor Libreswan logs and audit trails for: (1) unexpected IKEv1 SIG payload processing errors or assertion failures in daemon logs, which may indicate DoS exploitation; (2) successful IKEv1 authentication events from unexpected peer IP addresses or identities, which may indicate forgery attempts; (3) daemon crash-restart cycles correlated with incoming IPsec traffic. Deploy network-based detection by monitoring IKEv1 traffic for malformed SIG payloads (anomalously short hash fields); tools such as Zeek with IPsec policy enforcement can identify suspicious signature structures. Cross-reference any IKEv1 authentications with your known peer roster; deviations warrant investigation.

Why prioritize this

This vulnerability merits HIGH priority due to the combination of remote exploitability, high-impact attack vectors (both authentication forgery and denial of service), and the prevalence of Libreswan in production VPN infrastructure. While not yet in active public exploitation (KEV status is false), the cryptographic weakness is reproducible by motivated actors. Organizations running IKEv1 with RSA signatures should patch within 30 days; those with mixed IKEv1/IKEv2 environments should prioritize IKEv2 adoption and restrict IKEv1 scope in parallel.

Risk score, explained

CVSS 3.1 assigns a score of 8.1 (HIGH) reflecting: Attack Vector = Network (remote, no special access needed), Attack Complexity = High (requires knowledge of small exponents or specific configuration), Privileges Required = None, User Interaction = None, Scope = Unchanged (impact is to the confidentiality and integrity of the IPsec channel, not system-wide), Confidentiality Impact = High (tunnel traffic exposure), Integrity Impact = High (forgery of peer identity), Availability Impact = High (denial of service via crash). The 'High' complexity factor prevents a Critical score despite the severity of potential compromise.

Frequently asked questions