CVE-2024-39312

What it actually does

The X.509 name constraint parser accepts certificates containing both permittedSubtrees and excludedSubtrees yet only evaluates the permitted list, allowing a subject name that matches an excluded subtree to pass validation.

Why it matters to the business

Systems relying on Botan for certificate validation may trust certificates that should have been rejected, increasing the chance of unauthorized access or man-in-the-middle connections in TLS-protected services.

How an attack unfolds

An attacker generates an X.509 certificate that includes both a permitted subtree and an excluded subtree for the same name space, ensuring the target identity is covered by the excluded rule. When the certificate is presented to an application using the vulnerable Botan library, the parser skips the excluded-subtree check and accepts the certificate, allowing the attacker to establish a trusted TLS session.

How to fix it

Upgrade Botan to version 3.5.0 or 2.19.5. Rebuild and redeploy all dependent applications after the library update. Until the upgrade is complete, consider additional certificate-policy enforcement layers outside Botan.

How to confirm the fix worked

Confirm the installed Botan version is 3.5.0 or later. Test validation behavior with a certificate that contains both permitted and excluded subtrees covering the same name; the certificate must now be rejected.

Typical attack path

1. Locate services that use Botan to validate X.509 certificates
2. Craft or obtain a certificate containing both permittedSubtrees and excludedSubtrees with the target identity in the excluded list
3. Present the certificate during a TLS handshake or other certificate validation operation
4. Obtain acceptance of the certificate and proceed with the intended attack (MITM, impersonation, etc.)

How to detect it

Review application logs for certificate validation events around the time of suspected incidents; look for accepted certificates whose subject names would normally be excluded by name constraints. No reliable post-exploitation IOCs are available because the flaw is a silent acceptance during parsing.

What your security team should do

• Immediately schedule upgrade to Botan 3.5.0 or 2.19.5 across all affected products
• Inventory internal and third-party software that statically or dynamically links Botan
• Add version checks and automated rebuild pipelines to prevent reintroduction of older Botan releases
• Review certificate-validation code paths for any custom name-constraint handling that might mask the issue