REDHAT-BUG-2526729: Medium severity jwcrypto vulnerability
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.
Affected Software
Event History
Frequently Asked Questions
Which applications are realistically exposed to this flaw?
Applications using jwcrypto to verify General JSON Serialization JWS objects against a JWKSet are exposed if they rely on the signature kid header to bind a token or signature to a particular tenant, identity, authorization scope, or key-specific privilege.
What does an attacker need to exploit it?
The attacker needs possession of a valid signing key that is already present in the application's trusted JWKSet. They can then create a signature with that key while presenting a kid value associated with a different key, potentially bypassing kid-based authorization bindings.
Are deployments that do not make security decisions based on kid affected in the same way?
The flawed key-selection behavior may still occur when verifying General JSON JWS with a JWKSet, but the described authorization impact depends on the application using kid as a security boundary. The reported risks, including tenant impersonation, unauthorized data access, and privilege escalation, arise when kid determines authorization-relevant identity or scope.
How can teams determine whether their application is affected?
Review whether the application uses jwcrypto's General JSON Serialization JWS verification with a JWKSet and whether it trusts the kid header for tenant selection, identity mapping, access control, or other authorization decisions. Also determine whether multiple trusted signing keys exist in that JWKSet, since the issue can cause verification to succeed with a key other than the one identified by kid.