Botan CVE-2026-34580

Remote unauthenticated attacker can present a crafted end-entity certificate with matching DN and subject key identifier to Botan 3.11.0 during X.509 certificate path validation. No victim interaction required; exploitation occurs during certificate chain verification in default configurations.

This vulnerability presents critical real-world risk despite limited version exposure. The CVSS v4.0 score of 9.3 reflects maximum network attack surface (AV:N), no authentication requirements (PR:N), low attack complexity (AC:L), and high impact across confidentiality, integrity, and availability (VC:H/VI:H/VA:H). An attacker needs only to obtain or generate a certificate with DN and SKI matching any trusted root-trivial for publicly-known root CA attributes-to completely bypass certificate chain validation. This enables man-in-the-middle attacks against any TLS connection validated by Botan 3.11.0, with automatable exploitation requiring minimal skill. However, risk is substantially mitigated by the narrow affected version range (only 3.11.0, released recently) and rapid patch availability in 3.11.1. No EPSS score is provided, and no CISA KEV listing exists, indicating no confirmed active exploitation. The vulnerability is not a zero-day; it was publicly disclosed through GitHub Security Advisory GHSA-v782-6fq4-q827 with immediate patch availability. Organizations using Botan 3.11.0 in production TLS implementations face severe risk and should prioritize immediate remediation, while those on earlier versions (3.10.x or below) or who have already updated to 3.11.1+ are not affected.

An attacker intercepts TLS traffic destined for a legitimate server protected by a certificate chain rooted in a well-known CA like DigiCert or Let's Encrypt. The attacker generates a self-signed certificate with DN field cn=DigiCert Global Root G2 and matching Subject Key Identifier extracted from the public root certificate. When the victim application using Botan 3.11.0 validates the attacker's certificate, Certificate_Store::certificate_known matches the DN and SKI against its trusted root store and incorrectly returns true, causing the malicious certificate to be accepted as a trusted root without cryptographic verification. The attacker establishes a man-in-the-middle position, decrypting and potentially modifying all TLS traffic. This scenario requires only network interception capability and knowledge of public root CA attributes, making it automatable and highly practical against vulnerable deployments.