REDHAT-BUG-2533849: Medium severity jwcrypto vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Which application flows are most likely to expose this issue?
Exposure exists where application code imports attacker-supplied JWKs or JWK Sets. Examples include ECDH-ES key agreement, OIDC dynamic client registration, DPoP proof validation, ACME account key registration, and relying parties that import a federated JWKS.
Does exploitation require authentication or a valid token?
No. A remote unauthenticated attacker can submit a JWK with a very large key_ops array to a reachable import path. For ECDH-ES, the epk header is processed before other token validation.
What operational impact should be expected from a malicious request?
The reported test case used 50,000 distinct key_ops strings, approximately 526 KB of input, and reportedly consumed about 108 seconds of CPU time on one core per request. The finder reported that a small number of concurrent requests can exhaust processing capacity and cause denial of service; Red Hat did not independently reproduce those measurements.