External risk intelligence

Botan Certificate Store Trust Bypass Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-34580

Botan is a C++ cryptographic library intended for integration into other software as a development dependency. It is not a standalone internet-facing service, appliance, or application. Its presence depends on how developers implement it within their own products, and it does not inherently create a public-facing network presence.

Botan Project Botan

3.11.0

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This advisory concerns a flaw in the Botan C++ cryptography library that could allow an attacker to trick the system into accepting a malicious certificate as trustworthy. This occurs when a certificate's identifying information matches that of a trusted root, leading the system to bypass proper validation. The main concern is confirming relevance and exposure.

Cryptography library improperly trusts some certificates.
Critical flaw could allow acceptance of invalid certificates.
Confirm if your systems use this library.

Attack Path

How an attacker could exploit the issue

An attacker could trick a system using the Botan library into accepting a fraudulent certificate. This occurs when an end-entity certificate shares the same identifying information as a trusted root certificate, causing the library to incorrectly believe it is a trusted root and accept it without proper verification. This can lead to the acceptance of malicious or untrusted certificates, potentially compromising the security of the system.

No authentication or user interaction needed.
Malicious certificate triggers acceptance.
Compromised trust in digital certificates.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow an end-entity certificate to be accepted as a trusted root when its distinguished name and subject key identifier match a trusted root, bypassing intended certificate validation logic. This occurs when the Botan library is used in a context where certificate path validation is performed, and specific conditions of certificate matching are met.

Trusted root certificates could be impersonated.
Malicious certificates may be accepted as trusted.
Unintended trust could be established in the chain.

Operational Fix

Recommended remediation, mitigation, and detection steps

The Botan cryptographic library, specifically version 3.11.0, contains a flaw in its certificate validation logic that could allow an attacker to present a fraudulent end-entity certificate and have it accepted as a trusted root. This requires identifying where Botan is deployed, assessing its exposure to untrusted inputs, and understanding which teams manage the applications that depend on this library. The initial step involves locating all instances of the affected Botan version and determining their criticality and reachability.

Application owners and platform teams.
Verify vulnerable Botan deployments and exposure.
Coordinate vendor updates and application testing.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is the Botan library?

Botan is a C++ library that provides developers with a suite of cryptographic tools, such as encryption, hashing, and digital signature verification. It is typically integrated as a backend dependency within larger software applications to secure data and communications, rather than operating as a standalone program that a user would run directly.

What is the weakness in CVE-2026-34580?

This vulnerability is classified as Improper Certificate Validation (CWE-295). It occurs because a function incorrectly identifies certificates by only comparing their names and identifiers. Instead of verifying that the certificate is actually a trusted root, the library mistakenly accepts any certificate that shares the same identifying details, allowing unauthorized certificates to be treated as legitimate.

How does an attacker trigger this certificate bypass?

An attacker triggers this by presenting a fraudulent end-entity certificate that mimics the identifying information—specifically the distinguished name and subject key identifier—of a trusted root. Simply having a certificate is not enough; the bug only manifests when the application uses the flawed library to perform certificate path validation. It does not trigger if the application does not perform these specific validation checks.

Why should I care about this vulnerability?

You should care if your software relies on Botan 3.11.0 to verify digital identities or establish secure connections. While Halo Surface Signal notes that Botan itself is a library and not a standalone internet-facing service, your application's exposure depends on whether it uses this library to process untrusted network inputs where certificate spoofing could lead to unauthorized access or data interception.

How do I address this Botan vulnerability?

The primary step is to identify all software components in your environment that include Botan version 3.11.0 as a dependency. Once located, coordinate with your development teams to update the library to version 3.11.1, which contains the corrected validation logic. Testing is essential after the update to ensure that certificate chain verification functions correctly in your specific implementation.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.