CVE-2026-34073

What it actually does

The flaw is an X.509 certificate path validation weakness in Python's cryptography package prior to version 46.0.6. DNS name constraints in parent or intermediate CA certificates were checked against Subject Alternative Names in child certificates, but not against the peer name supplied by the application during certificate validation. As a result, a wildcard certificate such as *.example.com could be accepted for a constrained name such as bar.example.com even when an issuing CA higher in the chain explicitly excluded that DNS subtree. The practical impact is limited integrity loss in certificate identity validation: an application may incorrectly trust a TLS peer that should have been rejected under the CA's name constraints.

Why it matters to the business

Applications that rely on Python cryptography for certificate validation may connect to or accept connections from services whose certificates should be considered invalid under DNS name-constraint policy. This can weaken trust boundaries in private PKI, service-to-service authentication, mTLS deployments, and environments that use constrained certificate authorities to limit where certificates are valid. The CVSS score is moderate and EPSS is very low, with no known KEV listing or mature public exploit reported, so urgency is lower than for actively exploited remote-code-execution issues; however, systems using constrained CAs or wildcard certificates should prioritize review because the impact is directly tied to trust enforcement.

How an attack unfolds

An attacker needs a certificate chain that is otherwise trusted by the target application and includes a parent or intermediate certificate with an excluded DNS subtree constraint. They then present a wildcard leaf certificate whose Subject Alternative Name matches the victim application's peer-name check, while the actual peer name falls within a DNS subtree that should have been excluded by the parent certificate. In vulnerable versions, cryptography validates the DNS name constraints only against the child certificate SANs and fails to apply the excluded subtree check to the peer name passed into validation. If the application depends on this validation result for TLS or identity trust, the malicious or unauthorized endpoint may be accepted as legitimate. Exploitation is situational and requires specific PKI conditions, application use of cryptography's affected validation behavior, and the ability to present a suitable certificate chain.

How to fix it

Upgrade the Python cryptography package to version 46.0.6 or later wherever certificate validation is performed. Because no fixed version list was provided in the input beyond the advisory text, use 46.0.6 as the minimum safe upstream version. Rebuild and redeploy applications, containers, virtual environments, serverless packages, and dependency bundles that vendor or pin cryptography below 46.0.6. If immediate upgrade is not possible, reduce exposure by avoiding reliance on constrained CAs with wildcard certificates in affected validation paths, adding explicit application-level hostname deny checks for excluded DNS subtrees, and validating critical certificate chains with a patched library or an independent verifier. Confirm that transitive dependencies do not pin an older cryptography release.

How to confirm the fix worked

Confirm exposure by inventorying Python environments and dependency lockfiles for cryptography versions earlier than 46.0.6. Check pip freeze, pipdeptree, poetry.lock, Pipfile.lock, requirements files, container SBOMs, and runtime package metadata. Validate remediation by confirming cryptography reports version 46.0.6 or later in the deployed runtime, not only in source repositories. For functional validation, construct or obtain a test certificate chain with a parent or intermediate CA containing an excluded DNS subtree and a wildcard leaf certificate, then verify that peer validation for an excluded DNS name is rejected after patching. Also review application code paths that use cryptography.x509 verification APIs or wrappers that perform certificate path and hostname validation.

Typical attack path

1. Identify a Python application or service that uses a vulnerable version of the cryptography package for X.509 certificate validation.
2. Determine that the target relies on DNS name constraints in a private or constrained CA hierarchy.
3. Obtain or control a certificate chain containing a wildcard leaf certificate that appears valid for the target peer name.
4. Ensure the parent or intermediate CA contains an excluded subtree constraint that should block the peer name, but where the vulnerable validation logic will not enforce it against the peer name.
5. Present the crafted certificate chain during TLS, mTLS, or another certificate-authenticated protocol exchange.
6. Rely on the vulnerable validation behavior to have the certificate accepted when it should be rejected.

How to detect it

This vulnerability does not provide a strong universal host-based IOC because exploitation is a logic flaw in certificate validation rather than code execution or file modification. To assess possible prior exploitation, review TLS, mTLS, service mesh, API gateway, reverse proxy, and application logs for accepted connections using wildcard certificates where the peer hostname falls under a DNS subtree excluded by an issuing CA's name constraints. Collect certificate chains from historical connection logs, packet captures, TLS telemetry, certificate transparency sources where applicable, and application debug logs that record peer certificates. Focus on periods before cryptography was upgraded to 46.0.6, especially services using private PKI or constrained intermediate CAs. Look for mismatches between the peer name used by the application and the DNS name-constraint policy in the certificate chain. Because no known threat actors, KEV exploitation, ransomware use, or mature public exploit are reported, detection should emphasize anomaly review of certificate validation outcomes rather than commodity malware indicators.

• cryptography==46.0.5
• cryptography==46.0.4
• cryptography==46.0.3
• cryptography==46.0.2
• cryptography==46.0.1
• cryptography==46.0.0
• NameConstraints
• excludedSubtrees
• *.example.com
• bar.example.com
• cryptography.x509
• pip show cryptography
• pip freeze

What your security team should do

• Inventory all Python applications, containers, build artifacts, and virtual environments using cryptography prior to 46.0.6.
• Prioritize upgrades for systems using private PKI, constrained certificate authorities, wildcard certificates, mTLS, service mesh integrations, or custom certificate validation logic.
• Upgrade cryptography to 46.0.6 or later and redeploy affected services from clean dependency builds.
• Review dependency pins and transitive dependency constraints that may prevent cryptography from being updated.
• Add regression tests for name-constrained CA behavior, especially excluded DNS subtrees and wildcard leaf certificates.
• For high-trust internal PKI environments, audit recently issued wildcard certificates and constrained CA configurations for combinations that could have bypassed intended restrictions.
• Monitor for unexpected certificate chains, unusual wildcard certificate use, or connections to DNS names that should be excluded by CA policy.
• Track upstream cryptography advisories and package manager updates to ensure patched versions are consistently available across supported platforms.