This bypass allows an attacker to construct a JWT with arbitrary payloads and an empty signature, which the library will accept as valid. Because signature validation is bypassed, any payload data - such as user roles or administrative identifiers - is accepted by the application logic as trusted. This effectively grants an attacker full authentication or authorization bypass if they can present a JWT to the service.

Attack Chain

1. Attacker identifies an application utilizing the fast-jwt library for authentication.
2. Attacker confirms the application is misconfigured due to a missing or empty secret key environment variable.
3. Attacker crafts a custom JWT header with a valid algorithm (e.g., "HS256") and a malicious payload.
4. Attacker sets the JWT signature portion to empty (trailing dot).
5. Attacker transmits the crafted, unsigned JWT to the target application endpoint.
6. The createVerifier logic detects the explicit algorithms setting and, due to the falsy key, bypasses the signature verification call.
7. The application processes the forged token, trusting the attacker-controlled claims (e.g., admin: true).

Impact

Successful exploitation results in a full authentication and authorization bypass. Attackers can forge arbitrary claims within the JWT, potentially gaining unauthorized access to privileged user accounts or administrative functions. The impact is significant for any service relying on JWTs for session management that has unintentionally initialized with an empty secret key.

Recommendation

Prioritized actions for development and security teams:

• Upgrade fast-jwt to a version that addresses CVE-2026-107720 once available.
• Implement a check to ensure secret keys are not null or empty strings before initializing createVerifier.
• Validate that environment variables used as JWT secrets are properly populated during application startup.
• Patch CVE-2026-107720 by hardening the createVerifier logic to fail closed if the key is falsy regardless of the algorithms configuration.