CVE-2026-69248: 
Chainguard vulnerability analysis and mitigation

CVE-2026-69248 is an improper certificate validation vulnerability in the pyca/cryptography Python package that allows a verifier to accept invalid certificate chains by incorrectly handling wildcard DNS Subject Alternative Names (SANs) against permittedSubtrees name constraints. Specifically, if an intermediate constrained CA permits only foo.example.com, a leaf certificate with a wildcard SAN of *.example.com is incorrectly accepted, enabling escape outside the permitted name subtree. All versions up to and including 48.0.0 are affected; the issue is fixed in version 49.0.0. It carries a CVSS v4.0 base score of 6.9 (Medium) (Github Advisory). The advisory was published on July 31, 2026, and added to the GitHub Advisory Database on August 3, 2026 (Github Advisory).

The root cause is classified as CWE-295 (Improper Certificate Validation) and resides in the DNSConstraint::matches function within the Rust-based cryptography-x509-verification crate. The original implementation treated a wildcard DNS SAN (e.g., *.example.com) as matching a permittedSubtrees constraint (e.g., foo.example.com) using the same logic as excludedSubtrees, without distinguishing between the two semantics: for permittedSubtrees, every name the wildcard can expand to must fall within the constraint, whereas for excludedSubtrees, any overlap suffices. The fix (PR #14888, commit 4d035a4) introduces a SubtreeKind enum to dispatch between DNSConstraint::permits (containment check) and DNSConstraint::excludes (overlap check) depending on context, correctly rejecting *.example.com when the permitted subtree is only foo.example.com (pyca PR #14888, pyca commit). A standalone proof-of-concept demonstrating the bypass is publicly available in the advisory (Github Advisory).

Successful exploitation allows an attacker who controls a certificate issued by a constrained intermediate CA to present a leaf certificate with an overly broad wildcard SAN that the verifier incorrectly accepts, effectively bypassing the name constraint enforcement mandated by RFC 5280 §4.2.1.10. This results in acceptance of an invalid certificate chain, with high integrity impact (unauthorized trust decisions) and low confidentiality impact (potential exposure of data to an impersonating endpoint). Availability is not directly affected. The practical risk is that a sub-CA constrained to a narrow domain (e.g., foo.example.com) could issue a wildcard certificate accepted as valid for sibling domains (e.g., bar.example.com), enabling impersonation or man-in-the-middle attacks against applications relying on pyca/cryptography's X.509 verifier (Github Advisory).

A proof-of-concept (PoC) is publicly available in the GitHub Security Advisory and was confirmed by NVD's SSVC assessment as poc exploitation status (Github Advisory). The EPSS score is approximately 0.185% (8th percentile), indicating a low but non-negligible probability of exploitation in the near term. Exploitation requires specific attack prerequisites (AT:P): the attacker must be positioned to present a crafted certificate chain to a system using the vulnerable verifier. No in-the-wild exploitation or threat actor attribution has been reported, and the vulnerability is not currently listed in the CISA KEV catalog. Detection plugins are available from Qualys (ID 5016621) and Nessus (ID 331884) (Github Advisory).

1. Obtain a constrained intermediate CA certificate: Acquire or compromise an intermediate CA that has a permittedSubtrees name constraint limiting it to a specific DNS name (e.g., foo.example.com).
2. Issue an overly broad wildcard leaf certificate: Using the constrained intermediate CA's key, issue a leaf certificate with a DNS SAN of *.example.com — broader than the permitted subtree foo.example.com.
3. Present the certificate chain to a vulnerable verifier: Submit the chain (root → constrained sub-CA → wildcard leaf) to a Python application using pyca/cryptography ≤ 48.0.0 for TLS or X.509 path validation.
4. Trigger the bypass: The vulnerable DNSConstraint::matches logic incorrectly accepts *.example.com as satisfying the foo.example.com permitted constraint, causing the verifier to trust the chain.
5. Impersonate sibling domains: With the accepted wildcard certificate, the attacker can impersonate any *.example.com host (e.g., bar.example.com) to clients using the vulnerable verifier, enabling man-in-the-middle interception or data exfiltration (Github Advisory, pyca PR #14888).

• Logs: Application logs showing successful TLS handshakes or certificate verifications for domains outside the expected permitted subtree of a constrained CA (e.g., connections to bar.example.com when only foo.example.com should be trusted).
• Network: Unexpected TLS connections to sibling domains not covered by the constrained CA's permitted subtree; certificate chains presented during TLS negotiation where the leaf SAN wildcard (e.g., *.example.com) is broader than the intermediate CA's permittedSubtrees extension.
• File System: Presence of pyca/cryptography package version ≤ 48.0.0 in Python environments (pip show cryptography or inspection of site-packages).

Upgrade pyca/cryptography to version 49.0.0 or later, which contains the fix introduced in commit 4d035a4 (pyca commit). No configuration-based workaround is available; the only remediation is upgrading the package. Organizations using constrained intermediate CAs in PKI deployments with Python applications should prioritize this update, particularly where name constraints are relied upon for security boundaries (Github Advisory).

The vulnerability was reported by randombit and remediated by woodruffw (a core pyca/cryptography maintainer), with the fix reviewed and merged by alex on May 22, 2026 (pyca PR #14888). The NixOS/nixpkgs project opened a tracking issue (NixOS/nixpkgs#549104) to backport the fix for affected package versions. The Yocto Project security mailing list also discussed the issue, indicating broad downstream awareness in embedded and Linux distribution communities (Github Advisory).