CVE-2026-69248

What it actually does

The flaw is an X.509 certificate path validation error in Python's cryptography package before version 49.0.0. When enforcing DNS name constraints from an intermediate CA, the verifier can incorrectly treat a wildcard DNS Subject Alternative Name such as *.example.com as valid under a narrower permitted constraint such as foo.example.com. Because a wildcard at the parent domain can match sibling names outside the constrained namespace, an invalid certificate chain may be accepted as trusted. The direct technical consequence is improper certificate chain acceptance, potentially allowing impersonation of TLS peers or services in applications that rely on python-cryptography's affected verifier behavior for certificate validation.

Why it matters to the business

Applications that depend on affected versions of the Python cryptography library may trust certificates they should reject, which can undermine authentication between services, APIs, clients, and infrastructure components. In practical terms, this could enable misissued or malicious certificates to be accepted in constrained-CA environments, increasing the risk of traffic interception, service impersonation, or unauthorized trust relationships. The current EPSS is low, it is not listed in CISA KEV, and no mature public exploitation is indicated, but the library is widely used across Python ecosystems, so exposure may be broad where the affected verifier functionality is used.

How an attack unfolds

An attacker would need a certificate chain involving a constrained intermediate CA where DNS name constraints are intended to limit valid leaf certificates to a specific permitted name or subtree. The attacker then obtains or presents a leaf certificate with a wildcard DNS SAN that should fall outside the permitted constraint when expanded, but is incorrectly accepted by the vulnerable verifier. A target application using an affected version of python-cryptography to validate the chain may accept the attacker-controlled certificate as valid. If the application uses that validation decision for TLS peer authentication, mutual TLS, service identity, or certificate-based authorization, the attacker may be able to impersonate an otherwise untrusted service or endpoint. Exploitation depends on the presence of constrained CA usage and application reliance on the affected verifier behavior, so this is more situational than a generic remote code execution flaw.

How to fix it

Upgrade the Python cryptography package to version 49.0.0 or later wherever it is used. Rebuild and redeploy applications, containers, virtual environments, serverless packages, and pinned dependency bundles that include older versions. If immediate upgrade is not possible, reduce risk by avoiding reliance on the affected verifier for constrained-CA validation, rejecting unexpected wildcard certificates in constrained CA contexts, enforcing application-level hostname allowlists for certificate identities, and using platform or library certificate validation paths known not to be affected. Review dependency lockfiles, base images, and transitive dependencies because cryptography is commonly bundled indirectly by Python frameworks, agents, SDKs, and security tooling.

How to confirm the fix worked

Confirm the installed package version is 49.0.0 or later in every runtime environment, not only in source repositories. Check dependency manifests and lockfiles such as requirements.txt, constraints.txt, Pipfile.lock, poetry.lock, uv.lock, pyproject.toml, conda environment files, and container image software bills of materials for cryptography versions below 49.0.0. Validate running systems by querying the package in the same interpreter, virtual environment, container, or serverless artifact used by the application. Where certificate validation is security-critical, add regression tests with a constrained intermediate CA and a wildcard DNS SAN leaf certificate that should be rejected, and confirm the patched verifier rejects the invalid chain.

Typical attack path

1. Identify an application or service that uses python-cryptography before 49.0.0 for X.509 certificate verification.
2. Find or create a certificate chain involving an intermediate CA with DNS name constraints that should limit valid names to a narrower DNS identity.
3. Obtain or present a leaf certificate containing a wildcard DNS Subject Alternative Name that can match names outside the constrained permitted identity.
4. Initiate a TLS or certificate-authenticated connection to the target application using the crafted certificate chain.
5. Rely on the vulnerable verifier accepting the invalid chain as trusted.
6. Use the resulting misplaced trust to impersonate a service, intercept traffic, or satisfy certificate-based authentication or authorization checks.

How to detect it

This vulnerability does not produce a universal exploit artifact because exploitation is a logic error in certificate validation rather than code execution. To assess possible prior exploitation, review application, reverse proxy, API gateway, service mesh, and mTLS logs for successful connections or authentications using wildcard certificates where a constrained intermediate CA should have allowed only a narrower DNS name. Focus on logs that capture TLS peer certificate details, including Subject Alternative Name, issuer, certificate chain, serial number, fingerprint, and authenticated principal. Look for wildcard SANs such as *.example.com being accepted in contexts where only a specific hostname such as foo.example.com or a narrower namespace should be permitted. Review certificate transparency, internal CA issuance records, and private PKI logs for leaf certificates with wildcard DNS SANs issued under constrained intermediates. If available, compare accepted certificate identities against expected service identity inventories and investigate mismatches, sibling-domain identities, unusual certificate serials, or new issuers appearing shortly after publication. There are no known public threat actors or ransomware campaigns associated with this issue based on the provided data.

What your security team should do

• Inventory Python applications, services, images, and packaged tools that include the cryptography package, prioritizing internet-facing services, mutual TLS endpoints, API gateways, identity components, service mesh integrations, and certificate-based authorization paths.
• Upgrade cryptography to 49.0.0 or later and redeploy affected artifacts, including pinned builds and container images.
• Search dependency lockfiles and SBOMs for cryptography versions below 49.0.0 and create remediation tickets for any remaining instances.
• Prioritize review of systems that use private PKI, constrained intermediate CAs, custom X.509 verification, mTLS, or certificate-based service identity because they are most likely to exercise the vulnerable code path.
• Add automated dependency scanning and CI policy checks to block cryptography versions below 49.0.0.
• If rapid upgrade is delayed, implement compensating controls that reject unexpected wildcard certificates in constrained trust domains and enforce explicit identity allowlists.
• Monitor certificate-validation failures and unusual successful authentications involving wildcard certificates, constrained CA chains, or unexpected peer identities.