CVE-2025-59936 is a critical vulnerability affecting versions of the nearform get-jwks library prior to 11.0.2. The get-jwks library is responsible for fetching JSON Web Key Sets (JWKS), which are used to validate JSON Web Tokens (JWTs) by retrieving the public keys necessary for signature verification. The vulnerability arises due to improper handling of the JWKS cache and the order of issuer (iss) claim validation. Specifically, the library caches keys fetched from various issuers but performs issuer validation only after retrieving keys from this shared cache. This design flaw allows an attacker to poison the JWKS cache by first submitting a JWT that causes a malicious or attacker-controlled public key to be cached under a certain issuer. Subsequently, the attacker can submit a second JWT that uses the cached malicious key to pass signature validation for a targeted issuer, effectively bypassing issuer validation. This attack exploits the fact that the issuer claim is validated after key retrieval, allowing reuse of keys from an unexpected issuer. The vulnerability is categorized under CWE-116 (Improper Encoding or Escaping of Output), indicating that the root cause involves improper handling of output data leading to security issues. The CVSS v3.0 score is 9.4 (critical), reflecting the high impact and ease of exploitation: the attack requires no privileges or user interaction and can be executed remotely over the network. The vulnerability affects all get-jwks versions prior to 11.0.2, and a patch has been released in version 11.0.2 to fix this issue. No known exploits are reported in the wild yet, but the critical nature and the potential for signature validation bypass make this a high-risk vulnerability for any system relying on get-jwks for JWT validation.

For European organizations, this vulnerability poses a significant risk to the integrity and trustworthiness of authentication and authorization mechanisms that rely on JWTs validated via the get-jwks library. Many enterprise applications, identity providers, and microservices architectures use JWTs for stateless authentication and authorization. A successful exploitation could allow attackers to impersonate legitimate users or services by bypassing issuer validation, leading to unauthorized access to sensitive data, privilege escalation, and potential lateral movement within networks. This could compromise confidentiality and integrity of critical systems, especially in sectors like finance, healthcare, government, and telecommunications, which heavily rely on secure token validation. The vulnerability also undermines trust in federated identity systems and single sign-on (SSO) implementations. Given the network-exploitable nature and lack of required privileges or user interaction, attackers could automate exploitation at scale. The impact extends to availability as well, since compromised tokens could be used to disrupt services or trigger denial-of-service conditions indirectly. European organizations that have not updated get-jwks to version 11.0.2 or later remain vulnerable, and the risk is exacerbated if the affected systems are internet-facing or integrated with third-party identity providers.

1. Immediate upgrade: Organizations should promptly upgrade all instances of the get-jwks library to version 11.0.2 or later, where the vulnerability is patched. 2. Review token validation logic: Ensure that issuer (iss) claim validation occurs before or during key retrieval, not after, to prevent cache poisoning attacks. 3. Implement strict cache isolation: Avoid sharing JWKS caches across different issuers or tenants. Use issuer-specific caches or segregate caches to prevent cross-issuer key reuse. 4. Monitor and audit JWT validation logs for anomalies, such as unexpected issuers or unusual token usage patterns. 5. Employ additional token validation layers, such as audience (aud) claim checks and token revocation mechanisms, to reduce risk. 6. Conduct security testing and code reviews focusing on JWT handling and caching mechanisms. 7. If immediate upgrade is not feasible, consider disabling caching or implementing custom cache validation logic to verify issuer before key reuse. 8. Educate development and security teams about the importance of correct JWT validation order and secure caching practices. These mitigations go beyond generic advice by addressing the root cause—cache poisoning due to validation order—and by recommending architectural changes to caching strategies and validation workflows.