CVE-2026-34073: Python Cryptography Information Disclosure

CVE-2026-34073 Overview

CVE-2026-34073 is a Certificate Validation Bypass vulnerability in the Python cryptography package, a widely-used library designed to expose cryptographic primitives and recipes to Python developers. The vulnerability exists in how DNS name constraints are validated during certificate verification, specifically affecting how excluded subtree constraints in parent certificates are enforced against peer names.

Prior to version 46.0.6, DNS name constraints were only validated against Subject Alternative Names (SANs) within child certificates, not the "peer name" presented during each validation. This oversight allows an attacker to bypass certificate chain constraints that should prevent certain domain names from being considered valid.

Critical Impact

An attacker could use a wildcard leaf certificate (e.g., *.example.com) to successfully validate a peer name (e.g., bar.example.com) even when the certificate chain explicitly excludes that subdomain through name constraints, potentially enabling man-in-the-middle attacks.

Affected Products

• Python cryptography package versions prior to 46.0.6

Discovery Timeline

• March 31, 2026 - CVE-2026-34073 published to NVD
• April 1, 2026 - Last updated in NVD database

Technical Details for CVE-2026-34073

Vulnerability Analysis

This vulnerability falls under CWE-295 (Improper Certificate Validation). The flaw resides in the certificate chain validation logic within the cryptography library's X.509 certificate verification mechanism.

X.509 Name Constraints are a critical security feature that allows Certificate Authorities (CAs) to restrict which domain names can appear in certificates issued under a specific intermediate CA. These constraints include "excluded subtrees" which explicitly forbid certain domain patterns from being valid within the certificate hierarchy.

The cryptography library correctly validated these name constraints against the Subject Alternative Names embedded within child certificates. However, the validation process failed to apply these same constraints to the "peer name" - the actual hostname being verified during a TLS handshake or certificate validation operation.

This creates a dangerous gap in security validation. When a client connects to a server and validates its certificate, the peer name check bypasses the excluded subtree constraints that would normally prevent certain domains from being trusted.

Root Cause

The root cause lies in incomplete validation logic within the certificate verification code path. The name constraint checking was implemented for SAN validation but was not extended to peer name validation. This architectural oversight means that while the certificate itself may comply with name constraints, the actual hostname being validated against that certificate does not undergo the same constraint checks.

The wildcard certificate matching logic compounds this issue, as a certificate for *.example.com would be accepted for bar.example.com even when bar.example.com is explicitly excluded in a parent certificate's name constraints extension.

Attack Vector

The vulnerability requires network access to exploit, as it involves certificate validation during network communications. An attacker could potentially exploit this flaw through a man-in-the-middle attack scenario:

1. The attacker obtains or controls a valid wildcard certificate for a domain (e.g., *.example.com)
2. The certificate chain contains a parent certificate that explicitly excludes certain subdomains (e.g., bar.example.com) via name constraints
3. Despite this exclusion, the attacker can present this certificate when a client attempts to connect to bar.example.com
4. Due to the validation bypass, the cryptography library accepts the certificate as valid for the excluded subdomain

The vulnerability mechanism involves the disconnect between SAN-based constraint validation and peer name validation. When validating a certificate chain, the library properly checks that the leaf certificate's SANs don't violate parent name constraints, but fails to apply the same check when the actual peer name is compared against the certificate. For detailed technical information, see the GitHub Security Advisory.

Detection Methods for CVE-2026-34073

Indicators of Compromise

• Unexpected TLS connections succeeding to subdomains that should be excluded by name constraints
• Certificate validation logs showing accepted certificates for domains matching excluded subtree patterns
• Applications connecting to potentially spoofed endpoints despite properly configured certificate hierarchies

Detection Strategies

• Review application dependency manifests for cryptography package versions below 46.0.6
• Audit TLS connection logs for connections to sensitive subdomains that rely on name constraint protection
• Implement certificate transparency monitoring for domains protected by name constraints
• Use software composition analysis (SCA) tools to identify vulnerable cryptography installations

Monitoring Recommendations

• Monitor for anomalous TLS handshakes to subdomains expected to be blocked by name constraints
• Set up alerts for certificate validation events involving wildcard certificates against specific subdomain patterns
• Track dependency version updates across Python applications using the cryptography library

How to Mitigate CVE-2026-34073

Immediate Actions Required

• Upgrade the cryptography package to version 46.0.6 or later immediately
• Audit all Python applications using the cryptography library for TLS/certificate validation
• Review any systems relying on X.509 name constraints for security boundaries
• Consider additional hostname verification layers until patching is complete

Patch Information

The vulnerability has been addressed in cryptography version 46.0.6. The fix ensures that DNS name constraints, including excluded subtrees, are properly validated against both the certificate's Subject Alternative Names and the peer name during validation. For additional details, refer to the GitHub Security Advisory for GHSA-m959-cc7f-wv43.

Workarounds

• Implement additional hostname verification at the application layer as a defense-in-depth measure
• Consider network-level controls to restrict access to sensitive subdomains that rely on name constraint protection
• Deploy monitoring to detect exploitation attempts while awaiting patch deployment

# Upgrade cryptography package to patched version
pip install --upgrade cryptography>=46.0.6

# Verify installed version
pip show cryptography | grep Version