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.
A flaw was found in jwcrypto. A remote attacker can send a specially crafted JSON Web Encryption (JWE) token containing numerous period delimiters. This malformed token can force the JWE.deserialize() function to allocate excessive memory, leading to a MemoryError. This issue results in a denial of service (DoS) for services that process untrusted JWE values.
A flaw was found in jwcrypto. When verifying a General JSON Serialization JWS using a JWKSet, the library does not correctly apply the current signature kid header when selecting the verification key. The root cause is located in jwcrypto/jws.py, where the code incorrectly evaluates the joseheader as a dictionary when it is actually a list for General JSON JWS objects. Consequently, the library may iterate through every key in the supplied JWKSet and accept a signature made by a different key than the one identified by the kid header.
An attacker who possesses a valid signing key within the application's trusted JWKSet can exploit this flaw to bypass kid-based authorization bindings. This allows the attacker to perform actions such as impersonating other tenants, accessing unauthorized data, or escalating privileges in applications that rely on the kid claim for security decisions.
A flaw was found in jwcrypto. When verifying a General JSON Serialization JWS using a JWKSet, the library does not correctly apply the current signature kid header when selecting the verification key. The root cause is located in jwcrypto/jws.py, where the code incorrectly evaluates the joseheader as a dictionary when it is actually a list for General JSON JWS objects. Consequently, the library may iterate through every key in the supplied JWKSet and accept a signature made by a different key than the one identified by the kid header.
An attacker who possesses a valid signing key within the application's trusted JWKSet can exploit this flaw to bypass kid-based authorization bindings. This allows the attacker to perform actions such as impersonating other tenants, accessing unauthorized data, or escalating privileges in applications that rely on the kid claim for security decisions.
The Rsa15 class in the RSA 1.5 algorithm implementation in jwa.py in jwcrypto before 0.3.2 lacks the Random Filling protection mechanism, which makes it easier for remote attackers to obtain cleartext data via a Million Message Attack (MMA).