Botan patches certificate verification bypass via trust anchor confusion
TL;DR — A certificate-store logic error in Botan can cause X.509 verification to accept an attacker-controlled end-entity certificate as a trusted root, bypassing certificate authentication.
What happened
Botan is a C++ cryptography library that implements TLS and X.509 certificate handling for applications that embed it.
CVE-2026-34580 describes a Critical certificate verification bypass introduced in Botan 3.11.0. The root cause is Certificate_Store::certificate_known: it returns true when any certificate in the store has a matching DN (and subject key identifier, if set), without verifying the found certificate is actually identical to the input certificate. In Botan 3.11.0, path validation logic was extended and assumed certificate_known only returns true for identical certificates, creating a trust decision based on a weaker match.
Per the CVE record, if an end-entity certificate is presented and its DN (and subject key identifier, if set) match that of any trusted root, the end-entity certificate can be accepted immediately as if it itself were a trusted root.
| Item | Source value |
|---|---|
| Affected package | botan |
| Affected versions | >= 3.11.0, < 3.11.1 |
| Severity | CVSS v4.0 9.3 (Critical) |
| CVSS v4.0 vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N |
Certificate validation bugs are high-leverage: they sit directly on the identity boundary for TLS and any higher-level auth built on top of it. Even when the triggering conditions are subtle (DN/SKI matching), they tend to be “single mistake, broad blast radius” flaws for every app shipping the library.
Who is impacted
- Projects embedding or linking against Botan versions reported as affected in the CVE record (
>= 3.11.0, < 3.11.1). - Any service using Botan for X.509 certificate verification (e.g., TLS client/server verification or certificate-based authentication flows).
- Environments where a failure in certificate authentication would enable unauthorized service impersonation or trust establishment.
What to do now
- Follow vendor remediation guidance and apply the latest patched release available at the time of writing.
"This vulnerability is fixed in 3.11.1."
- Identify where Botan is pulled into your fleet (vendored source, system packages, container base images, statically linked binaries) and verify the shipped Botan version.
- Treat this as an authentication-boundary flaw:
- review where certificate validation outcomes directly gate access (mTLS, client cert auth, service-to-service trust)
- if you suspect abuse, investigate certificate verification failures/successes and unexpected peer identities around the time window of exposure
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.