HIGH 8.1

CVE-2026-50722: Libreswan IKEv2 Authentication Forgery and Denial-of-Service Vulnerability

Libreswan, a widely-used open-source IKE/IPsec implementation, contains a flaw in how it validates digital signatures on IKEv2 authentication payloads. The vulnerability stems from improper verification of the ASN.1 encoding structure within RSA signatures. An attacker can exploit this in two ways: first, by forging authentication messages when the target uses a small RSA public exponent (such as e=3), allowing them to impersonate legitimate IKE peers; second, by sending specially crafted malformed signatures that crash the daemon, causing repeated denial of service. While serious, this does not enable remote code execution, and X.509 certificate chains remain properly validated.

Source data · NVD / CISA · public domain

CVSS
3.1 · 8.1 HIGH · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-347, CWE-617
Affected products
1 configuration(s)
Published / Modified
2026-07-02 / 2026-07-09

NVD description (verbatim)

Libreswan, via the function RSA_authenticate_hash_signature_pkcs1_1_5_rsa(), did not correctly verify the DER encoding of the ASN.1 digest when the IKEv2 AUTH payload was encoded using RSASSA-PKCS1-v1_5 (RFC 8017). A remote attacker can use a variation on the Bleichenbacher attack to forge the AUTH payload when small public exponents are used (e.g., e=3), leading to impersonation. Additionally, a remote attacker, by encoding a shorter than expected hash in the AUTH payload, could trigger an assertion leading to denial-of-service. The daemon aborts and restarts; continued exploitation causes sustained denial of service. Remote code execution is not possible. X.509 certificate verifications of the remote IKE peer are not affected.

4 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-50722 affects the RSA_authenticate_hash_signature_pkcs1_1_5_rsa() function in Libreswan's IKEv2 authentication handling. The vulnerability manifests as inadequate DER encoding verification of ASN.1 digest structures within RSASSA-PKCS1-v1_1_5 signatures (RFC 8017). This enables two distinct attack vectors: (1) a Bleichenbacher-style forgery attack when small public exponents are deployed, permitting AUTH payload spoofing and peer impersonation; (2) a denial-of-service vector via malformed hash encoding that triggers assertion failures, forcing daemon restart. The root causes map to CWE-347 (Improper Verification of Cryptographic Signature) and CWE-617 (Reachable Assertion).

Business impact

Organizations deploying Libreswan as a VPN termination point or IPsec gateway face two material risks. Authentication bypass enables an attacker to establish seemingly legitimate tunnel endpoints, potentially redirecting sensitive traffic or injecting data into encrypted sessions. Repeated DoS attacks can disrupt VPN availability, isolating remote workers or branch offices. The threat is particularly acute in environments where Libreswan peers are exposed to untrusted networks without additional out-of-band peer authentication. However, the limitation to authentication payload forgery—not encryption bypass or certificate validation failure—constrains the exposure compared to lower-level IPsec implementation flaws.

Affected systems

Libreswan versions prior to the patched release are vulnerable. The flaw is most severe when Libreswan instances are configured to accept peers using small RSA exponents (e=3), a practice still seen in legacy deployments. Any Libreswan instance performing IKEv2 authentication with RSA signatures is susceptible to the DoS vector. Verify your installed version against the official Libreswan security advisory to determine applicability.

Exploitability

The authentication forgery requires sophisticated cryptographic attack execution and is most practical against deployments using small RSA exponents. Real-world Bleichenbacher attacks are non-trivial but have been demonstrated in the literature. The DoS vector is trivial to exploit—an attacker need only craft a single malformed IKEv2 packet—making sustained denial of service a realistic threat if the attacker has network-level access to the IKE peer. No public exploit code is known, and active exploitation in the wild has not been reported as of publication.

Remediation

Apply the patched Libreswan version released by the project. Verify against the official Libreswan security advisory for the specific version number addressing this CVE. As an interim mitigation, disable or restrict IKEv2 authentication using RSA signatures where feasible, substituting ECDSA or other asymmetric algorithms if peer configurations permit. Restrict IKE listener access via firewall rules to known, trusted peer IP ranges. Monitor Libreswan daemon logs for repeated crashes or authentication failures.

Patch guidance

Consult the official Libreswan project security advisory and release notes to identify the patched version that addresses CVE-2026-50722. Apply updates through your standard change management process, testing in a pre-production environment first. Given the DoS vector's ease of exploitation, prioritize patching on production IKE gateways. A daemon restart is required for the new code to take effect.

Detection guidance

Monitor Libreswan logs for repeated daemon crashes, assertion failures, or authentication errors coinciding with IKEv2 AUTH payload processing. Elevated rates of IKEv2 packet rejections or malformed signature rejections may signal attack attempts. Network-level detection is challenging without deep IKEv2 inspection; however, anomalous spikes in failed IKE_SA_INIT or IKE_AUTH exchanges from unusual sources warrant investigation. Correlate with firewall and endpoint logs to identify potential attacker infrastructure.

Why prioritize this

This vulnerability merits urgent attention due to its CVSS 8.1 HIGH severity, the feasibility of sustained DoS attacks, and the authentication impersonation risk in certain configurations. While not yet in CISA KEV and without public exploits, the combination of authentication bypass and denial-of-service capabilities, coupled with Libreswan's prevalence in enterprise and service-provider VPN deployments, creates substantial business risk. Organizations relying on Libreswan for critical network segmentation should prioritize patching.

Risk score, explained

The CVSS 8.1 score reflects high-impact confidentiality and integrity compromise (authentication forgery), high availability impact (DoS), and network-adjacent attack vector. The 'High' constraint on attack complexity reflects the cryptographic sophistication required for the forgery vector, which tempers the score relative to a trivial DoS-only flaw. The network-accessible nature and lack of authentication/UI barriers elevate the score despite the AC:H requirement.

Frequently asked questions

Can this vulnerability allow an attacker to decrypt existing IPsec traffic?

No. The flaw is confined to IKEv2 authentication payload validation. It does not compromise the underlying encryption or integrity protection of IPsec traffic itself. Once a malicious peer is authenticated (via the forgery vector), they could potentially redirect or inject new traffic, but they cannot retroactively decrypt previously encrypted sessions.

Does my deployment using ECDSA signatures for IKEv2 AUTH instead of RSA avoid this risk?

The DoS vector (malformed hash encoding triggering assertions) is specific to the RSA signature verification function described in the CVE. Deployments using ECDSA or other asymmetric algorithms are not affected. However, verify your peer configurations to confirm all IKEv2 AUTH exchanges use ECDSA exclusively.

Is updating Libreswan enough, or do I need to revoke and reissue certificates?

Updating Libreswan and restarting the daemon is sufficient. X.509 certificate validation is not affected by this vulnerability, so existing certificates remain valid and trusted. You do not need to reissue or revoke IKE certificates solely to address CVE-2026-50722.

If I restrict IKE access to known peer IPs via firewall rules, can I defer patching?

Firewall restrictions meaningfully reduce exposure and are a valid interim measure while patch testing is underway. However, they do not eliminate risk if any allowed peer is compromised or if an attacker is positioned on the network path to a trusted peer. Patching should not be deferred indefinitely.

This analysis is provided for informational and educational purposes. The technical details, severity assessments, and remediation guidance are based on the CVE description and CVSS vector as published. Organizations must verify patch availability and applicability against official Libreswan security advisories before deploying updates. SEC.co does not provide legal, compliance, or detailed incident response advice. Consult your vendor, security team, and relevant compliance frameworks when determining remediation timelines. No exploit code or weaponized proof-of-concept is provided or referenced herein. Source: NVD (public-domain), retrieved 2026-08-11. Analysis generated by SEC.co (claude-haiku-4-5).