Summary
fast-jwt may accept an unsigned JWT when a synchronous verifier is configured with an empty or null key and a non-empty algorithm allowlist. An attacker who can submit tokens to the affected verifier may forge arbitrary claims without possessing a signing key, potentially bypassing authentication or authorization checks.
fast-jwt may accept an unsigned JWT when a synchronous verifier is configured with an empty or null key and a non-empty algorithm allowlist. An attacker who can submit tokens to the affected verifier may forge arbitrary claims without possessing a signing key, potentially bypassing authentication or authorization checks.
Affected context
The issue occurs in fast-jwt verifier configurations that use a falsy synchronous key, such as an empty string or null, together with a non-empty algorithms allowlist. Under these conditions, claim validation may still execute, but signature verification can be skipped for a token with an empty signature. Configurations using non-empty keys, no algorithm allowlist, or the asynchronous key resolver path are not described as exhibiting this behavior.
The issue occurs in fast-jwt verifier configurations that use a falsy synchronous key, such as an empty string or null, together with a non-empty algorithms allowlist. Under these conditions, claim validation may still execute, but signature verification can be skipped for a token with an empty signature. Configurations using non-empty keys, no algorithm allowlist, or the asynchronous key resolver path are not described as exhibiting this behavior.
Exploit preconditions
- Attack surface: An application endpoint or service that accepts JWTs and validates them with fast-jwt
- Required access: Ability to submit a crafted JWT to the affected verification path; possession of a legitimate signing key is not required
- Trigger point: Synchronous token verification using an empty or null key and a non-empty algorithm allowlist
- Why exploitation is possible: Falsy keys can bypass key preparation, while an empty signature avoids the signature-verification gate even though allowed algorithms remain configured
- Attack surface: An application endpoint or service that accepts JWTs and validates them with fast-jwt
- Required access: Ability to submit a crafted JWT to the affected verification path; possession of a legitimate signing key is not required
- Trigger point: Synchronous token verification using an empty or null key and a non-empty algorithm allowlist
- Why exploitation is possible: Falsy keys can bypass key preparation, while an empty signature avoids the signature-verification gate even though allowed algorithms remain configured
Why this happens
The underlying bug is an inconsistent relationship between key presence, algorithm configuration, and signature verification. A falsy synchronous key is treated as a special case, but the verifier continues to apply the algorithm allowlist and does not require a valid cryptographic signature before accepting claims. This maps primarily to CWE-347: Improper Verification of Cryptographic Signature, with CWE-20: Improper Input Validation also relevant because malformed or incomplete token inputs are not rejected consistently.
The underlying bug is an inconsistent relationship between key presence, algorithm configuration, and signature verification. A falsy synchronous key is treated as a special case, but the verifier continues to apply the algorithm allowlist and does not require a valid cryptographic signature before accepting claims. This maps primarily to CWE-347: Improper Verification of Cryptographic Signature, with CWE-20: Improper Input Validation also relevant because malformed or incomplete token inputs are not rejected consistently.
Potential impact
- An attacker may bypass authentication checks
- An attacker could obtain access associated with forged identity claims
- Authorization decisions may be influenced by attacker-controlled roles or permissions
- Protected application data or administrative functionality may be exposed
- Audit records may contain misleading token identities
- An attacker may bypass authentication checks
- An attacker could obtain access associated with forged identity claims
- Authorization decisions may be influenced by attacker-controlled roles or permissions
- Protected application data or administrative functionality may be exposed
- Audit records may contain misleading token identities
General mitigation guidance
Mitigation generally focuses on making signature verification mandatory and reducing ambiguity in verifier configuration.
Defensive patterns include:
- Rejecting empty, null, or otherwise invalid verification keys during configuration and startup
- Requiring a cryptographically valid signature before processing authorization-relevant claims
- Treating algorithm allowlists as restrictions rather than substitutes for key and signature presence
- Using explicit configuration schemas that distinguish valid key material from missing values
- Applying least privilege to identities represented by JWT claims and requiring independent authorization checks for sensitive operations
- Testing malformed, unsigned, and algorithm-mismatch tokens as part of security regression suites
Mitigation generally focuses on making signature verification mandatory and reducing ambiguity in verifier configuration.
Defensive patterns include:
- Rejecting empty, null, or otherwise invalid verification keys during configuration and startup
- Requiring a cryptographically valid signature before processing authorization-relevant claims
- Treating algorithm allowlists as restrictions rather than substitutes for key and signature presence
- Using explicit configuration schemas that distinguish valid key material from missing values
- Applying least privilege to identities represented by JWT claims and requiring independent authorization checks for sensitive operations
- Testing malformed, unsigned, and algorithm-mismatch tokens as part of security regression suites
How teams detect issues like this
Detection can combine configuration review, code analysis, and runtime monitoring:
- Search for verifier construction using empty, nullable, or environment-derived keys
- Flag code paths where algorithm allowlists are configured without an enforced key-presence check
- Review handling of tokens with empty signatures and confirm that they are rejected
- Add automated tests for unsigned tokens, missing keys, invalid signatures, and forged claims
- Monitor authentication failures, unusual claim combinations, and successful access associated with unexpected token subjects or roles
- Use static analysis or automated dependency review tools to identify unsafe JWT verification patterns
Detection can combine configuration review, code analysis, and runtime monitoring:
- Search for verifier construction using empty, nullable, or environment-derived keys
- Flag code paths where algorithm allowlists are configured without an enforced key-presence check
- Review handling of tokens with empty signatures and confirm that they are rejected
- Add automated tests for unsigned tokens, missing keys, invalid signatures, and forged claims
- Monitor authentication failures, unusual claim combinations, and successful access associated with unexpected token subjects or roles
- Use static analysis or automated dependency review tools to identify unsafe JWT verification patterns
