CVE-2026-84185 in jwcrypto
Summary
by MITRE • 09/03/2026
A flaw was found in the jwcrypto library, which is used for implementing Javascript Object Signing and Encryption (JOSE) standards. The issue occurs when the library verifies a General JSON Serialization JWS using a set of keys. Due to a coding error, the library fails to correctly identify the specific key ID (kid) and may instead accept a signature made by any valid key in the set. This can allow an attacker with a valid key to bypass authorization checks in applications that rely on the key ID to identify specific tenants or users.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified within the jwcrypto library represents a critical failure in the verification logic for JSON Web Signature (JWS) objects, specifically affecting those utilizing General JSON Serialization as defined by RFC 7515 and related JOSE standards. The core technical flaw lies in the key selection mechanism during signature validation. When an application provides a set of potential public keys to verify a JWS token, the library is designed to match the Key ID (kid) header parameter within the signed payload against one of the provided keys to ensure cryptographic integrity and identity binding. However, due to a specific coding error in this matching process, the verification routine fails to strictly enforce that the key used for signing corresponds exactly to the kid specified in the token headers. Instead, the library may accept any valid signature generated by any key present in the supplied set, regardless of whether that key matches the intended identifier. This behavior fundamentally breaks the assumption that a specific key ID uniquely identifies the signer within the context of the verification process.
From an operational perspective, this flaw has severe implications for security architectures relying on JWS tokens for authentication and authorization, particularly in multi-tenant environments or systems using decentralized identity models where keys are mapped to specific users, services, or tenants. If an attacker possesses a valid signing key but not necessarily the one associated with the target user's kid header, they can craft a malicious token that appears legitimate because it is signed by their own valid key and accepted by the vulnerable library despite the mismatched identifier. This allows for authorization bypasses where an actor impersonates another entity or accesses resources intended only for specific tenants. The vulnerability effectively neutralizes the binding between identity claims and cryptographic proof, turning what should be a strict verification step into a permissive one that trusts any signature from the allowed key pool.
This issue aligns with CWE-287, which describes Improper Authentication, specifically regarding the failure to correctly verify credentials or identifiers during access control decisions. Furthermore, it relates to CWE-345, Insufficient Verification of Data Authenticity, as the system fails to ensure that the data originated from the claimed source based on the provided key identifier. In terms of MITRE ATT&CK framework mapping, this vulnerability facilitates techniques associated with T1078, Valid Accounts, by allowing attackers to use legitimate credentials in an unauthorized manner through token manipulation. It also touches upon T1499, Endpoint Denial of Service, if exploited to cause system instability, though the primary risk is lateral movement and privilege escalation via identity spoofing.
Mitigation strategies must prioritize immediate updates to the jwcrypto library version that addresses this key selection logic error. Developers should ensure they are using a patched release where the verification process strictly enforces the correspondence between the kid header parameter and the specific public key used for signature validation. In addition to updating dependencies, security teams should implement defense-in-depth measures such as validating token contents against application-specific policies before processing them further. Monitoring logs for unusual patterns of token usage or failed authentication attempts can help detect exploitation attempts in real-time. It is also advisable to review any custom implementations that wrap jwcrypto to ensure no additional logic inadvertently bypasses the library's internal checks, and to consider using stricter key management practices where possible, such as limiting the number of keys available for verification at any given time to reduce the attack surface.