CVE-2026-26007

What it actually does

The flaw is a missing elliptic-curve public key validation check in pyca/cryptography before version 46.0.5. When applications import or construct public keys using public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), or load_pem_public_key(), the library may fail to verify that a supplied point is in the expected prime-order subgroup for affected SECT curves. An attacker who can supply an elliptic-curve public key on a small-order subgroup can cause ECDH operations to leak partial information about the victim private key modulo the subgroup order, and can make ECDSA verification unsafe for signatures over that small subgroup. The impact is confidentiality loss of cryptographic private-key material or acceptance of forged signatures in applications that use affected SECT curves with attacker-controlled public keys.

Why it matters to the business

Organizations using affected versions of the Python cryptography package may have services whose trust decisions, authentication, key exchange, or message validation are weaker than expected if they rely on SECT elliptic curves and accept public keys from untrusted parties. The practical exploitability is constrained because only SECT curves are affected, attacker interaction with cryptographic key handling is required, and the listed EPSS is low with no known KEV listing or reported exploit maturity. However, affected cryptographic libraries are often embedded transitively in many Python applications, so inventory and dependency remediation are important to prevent long-lived exposure in authentication, encryption, signing, or protocol implementations.

How an attack unfolds

An attacker first identifies an application or protocol endpoint that uses pyca/cryptography before 46.0.5, accepts externally supplied elliptic-curve public keys, and uses one of the affected SECT curves. The attacker then crafts a public key point that is validly encoded but lies in a small-order subgroup rather than the expected prime-order subgroup. If the application uses that key in ECDH, the victim computes a shared secret using its private key and the attacker-controlled point; the resulting output can reveal information about the victim private key modulo the small subgroup order. Repeating this pattern across suitable interactions may incrementally expose private-key information. If the application uses the weak public key for ECDSA verification, signatures may be forgeable within the small subgroup, potentially allowing the attacker to bypass integrity or authentication checks where that public key is trusted.

How to fix it

Upgrade pyca/cryptography to version 46.0.5 or later wherever it is used directly or transitively. For source-based consumers, ensure the fix containing commit 06e120e682cb200e3f7050c02f0bcdac90c4c6ad is present. Rebuild and redeploy applications, containers, serverless functions, and packaged artifacts that vendor or pin the vulnerable library. Where immediate upgrade is not possible, reduce exposure by disabling SECT curves, rejecting externally supplied SECT public keys, restricting accepted curves to well-validated modern curves such as NIST P-256/P-384/P-521 or X25519/X448 where appropriate, and adding explicit public-key validation in application code or protocol gateways. Rotate cryptographic private keys if there is credible evidence that vulnerable ECDH operations with attacker-controlled SECT public keys occurred.

How to confirm the fix worked

Confirm package versions with dependency tooling such as pip show cryptography, pip freeze, poetry show cryptography, pip-audit, safety, osv-scanner, or software composition analysis tools. Validate that all runtime images and deployment artifacts contain cryptography 46.0.5 or later, not only source repositories. Search code and configuration for SECT curve usage and for calls to load_der_public_key(), load_pem_public_key(), EllipticCurvePublicNumbers.public_key(), or public_key_from_numbers() where input may be untrusted. Add or run regression tests that attempt to load crafted small-subgroup public keys for affected SECT curves and confirm they are rejected after the update. For services, verify that curve negotiation or accepted-key policy no longer permits affected SECT curves unless the patched library is in use and the business need is documented.

Typical attack path

1. Find a Python application, service, library, or protocol implementation using pyca/cryptography before 46.0.5.
2. Determine whether the application accepts attacker-controlled DER, PEM, or constructed elliptic-curve public keys.
3. Confirm that affected SECT curves are allowed or negotiated by the application.
4. Submit a specially crafted small-subgroup public key through the normal certificate, key exchange, API, file upload, token, or protocol input path.
5. Trigger an ECDH operation to obtain outputs that leak information about the victim private key, or trigger ECDSA verification using the attacker-controlled weak public key.
6. Use the leaked key information or forged signature capability to undermine confidentiality or bypass integrity/authentication checks in the affected workflow.

How to detect it

There are usually no reliable network or host indicators showing exploitation of this class of cryptographic validation flaw because attacks can look like normal key exchange, certificate handling, or signature verification. Focus on exposure assessment and targeted forensic review. Examine application logs, API gateway logs, TLS/protocol telemetry, authentication logs, and custom cryptographic audit logs for unusual volumes of failed or repeated public-key submissions, DER/PEM parsing events, ECDH handshakes, certificate uploads, or signature-verification attempts involving SECT curves. Review whether any services logged curve names such as sect163k1, sect163r2, sect233k1, sect233r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, or sect571r1 from untrusted clients. Inspect application artifacts for vulnerable package versions and untrusted use of the affected key-loading functions. If suspicious activity aligns with vulnerable ECDH use, treat associated private keys as potentially weakened and consider rotation. No specific threat actors or ransomware campaigns are currently associated with this issue based on the provided data.

What your security team should do

• Inventory all Python applications, containers, build artifacts, and vendor bundles for pyca/cryptography versions earlier than 46.0.5.
• Prioritize remediation for internet-facing services, identity/authentication systems, signing/verification services, certificate-processing workflows, encrypted messaging systems, and APIs that accept public keys from users or partners.
• Upgrade to cryptography 46.0.5 or later and rebuild affected deployment artifacts to remove vulnerable copies from runtime environments.
• Identify and disable SECT curve support where it is not explicitly required.
• Review code paths that import PEM/DER public keys or construct elliptic-curve public numbers from untrusted input.
• Assess whether private-key rotation is warranted for systems that performed ECDH with untrusted SECT public keys while running a vulnerable version.
• Add dependency scanning gates to CI/CD to prevent reintroduction of vulnerable cryptography versions.
• Because the issue is not KEV-listed, has no known exploit maturity, and has low EPSS, handle as a targeted cryptographic weakness rather than an active mass-exploitation emergency, while still remediating promptly due to potential key-confidentiality impact.