A flaw was found in jwcrypto. JWK.import_key() validates the key_ops 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 key_ops. The key_ops 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\",\"key_ops\":[...]} containing a large key_ops 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.