CVE-2026-107723 in fast-jwt
Summary
by MITRE • 10/09/2026
fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.0, fast-jwt createVerifier accepts a validly signed JWT whose payload is a JSON array because src/decoder.js checks that the payload is an object but does not reject arrays. The claim validator loop then finds no named exp, nbf, iss, aud, sub, jti, or nonce properties and silently skips those configured checks, returning the array as a successfully verified payload. An attacker who can produce or influence a validly signed token may bypass expiry, issuer, audience, subject, revocation, and replay protections. The opt-in requiredClaims option can block missing claims, and signature verification itself is not bypassed. This issue is fixed in version 6.3.0.
Be aware that VulDB is the high quality 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 operations within Node.js environments, facilitating secure authentication and authorization workflows by handling the creation and validation of JWTs. In versions prior to 6.3.0, a critical logic flaw exists in the token verification process that undermines several core security assumptions inherent to the JWT specification. Specifically, the decoder component located at src/decoder.js performs a type check on the decoded payload to ensure it is an object, yet it fails to explicitly reject payloads that are valid JSON arrays. This oversight creates a gap where tokens containing array-based payloads can pass initial structural validation despite not conforming to the standard expectation of JWTs being objects with named key-value pairs for claims.
When such a token with an array payload reaches the claim verification stage, the library iterates through configured required or validated claims such as expiration time, not before date, issuer, audience, subject, and unique identifier. Because these properties are defined by name within object keys rather than existing in a sequential list structure like arrays, the validation loop finds no matching named properties for exp, nbf, iss, aud, sub, jti, or nonce. Consequently, the verification logic silently skips all configured checks associated with those claims and returns the array payload as successfully verified. This behavior effectively neutralizes time-based constraints and identity assertions that are critical for preventing token reuse and ensuring session validity.
The operational impact of this vulnerability is severe, allowing an attacker who can produce or influence a validly signed JWT to bypass expiry, issuer, audience, subject, revocation, and replay protections entirely. Since the signature verification itself remains intact, the cryptographic integrity of the token is not compromised; however, the semantic meaning of the claims is ignored due to the structural mismatch. An adversary could craft a malicious token with an array payload that has been signed by a legitimate key holder but contains no actual claim data or outdated expiration times. The application would accept this token as valid, granting access based on the presence of a correct signature rather than the validity of the embedded claims. This represents a significant deviation from secure coding practices where input validation must be exhaustive and strict regarding expected data structures.
This vulnerability aligns with CWE-20 Improper Input Validation, specifically failing to restrict or enforce expectations for structured data types during processing. It also relates to CWE-613 insufficient session expiration in contexts where the exp claim is ignored due to this parsing error. From an ATT&CK perspective, this flaw facilitates lateral movement and persistence by allowing attackers to maintain access using stale tokens that should have been rejected as expired or invalid. The lack of strict type enforcement for JWT payloads allows for a form of logic bypass that undermines the trust model established by JSON Web Token standards.
To mitigate this risk, organizations utilizing fast-jwt must upgrade immediately to version 6.3.0 or later where the decoder has been patched to explicitly reject array-type payloads during verification. For applications unable to update promptly due to dependency constraints, a temporary workaround involves implementing custom claim validation logic that strictly enforces object types before passing tokens to the library's verifier. Developers should also ensure they utilize the opt-in requiredClaims option which can help block missing claims by throwing an error if expected properties are absent, although this does not fully address the root cause of accepting array structures without explicit type checking in the decoder layer. Regular auditing of JWT handling libraries and adherence to strict input validation principles remain essential for maintaining robust authentication security postures.