Ddos 
Security researchers have disclosed two major vulnerabilities within fast-jwt, a high-performance library used to implement JSON Web Tokens (JWT). The flaws reveal that even minor oversights in code logic can lead to critical authentication bypasses in modern web applications.
The flaw, tracked as CVE-2026-34950, is an “incomplete fix” for a previous high-severity issue discovered in 2023. The original bug allowed for JWT Algorithm Confusion, a classic attack where a server is tricked into treated a public key as a private secret, allowing an attacker to sign their own malicious tokens.
While the developers previously implemented a fix using a Regular Expression (regex) to validate public keys, the new research shows that the fix contained a subtle but fatal error: it relied on a “starting anchor” (the ^ symbol) that is easily defeated.
The vulnerability exists because the library’s security check requires the public key to start exactly at the beginning of a string. If an attacker prefixes the key with any leading whitespace—such as a space, a tab, or a new line—the security regex fails to recognize the key as an RSA public key.
Because the check fails, the library defaults to treating the key as a symmetric HMAC secret. As the report explains:
“The attacker can then sign an HS256 token using the public key as the HMAC secret—the exact same attack as CVE-2023-48223”.
Leading whitespace is a common occurrence in real-world software deployments. Researchers noted several common scenarios where this flaw could be triggered:
- Database Returns: PostgreSQL and MySQL text columns often return strings with leading newlines.
- Configuration Files: YAML multiline strings can accidentally introduce leading spaces.
- Human Error: Simple copy-pasting into configuration files often includes unintended whitespace.
The library’s private key detection function already includes a safeguard (the .trim() method) that removes whitespace, but the public key path does not.
“This inconsistency is the root cause”.
In addition to the algorithm bypass, the library faces a significant risk involving its caching mechanism (CVE-2026-35039). While fast-jwt provides a secure default for caching verified tokens, it allows developers to implement custom cacheKeyBuilder functions.
If a custom builder is implemented poorly, it can lead to cache collisions—where a token for a regular user is incorrectly associated with the cached permissions of an administrator.
- Vulnerable Patterns: Builders that group users by broad categories (e.g., admin-users vs. regular-users) or only use non-unique identifiers like a “Tenant ID” are highly susceptible.
- Safe Alternatives: To prevent collisions, developers should ensure cache keys include unique identifiers such as the Subject (sub) and Issued At (iat) claims.
Both vulnerabilities carry a critical CVSS score of 9.1. Applications are at risk if they use fast-jwt versions 6.1.0 or lower, especially if they verify tokens without explicitly defining an allowed algorithm or use custom caching logic.
As of this writing, a complete patch for the bypass has not been finalized. To protect systems in the interim, security experts recommend that developers:
- Enforce Algorithms: Always explicitly provide the expected algorithm (e.g., RS256) when calling the verify function.
- Sanitize Inputs: Manually trim whitespace from RSA public keys before passing them to the JWT library.
- Audit Configurations: Check environment variables and database entries for hidden newlines or spaces in key strings.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
