CVE-2026-107720 in fast-jwt
Summary
by MITRE • 10/09/2026
fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.1, fast-jwt createVerifier accepts an unsigned JWT when key is an empty string or null and algorithms is a non-empty allowlist. Falsy synchronous keys bypass prepareKeyOrSecret, allowedAlgorithms remains active, hasKey is false, and the empty signature avoids the verifySignature gate. An attacker can therefore submit a token containing arbitrary claims without possessing a signing key, resulting in authentication or authorization bypass. Claim validators still run, and non-empty keys, an empty key without algorithms, and the async key resolver path do not have this behavior. This issue is fixed in version 6.3.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The fast-jwt library serves as a high-performance implementation for JSON Web Token processing within Node.js environments, widely adopted by developers requiring efficient cryptographic operations for authentication and authorization workflows. A critical security flaw was identified in versions prior to 6.3.1 regarding the token verification logic, specifically affecting how unsigned tokens are handled under specific configuration conditions. This vulnerability stems from an improper validation of key material during the initialization phase of the verifier object, allowing attackers to bypass signature verification entirely when certain falsy values are provided for cryptographic keys while maintaining a non-empty list of allowed algorithms.
The technical root cause lies in the internal handling of the prepareKeyOrSecret function and its interaction with the hasKey flag within the verifySignature gate. When an attacker supplies an empty string or null as the key parameter, combined with a non-empty allowlist for algorithms, the library fails to properly reject unsigned tokens. In this specific configuration, the falsy synchronous keys bypass the standard preparation logic, leaving the allowedAlgorithms array active while setting hasKey to false. Consequently, the verifySignature gate is effectively disabled because it relies on the presence of a valid key reference to enforce signature checks. This architectural oversight means that an empty or missing signature does not trigger a verification failure, allowing any token with arbitrary claims and no cryptographic proof of origin to be accepted as valid.
The operational impact of this vulnerability is severe, primarily manifesting as authentication and authorization bypasses in applications relying on fast-jwt for session management or API access control. An attacker can craft JWTs containing elevated privileges, administrative roles, or other malicious claims without possessing the legitimate signing key. Since claim validators continue to execute after verification, any logic dependent solely on token content rather than cryptographic integrity may also be compromised if it assumes that a verified token is inherently trustworthy. This flaw undermines the fundamental security model of JSON Web Tokens, which relies on the assumption that only entities with the secret or private key can generate valid tokens.
This vulnerability aligns with CWE-287, Improper Authentication, as it allows an actor to assume another user's identity by bypassing credential verification mechanisms. Furthermore, from a tactical perspective related to MITRE ATT&CK, this flaw facilitates T1078 Valid Accounts and potentially T1556 Modifying Authenticators if the application logic permits privilege escalation through manipulated claims. The issue is isolated to specific configurations; non-empty keys correctly enforce signature checks, an empty key without specified algorithms does not trigger the bypass due to algorithm mismatch failures, and asynchronous key resolver paths maintain proper validation protocols.
To mitigate this risk, organizations must immediately upgrade fast-jwt to version 6.3.1 or later, where the verification logic has been hardened to reject unsigned tokens regardless of the key value when an allowlist is present. Developers should also review their JWT implementation strategies to ensure that critical security decisions are not made based solely on token content without rigorous cryptographic validation. Implementing defense-in-depth measures such as strict input validation and monitoring for anomalous authentication patterns can provide additional layers of protection against exploitation attempts targeting similar weaknesses in other libraries or custom implementations.