CVE-2026-107724 in fast-jwt
Summary
by MITRE • 10/09/2026
fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.2.4, fast-jwt can classify raw serialized public JWK or JWKS JSON as an HMAC secret because src/crypto.js performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use those bytes as an HMAC key and create a token containing arbitrary claims that createVerifier accepts. Serialization ordering or whitespace differences can prevent exploitation, and applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected. This issue is fixed in version 6.3.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/09/2026
The vulnerability identified in fast-jwt versions prior to 6.3.0 represents a critical flaw in the library's cryptographic key detection logic, specifically within the src/crypto.js module. The core technical deficiency lies in how the performDetectPublicKeyAlgorithms function processes input keys. This function is designed to determine whether an incoming key should be treated as asymmetric or symmetric material for JSON Web Token operations. However, it fails to adequately distinguish between raw serialized public JWK (JSON Web Key) or JWKS (JSON Web Key Set) structures and actual HMAC secret strings. The logic incorrectly classifies non-PEM formatted string inputs as potential symmetric key material if they do not match specific PEM patterns, thereby allowing the library to proceed with HMAC-based verification algorithms even when asymmetric keys are intended for use.
This misclassification creates a severe security risk known as JWT Algorithm Confusion or Key Injection. When an application allows HS256 (HMAC-SHA256) either explicitly in its algorithm allowlist or implicitly through default configuration, the vulnerability becomes exploitable. An attacker who has access to the public key material of the target service can serialize this public key and present it as if it were a shared HMAC secret during token verification. Because fast-jwt accepts these raw serialized bytes as valid symmetric keys under certain conditions, the library will successfully verify tokens signed with that same byte sequence using an HMAC algorithm. This effectively bypasses the intended asymmetric cryptographic boundary where only holders of the private key should be able to generate or modify claims securely.
The operational impact of this vulnerability is significant for any application relying on fast-jwt for authentication and authorization decisions. By exploiting this flaw, a malicious actor can forge arbitrary JWTs containing privileged claims such as administrative roles, elevated user permissions, or access tokens for other users. Since the forged token appears valid to the verifier due to the algorithm confusion, the victim application will trust these unauthorized assertions. This leads directly to full account takeover and privilege escalation within the affected system. The attack vector is particularly dangerous because it does not require breaking any cryptographic primitives; instead, it exploits a logical error in key type detection that allows public information to be used as private secret material for HMAC operations.
Several factors influence the exploitability of this vulnerability, which must be considered during risk assessment and remediation planning. The attack requires precise knowledge of the exact serialized bytes of the target's public key. Furthermore, success depends on specific serialization ordering or whitespace configurations that align with how fast-jwt parses the input string before detection. If the application enforces a strict allowlist of asymmetric-only algorithms such as RS256 or ES256 without permitting any HMAC variants like HS256, the vulnerability is mitigated because the library will reject attempts to use symmetric signing methods regardless of key type confusion. Similarly, applications that exclusively utilize PEM-formatted keys are generally unaffected since the detection logic specifically targets non-PEM strings for potential misclassification as symmetric material.
To remediate this issue, organizations must immediately upgrade fast-jwt to version 6.3.0 or later, where the performDetectPublicKeyAlgorithms function has been corrected to properly distinguish between asymmetric public keys and symmetric secrets. In addition to upgrading dependencies, developers should review their JWT configuration strategies to enforce strict algorithm allowlists that explicitly exclude HMAC variants unless absolutely necessary for specific use cases involving shared secrets rather than public key infrastructure. Implementing defense-in-depth measures such as validating the alg header against a whitelist of expected algorithms before verification is crucial. This practice ensures that even if library-level protections fail, the application logic will reject tokens signed with unexpected or unauthorized cryptographic methods.
From a standards perspective, this vulnerability aligns with CWE-295 Improper Certificate Validation and CWE-780 Use of RSA-OAEP without AEAD for Integrity Protection in broader contexts of algorithm confusion attacks. It also maps to MITRE ATT&CK technique T1649 Misuse of Cloud Infrastructure: Configuration Flaws, specifically relating to the misconfiguration or misuse of cryptographic libraries leading to authentication bypass. Security teams should treat this as a high-severity issue requiring immediate patching due to its direct impact on identity and access management systems. Regular auditing of third-party library versions and enforcing strict input validation for cryptographic parameters are essential practices to prevent similar algorithm confusion vulnerabilities in future implementations.