pypi package report

Is cryptography safe?

24 known vulnerabilities, worst severity HIGH.

// reach

3 direct dependencies

none carry a known advisory

    727 packages depend on it

    an advisory here reaches each of them

    • 3lc
    • a2a-sdk
    Create a free accountfor every dependency path, dependent and what to upgrade
    // ai model usage

    No published models are known to use this package.


    cvss
    8.7
    high

    CVSS v4.0 base score out of 10

    epss
    0.26%
    low

    chance of exploitation in 30 days, 18th percentile of all CVEs

    xyz score
    5.0
    medium

    CyberXYZ composite out of 10

    fig. 01 — GHSA-jwv3-5hgf-82ww, the advisory selected below

    // 24 advisories

    GHSA-jwv3-5hgf-82ww

    HIGHGitHub ratingCVE-2026-69249
    // 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.

        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.

              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.

    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 
    // cvss v4.0 vector

    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

    Attack vector
    Network
    Attack complexity
    Low
    Attack requirements
    None
    Privileges required
    None
    User interaction
    None
    Confidentiality (vulnerable system)
    None
    Integrity (vulnerable system)
    None
    Availability (vulnerable system)
    High
    Confidentiality (subsequent systems)
    None
    Integrity (subsequent systems)
    None
    Availability (subsequent systems)
    None

    Checked 2026-11-06 at 21:01 UTC. The most recent advisory here was published 2026-08-03. Updated continuously from NVD, GHSA, OSV and CNA feeds.

    Think a verdict here is wrong? Tell us — we respond within 2 business days.