CVE-2026-92091 in jwcrypto
Summary
by MITRE • 09/16/2026
A flaw was found in jwcrypto. The JWK.import_key() function validates the key_ops JWK member for duplicate values using an algorithm with O(n^2) time complexity, and the length of key_ops is not bounded. A remote, unauthenticated attacker can supply a JWK with a large key_ops array to an application that passes attacker-controlled key material to a public key-import API (reachable via ECDH-ES key agreement, OIDC dynamic client registration, DPoP, or ACME account key registration, among others) to consume excessive CPU time, resulting in a denial of service.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
The vulnerability identified within the jwcrypto library represents a significant availability risk stemming from inefficient algorithmic complexity and insufficient input validation. Specifically, the JWK.import_key() function exhibits quadratic time complexity, O(n^2), when validating the key_ops member for duplicate values in a JSON Web Key object. This inefficiency is compounded by the absence of any upper bound on the length of the key_ops array. In cryptographic libraries, such as jwcrypto which handles sensitive operations like key importation and validation, performance characteristics are critical not only for efficiency but also for resilience against resource exhaustion attacks. The lack of a hard limit on the size of this specific field allows an attacker to construct maliciously crafted inputs that trigger excessive computational overhead during the validation phase.
From a technical perspective, the flaw lies in how the library processes the key_ops array. When importing a JWK, the system iterates through the provided operations list to ensure there are no duplicates, likely using nested loops or repeated searches rather than optimized data structures like hash sets that would provide constant time lookups on average. As the size of the input array increases, the processing time grows exponentially relative to the square of the number of elements. This behavior creates a classic algorithmic complexity vulnerability where legitimate-looking but oversized inputs can be used to stall system resources. The validation logic does not enforce reasonable constraints on the cardinality of the key_ops list, leaving it open to abuse by adversaries who understand this internal implementation detail.
The operational impact of this flaw is primarily centered around denial of service conditions for applications that rely on jwcrypto and expose public-facing APIs involving key material importation. An unauthenticated remote attacker can exploit this weakness by submitting a JWK containing an excessively large key_ops array to any endpoint that accepts such input. Common attack vectors include endpoints supporting ECDH-ES key agreement, OpenID Connect dynamic client registration, DPoP proof token validation, or ACME account key registration processes. In these scenarios, the application is expected to parse and validate incoming cryptographic keys as part of standard authentication or authorization flows. By flooding these entry points with crafted payloads, an attacker can consume disproportionate amounts of CPU cycles on the server side, potentially leading to service degradation for legitimate users or complete system unavailability if resource limits are not externally enforced at a network level.
This vulnerability aligns closely with CWE-400, which describes Uncontrolled Resource Consumption, specifically highlighting issues related to algorithmic complexity that allow attackers to exhaust computational resources. Furthermore, in the context of the MITRE ATT&CK framework, this exploit technique maps to T1496, Resource Hijacking, where an adversary uses compromised or vulnerable systems for their own purposes, such as causing a denial of service by consuming excessive CPU time. It also touches upon CWE-770, Allocation of Resources Without Limits or Throttling, due to the failure to bound the size of the input array during processing. The severity is heightened because it requires no authentication and can be triggered remotely over standard network protocols used for identity management and cryptographic key exchange.
Mitigation strategies should focus on both immediate code-level fixes and broader architectural defenses. Developers utilizing jwcrypto must upgrade to a patched version that implements efficient duplicate detection, such as using hash-based collections to achieve O(n) complexity, and enforces strict maximum length limits on the key_ops array during validation. For organizations unable to immediately patch their dependencies, implementing rate limiting at the API gateway level can help mitigate the impact by restricting the number of import requests from a single source within a given timeframe. Additionally, deploying Web Application Firewalls with rules designed to detect unusually large JSON payloads or specific patterns indicative of this exploit can provide an additional layer of defense. It is also advisable to review all public-facing endpoints that accept JWKs and ensure they are protected by authentication requirements where possible, thereby reducing the attack surface available to unauthenticated actors. Regular security audits focusing on input validation boundaries in cryptographic libraries will help prevent similar algorithmic complexity vulnerabilities from being introduced or overlooked in future updates.