CVE-2026-69249

What it actually does

The flaw is a network-reachable denial-of-service condition in python-cryptography certificate chain validation before version 49.0.0. When an invalid certificate chain contains duplicate copies of self-signed certificates, the chain-building logic recursively re-evaluates the same candidate certificates instead of de-duplicating previously analyzed candidates. Chain depth limits prevent infinite recursion, but the repeated work causes exponential CPU amplification and can make rejection of a malicious certificate chain take several seconds per attempt. The issue does not allow certificate validation bypass, code execution, data disclosure, or integrity compromise; the impact is availability degradation in services that validate attacker-supplied X.509 certificate chains.

Why it matters to the business

Applications that accept or validate untrusted TLS, mTLS, S/MIME, client certificate, signing, or other X.509 certificate chains could be slowed or made unavailable by repeated malicious validation attempts. This can affect public-facing APIs, authentication gateways, service-to-service mTLS endpoints, certificate enrollment workflows, scanners, and backend workers that process uploaded or remote certificates. The CVSS availability impact is high, but current EPSS is low and there is no known CISA KEV listing or reported ransomware use, so urgency should be driven by exposure: internet-facing or high-volume certificate-validation services should patch promptly, while internal-only uses should be remediated during normal dependency update cycles.

How an attack unfolds

An attacker identifies an application path that causes python-cryptography to validate a certificate chain they can influence, such as a TLS client-certificate handshake, a certificate upload endpoint, a webhook or federation connector, or a service that validates remote peer certificates. The attacker constructs an invalid chain containing repeated duplicate self-signed certificates. When the vulnerable library attempts to build and reject the chain, its recursive chain-resolution routine revisits the same candidates many times, consuming disproportionate CPU time before eventually failing validation. By sending these chains repeatedly or in parallel, the attacker can exhaust worker threads, event-loop capacity, CPU, or request queues, causing timeouts, increased latency, failed authentications, or service unavailability. Exploitation does not require authentication, user interaction, or successful certificate validation if the vulnerable path is reachable by an unauthenticated network peer.

How to fix it

Upgrade python-cryptography to version 49.0.0 or later wherever certificate chain validation may process untrusted input. If the package is bundled by an application, container image, virtual environment, serverless layer, appliance, or transitive dependency, rebuild and redeploy those artifacts after updating. Where immediate upgrade is not possible, reduce exposure by rate-limiting certificate validation endpoints, limiting certificate chain size and duplicate certificates before invoking library validation, enforcing handshake/request timeouts, capping concurrent unauthenticated TLS or certificate-processing operations, and isolating certificate-validation workers so resource exhaustion cannot take down unrelated services. These mitigations reduce exploitability but should not be treated as a substitute for upgrading.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, build artifacts, and dependency locks resolve python-cryptography/cryptography to 49.0.0 or later. Use package inventory tooling, SBOMs, `pip show cryptography`, `python -m pip show cryptography`, `pip freeze`, lockfiles, and container image scans to verify runtime versions rather than only source repositories. Exercise representative certificate-validation paths with normal valid and invalid chains to ensure functionality remains intact after upgrade. For exposure validation, identify services that accept client certificates, uploaded certificates, or remote certificate chains and confirm they enforce request limits, timeouts, and concurrency controls. If safe test tooling is available, compare pre- and post-upgrade handling time for malformed chains with duplicate self-signed certificates; fixed versions should reject without the vulnerable exponential slowdown.

Typical attack path

1. Locate a service or workflow that validates attacker-controlled X.509 certificate chains using python-cryptography before 49.0.0.
2. Prepare an invalid certificate chain that includes duplicate copies of self-signed certificates.
3. Submit the chain through a reachable validation path, such as a TLS/mTLS handshake, certificate upload, API request, or backend certificate-processing job.
4. Trigger recursive chain-building behavior that repeatedly analyzes the same certificate candidates and spends excessive CPU time before rejecting the chain.
5. Repeat requests concurrently to consume CPU, workers, sockets, queues, or timeouts until the service becomes slow or unavailable.

How to detect it

Look for evidence of resource-exhaustion attempts against services that validate X.509 certificate chains. Relevant log sources include application logs, TLS/mTLS gateway logs, reverse proxy logs, load balancer telemetry, web server error logs, certificate-processing service logs, Python exception logs, APM traces, CPU and worker saturation metrics, and network captures of TLS handshakes or certificate upload requests. Investigate bursts of failed certificate validation, repeated TLS handshake failures, request timeouts, elevated CPU without corresponding traffic volume, worker pool exhaustion, or many invalid certificate chains from the same source address or autonomous system. In packet captures or retained request artifacts, look for certificate chains containing repeated identical self-signed certificates or the same subject/issuer/serial/fingerprint appearing multiple times in one submitted chain. If Python stack traces, profiling data, or APM spans are available, search for excessive time spent in cryptography X.509 verification routines, especially recursive chain-building. Absence of a unique exploit string means detection should combine behavioral signals with certificate-chain artifact analysis.

• build_chain_inner
• cryptography.x509.verification
• duplicate self-signed certificate
• certificate chain contains duplicate
• TLS handshake failed
• certificate verify failed
• invalid certificate chain
• x509 verification timeout
• worker timeout during certificate validation
• repeated identical certificate fingerprint in chain

What your security team should do

• Prioritize upgrading internet-facing, unauthenticated, or high-throughput services that validate client-supplied X.509 certificate chains to cryptography 49.0.0 or later.
• Inventory Python applications, containers, virtual environments, and vendor-delivered components for cryptography versions before 49.0.0, including transitive dependencies.
• Add or verify rate limits, connection limits, handshake timeouts, request body limits, and worker isolation around certificate-validation entry points.
• Review TLS/mTLS gateways, certificate upload APIs, identity federation components, certificate enrollment services, scanners, and asynchronous workers for exposure to attacker-controlled certificate chains.
• Monitor for spikes in TLS handshake failures, certificate-validation errors, CPU saturation, worker timeouts, and repeated invalid certificate submissions from the same sources.
• Because this is not currently in KEV and EPSS is low, align remediation priority to exposure and service criticality, but do not defer patching for public certificate-validation surfaces.