CVE-2026-92091: Jwcrypto: jwcrypto: denial of service via o(n^2) duplicate check on unbounded jwk key_ops array
A flaw was found in jwcrypto. JWK.importkey() validates the keyops JWK member for duplicate values using a nested loop that rescans the entire list for every element, resulting in O(n^2) time complexity relative to the length of keyops. The keyops array has no size limit and is fully attacker-controlled when an application passes attacker-supplied JWK material into this API. A remote, unauthenticated attacker can trigger this by supplying a JWK such as {\"kty\":\"oct\",\"k\":\"AAAA\",\"keyops\":[...]} containing a large keyops array (e.g. 50,000 distinct strings, ~526 KB) to any application code path that imports an attacker-supplied JWK or JWK Set, including ECDH-ES key agreement (the epk header is processed before other token validation), OIDC dynamic client registration, DPoP proof validation, ACME account key registration, or relying parties importing a federated JWKS. Per the finder's measurements (not independently reproduced by Red Hat), a single such request consumes approximately 108 seconds of CPU time on one core, and a small number of concurrent requests can exhaust a server's processing capacity, resulting in denial of service. This does not affect deployments that only import JWKs from trusted, fixed issuer endpoints.
Other sources
A flaw was found in jwcrypto. The JWK.importkey() function validates the keyops JWK member for duplicate values using an algorithm with O(n^2) time complexity, and the length of keyops is not bounded. A remote, unauthenticated attacker can supply a JWK with a large keyops 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Do not pass attacker-controlled JWK/JWK Set material to jwcrypto’s public key import paths (e.g., JWK.import_key()), particularly those reachable via ECDH-ES key agreement, OIDC dynamic client registration, DPoP proof validation, ACME account key registration, or federated relying-party JWKS imports. Ensure only trusted, fixed issuer endpoints’ JWKS are imported.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments are exposed when application code imports attacker-supplied JWK material or JWK Sets through JWK.import_key(). Examples include ECDH-ES key agreement, OIDC dynamic client registration, DPoP proof validation, ACME account key registration, and relying parties importing a federated JWKS.
What does an attacker need to exploit it?
An attacker needs network access to an application path that passes attacker-controlled JWK data to JWK.import_key(). No authentication or user interaction is required.
What is the expected operational impact of a malicious request?
A JWK with a very large key_ops array triggers quadratic duplicate checking. The finder reported that a request containing 50,000 distinct key_ops strings consumed about 108 seconds of CPU time on one core, and a small number of concurrent requests could exhaust server processing capacity.