CVE-2026-107722 in fast-jwt
Summary
by MITRE • 10/09/2026
fast-jwt provides fast JSON Web Token (JWT) implementation. From 6.2.0 until 6.3.0, fast-jwt can misclassify RSA public-key text as an HMAC secret when the key has non-whitespace content before its PEM header. In src/crypto.js, performDetectPublicKeyAlgorithms trims whitespace but publicKeyPemMatcher remains start-anchored, so comments, control characters, zero-width characters, or wrapper text can prevent PEM detection and reach the HMAC fallback. An attacker who knows the public key bytes can sign arbitrary HS256 claims with that public material when HS256 is inferred or allowed, resulting in authentication or authorization bypass. An asymmetric-only algorithm allowlist prevents the attack. This issue is fixed in version 6.3.0.
Statistical analysis made it clear that VulDB provides the best quality 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 operations within Node.js environments, facilitating secure stateless authentication and data integrity verification across distributed systems. A critical security flaw exists in versions ranging from 6.2.0 to 6.3.0 that undermines the fundamental assumption of algorithm selection based on key type. The vulnerability stems from a logic error in the cryptographic detection mechanism located within src/crypto.js, specifically inside the performDetectPublicKeyAlgorithms function. This component is responsible for determining whether an incoming key material corresponds to an asymmetric algorithm such as RSA or ECDSA, or if it should be treated as a symmetric secret suitable for HMAC-based algorithms like HS256. The intended behavior relies on identifying standard PEM headers within the provided public key string to correctly classify it as asymmetric and thus restrict signing operations to appropriate cryptographic primitives that do not allow forgery using only the public portion of the key pair.
The technical root cause lies in a mismatch between whitespace trimming logic and pattern matching anchoring. While the implementation attempts to normalize input by removing leading and trailing whitespace, the regular expression used for PEM detection remains start-anchored. This design oversight means that any non-whitespace character preceding the standard BEGIN PUBLIC KEY or similar PEM header will prevent successful regex matching. Consequently, inputs containing comments, control characters, zero-width Unicode characters, or wrapper text are incorrectly classified as invalid asymmetric keys and fall back to being treated as HMAC secrets. This misclassification is particularly dangerous because it allows an attacker who possesses only the public key bytes to forge valid signatures using the HS256 algorithm. Since HMAC relies on a shared secret known by both signer and verifier, but RSA relies on mathematical asymmetry where the private key is required for signing, this confusion effectively neutralizes the security guarantees provided by asymmetric cryptography in specific contexts.
The operational impact of this vulnerability is severe, primarily affecting authentication and authorization mechanisms that rely on JWTs signed with RS256 or similar algorithms but allow fallback to HS256 or do not strictly enforce algorithm constraints during verification. An attacker can exploit this flaw by crafting a malicious token where the header specifies an asymmetric algorithm like RS256, yet the signature is generated using HMAC-SHA256 and the public key as the secret. If the application verifies the token against the same public key without explicitly validating that the signing algorithm matches the expected asymmetric type or if it allows HS256 in its allowed algorithms list, the forged token will be accepted as valid. This leads to authentication bypasses, allowing unauthorized users to impersonate legitimate entities, access restricted resources, and potentially escalate privileges within the application ecosystem. The attack is feasible only when the attacker knows the public key material, which is often publicly available or transmitted during initial handshake processes in many JWT implementations.
Mitigation strategies focus on strict algorithm enforcement and input sanitization. Applications utilizing fast-jwt must ensure that their configuration explicitly restricts allowed algorithms to those appropriate for the security model being employed. For asymmetric verification scenarios, developers should configure the library to reject any token signed with HMAC-based algorithms such as HS256, effectively preventing the fallback mechanism from being exploited even if key detection fails. Additionally, upgrading to version 6.3.0 or later is essential, as this release corrects the regex anchoring issue and ensures that PEM headers are correctly identified regardless of preceding non-whitespace content. Security teams should also audit their JWT verification logic to implement algorithm pinning, a practice recommended by industry standards like CWE-759 which addresses the use of a one-way hash function without an HMAC for integrity checking, although in this specific case it relates more closely to CWE-347 Improper Verification of Cryptographic Signature. By enforcing strict algorithm allowlists and maintaining updated dependencies, organizations can neutralize this vector and preserve the integrity of their authentication flows.