The fast-jwt fix for algorithm confusion missed the prefix
The fast-jwt fix for algorithm confusion missed the prefix
JWT libraries have been fighting the same class of bug for a decade: a verifier that is handed a public key and a token whose header says HS256, and which decides the key must therefore be an HMAC secret. CVE-2026-107722 is a later round of that fight, and what makes it worth reading is not the bypass itself but where the previous fix stopped.
What is affected
The CVE record covers the npm package fast-jwt, from version 6.2.0 until 6.3.0. The vulnerability is explicitly described as an incomplete patch of an earlier issue, CVE-2026-34950. Version 6.3.0 contains the current fix.
The record rates it 9.8 under CVSS 3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The attack is network-reachable, needs no privileges and no user interaction, and affects confidentiality, integrity and availability. That score reflects the consequence, not the effort: forging a token requires only the public key.
The mechanism, as the advisory describes it
In src/crypto.js, a function called performDetectPublicKeyAlgorithms decides whether a key string is an RSA public key or something else. It trims whitespace before matching. The matcher that recognises a PEM header, publicKeyPemMatcher, remains anchored to the start of the string.
Those two behaviours disagree about where the key begins. Trimming removes whitespace, but the matcher is evaluating the already-trimmed value while still requiring its first character to be part of the PEM header. Any non-whitespace content in front of the header, such as a comment line, a control character, a zero-width character, or text that wraps the key, prevents PEM detection. The value then falls through to the HMAC branch.
Once the code treats a public key as an HMAC secret, the classic attack applies. The attacker, who knows the public key by definition, computes an HS256 signature over arbitrary claims using those public bytes as the shared secret. If the verification path infers HS256 or permits it, the forged token validates.
Incomplete patches and the shapes they leave behind
Security fixes for parsing bugs tend to remove the input that triggered the report. A prefix that was plain whitespace is a natural thing to normalise, and normalising it makes the original proof of concept fail. The structural problem, which is that key classification and key consumption consult different notions of the same string, remains.
This is a recurring pattern in parsers that sit between formats. Detection logic and execution logic each carry their own assumptions about the boundaries of a value. A fix that touches only one of them changes the observable behaviour without changing the decision path.
The advisory's own mitigation names the durable answer: use an asymmetric-only algorithm allowlist. If the verifier is configured to accept only RS256, ES256 or similar, the HMAC fallback never runs, and how a key string was classified stops mattering.
Where this bites hardest
A JWT verification bypass is not a library-internal curiosity. It is an authentication bypass wherever the token carries identity, which in 2026 means most API surfaces and a growing number of internal service meshes.
The exposure that matters is the subset where token verification is the only gate. A gateway that validates a token and forwards a user identifier downstream, an internal job runner that authorises by claim, a webhook receiver that trusts a signed body: each of these converts one misclassified key into a privilege decision made by an attacker.
HS256 acceptance is usually inherited rather than chosen. It arrives with a default configuration, a copied code sample, or a multi-tenant service that lets each tenant supply its own verification settings. Nobody writes a design document titled "we will allow symmetric and asymmetric verification against the same key input". It accumulates.
That inheritance is also why the fix in 6.3.0 will not be universally applied. Applications pin versions in lockfiles, and library updates in large dependency trees move at the speed of the slowest maintainer. The vulnerable range is narrow, from 6.2.0 to 6.3.0, which limits the population, but narrow ranges are exactly the ones that get skipped when teams sample their inventory quarterly.
What to check, in order
- Inventory. Search for fast-jwt in lockfiles and container images, then confirm which resolved versions fall in the 6.2.x line. Package manager audit output is the fastest source; a container image scan catches the copies that arrive as transitive dependencies.
- Read the verifier configuration, not just the version. Look for any place where a key is supplied as a string that might carry comments or wrapper text: environment variables, mounted secrets, configuration files assembled by a template, key material pasted into a UI. Those are the inputs that trigger the misclassification.
- Restrict the accepted algorithms. If the verifier can be configured with an asymmetric-only allowlist, do that before upgrading. It is the mitigation the advisory itself recommends and it survives a delayed rollout.
- Check what the tokens authorise. A verification bypass matters most where the token is the sole authorisation decision. Services that combine a token check with a second, independent check, such as a scoped lookup against a session store, keep some protection when the first gate fails.
Detection notes
Forged tokens carry a distinguishing property: they are signed with a key the legitimate issuer never uses. Where the application logs token metadata at validation time, comparing the algorithm in the header against the expected algorithm for that endpoint will surface attempts early, even when the signature check passes.
Validation failures of a new kind are also a signal. If a verifier starts rejecting tokens it previously accepted, or accepts tokens whose headers differ from the tenant's configured algorithm, the change deserves investigation rather than a note in a log file.
Key rotation is not a fix here. The bypass does not require the attacker to know a secret, so rotating the public key pair changes nothing about exploitability, and rotating the HMAC secret changes nothing when the HMAC secret is the public key.
The broader lesson
A parser fix must be evaluated against the decision it feeds. When detection logic and consumption logic disagree about the same string, closing one path leaves the other open, and the next researcher will find the prefix that the previous fix forgot. Allowlisting an algorithm removes the decision entirely, which is why it holds.
References
- CVE.org record for CVE-2026-107722: cve.org
- fast-jwt security advisory GHSA-ww5h-9m49-7xx4: github.com/nearform/fast-jwt/security/advisories/…
- fast-jwt release v6.3.0: github.com/nearform/fast-jwt/releases/tag/v6.3.0
CVE-2026-107723: CVE-2026-107723: Silent Claim-Validator Bypass in NearForm fast-jwt via Array Payload Type Confusion
CVE-2026-107723: Silent Claim-Validator Bypass in NearForm fast-jwt via Array Payload Type Confusion
> Vulnerability ID: CVE-2026-107723
> CVSS Score: 8.1
> Published: 2026-10-08
A high-severity type-confusion vulnerability exists in NearForm fast-jwt prior to version 6.3.0. The vulnerability allows attackers to bypass crucial claim validation steps (such as expiration, issuer, audience, and subject validations) by presenting a validly signed JSON Web Token structured as a JSON array instead of a JSON object. This occurs because the library's decoder fails to reject JSON arrays during type evaluation.
TL;DR
A type-confusion vulnerability in fast-jwt prior to 6.3.0 allows validly signed tokens structured as JSON arrays to completely bypass claim validations such as expiration (exp) and issuer (iss) verification.
---
⚠️ Exploit Status: POC
Technical Details
- CWE ID: CWE-1287: Improper Validation of Specified Type of Input
- Attack Vector: Network (AV:N)
- CVSS Base Score: 8.1
- Exploit Status: Proof of Concept available
- CISA KEV Status: Not listed
- Remediation Status: Patched in v6.3.0
Affected Systems
- Applications utilizing fast-jwt library versions prior to 6.3.0
- fast-jwt: < 6.3.0 (Fixed in: 6.3.0)
Code Analysis
Commit: 86e83ef
fix: reject array payloads explicitly to avoid silent validation bypass
@@ -62,7 +62,7 @@ function decode({ complete, checkTyp }, token) {
// 10. Verify that the resulting octet sequence is a UTF-8-encoded
// representation of a completely valid JSON object conforming to
// RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object.
- if (!payload || typeof payload !== 'object') {
+ if (!payload || typeof payload !== 'object' || Array.isArray(payload)) {
throw new TokenError(TokenError.codes.invalidPayload, 'The payload must be an object', { payload })
}
Mitigation Strategies
- Upgrade fast-jwt dependency to version 6.3.0 or later.
- Enforce strict claims verification using the opt-in requiredClaims configuration.
- Deploy WAF rules to detect and reject base64url-encoded array payloads (beginning with the Wy pattern).
Remediation Steps:
1. Locate all node projects using fast-jwt as a dependency.
2. Update package.json to reference fast-jwt version 6.3.0 or newer.
3. Execute npm install or yarn install to update lockfiles.
4. Ensure production environments are thoroughly redeployed and signature configurations are validated.
5. Set requiredClaims for all configurations requiring expiration, issuer, and audience validations.
References
- GHSA-5hjw-83fp-phq9: Claim validation bypass
- PR #639: Fix array payload check
- fast-jwt v6.3.0 Release Notes
- NVD CVE-2026-107723 Details
- CVE-2026-107723 Record
---
Read the full report for CVE-2026-107723 on our website for more details including interactive diagrams and full exploit analysis.
Mentions
The fast-jwt fix for algorithm confusion missed the prefix The fast-jwt fix for algorithm confusion missed the prefix JWT libraries have been fighting the same class of bug for a decade: a verifier that is handed a public key and a token whose header says HS256, and which decides the key must therefore be an HMAC secret. CVE-2026-107722 is a later round of that fight, and what makes it worth reading is not the bypass itself but where the previous fix stopped. What is affected The CVE record covers the npm package fast-jwt, from version 6.2.0 until 6.3.0. The vulnerability is explicitly described as an incomplete patch of an earlier issue, CVE-2026-34950. Version 6.3.0 contains the current fix. The record rates it 9.8 under CVSS 3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The attack is network-reachable, needs no privileges and no user interaction, and affects confidentiality, integrity and availability. That score reflects the consequence, not the effort: forging a token requires only the public key. The mechanism, as the advisory describes it In src/crypto.js, a function called performDetectPublicKeyAlgorithms decides whether a key string is an RSA public key or something else. It trims whitespace before matching. The matcher that recognises a PEM header, publicKeyPemMatcher, remains anchored to the start of the string. Those two behaviours disagree about where the key begins. Trimming removes whitespace, but the matcher is evaluating the already-trimmed value while still requiring its first character to be part of the PEM header. Any non-whitespace content in front of the header, such as a comment line, a control character, a zero-width character, or text that wraps the key, prevents PEM detection. The value then falls through to the HMAC branch. Once the code treats a public key as an HMAC secret, the classic attack applies. The attacker, who knows the public key by definition, computes an HS256 signature over arbitrary claims using those public bytes as the shared secret. If the verification path infers HS256 or permits it, the forged token validates. Incomplete patches and the shapes they leave behind Security fixes for parsing bugs tend to remove the input that triggered the report. A prefix that was plain whitespace is a natural thing to normalise, and normalising it makes the original proof of concept fail. The structural problem, which is that key classification and key consumption consult different notions of the same string, remains. This is a recurring pattern in parsers that sit between formats. Detection logic and execution logic each carry their own assumptions about the boundaries of a value. A fix that touches only one of them changes the observable behaviour without changing the decision path. The advisory's own mitigation names the durable answer: use an asymmetric-only algorithm allowlist. If the verifier is configured to accept only RS256, ES256 or similar, the HMAC fallback never runs, and how a key string was classified stops mattering. Where this bites hardest A JWT verification bypass is not a library-internal curiosity. It is an authentication bypass wherever the token carries identity, which in 2026 means most API surfaces and a growing number of internal service meshes. The exposure that matters is the subset where token verification is the only gate. A gateway that validates a token and forwards a user identifier downstream, an internal job runner that authorises by claim, a webhook receiver that trusts a signed body: each of these converts one misclassified key into a privilege decision made by an attacker. HS256 acceptance is usually inherited rather than chosen. It arrives with a default configuration, a copied code sample, or a multi-tenant service that lets each tenant supply its own verification settings. Nobody writes a design document titled "we will allow symmetric and asymmetric verification against the same key input". It accumulates. That inheritance is also why the fix in 6.3.0 will not be universally applied. Applications pin versions in lockfiles, and library updates in large dependency trees move at the speed of the slowest maintainer. The vulnerable range is narrow, from 6.2.0 to 6.3.0, which limits the population, but narrow ranges are exactly the ones that get skipped when teams sample their inventory quarterly. What to check, in order - Inventory. Search for fast-jwt in lockfiles and container images, then confirm which resolved versions fall in the 6.2.x line. Package manager audit output is the fastest source; a container image scan catches the copies that arrive as transitive dependencies. - Read the verifier configuration, not just the version. Look for any place where a key is supplied as a string that might carry comments or wrapper text: environment variables, mounted secrets, configuration files assembled by a template, key material pasted into a UI. Those are the inputs that trigger the misclassification. - Restrict the accepted algorithms. If the verifier can be configured with an asymmetric-only allowlist, do that before upgrading. It is the mitigation the advisory itself recommends and it survives a delayed rollout. - Check what the tokens authorise. A verification bypass matters most where the token is the sole authorisation decision. Services that combine a token check with a second, independent check, such as a scoped lookup against a session store, keep some protection when the first gate fails. Detection notes Forged tokens carry a distinguishing property: they are signed with a key the legitimate issuer never uses. Where the application logs token metadata at validation time, comparing the algorithm in the header against the expected algorithm for that endpoint will surface attempts early, even when the signature check passes. Validation failures of a new kind are also a signal. If a verifier starts rejecting tokens it previously accepted, or accepts tokens whose headers differ from the tenant's configured algorithm, the change deserves investigation rather than a note in a log file. Key rotation is not a fix here. The bypass does not require the attacker to know a secret, so rotating the public key pair changes nothing about exploitability, and rotating the HMAC secret changes nothing when the HMAC secret is the public key. The broader lesson A parser fix must be evaluated against the decision it feeds. When detection logic and consumption logic disagree about the same string, closing one path leaves the other open, and the next researcher will find the prefix that the previous fix forgot. Allowlisting an algorithm removes the decision entirely, which is why it holds. References - CVE.org record for CVE-2026-107722: cve.org - fast-jwt security advisory GHSA-ww5h-9m49-7xx4: github.com/nearform/fast-jwt/security/advisories/… - fast-jwt release v6.3.0: github.com/nearform/fast-jwt/releases/tag/v6.3.0
CVE-2026-107723: CVE-2026-107723: Silent Claim-Validator Bypass in NearForm fast-jwt via Array Payload Type Confusion CVE-2026-107723: Silent Claim-Validator Bypass in NearForm fast-jwt via Array Payload Type Confusion > Vulnerability ID: CVE-2026-107723 > CVSS Score: 8.1 > Published: 2026-10-08 A high-severity type-confusion vulnerability exists in NearForm fast-jwt prior to version 6.3.0. The vulnerability allows attackers to bypass crucial claim validation steps (such as expiration, issuer, audience, and subject validations) by presenting a validly signed JSON Web Token structured as a JSON array instead of a JSON object. This occurs because the library's decoder fails to reject JSON arrays during type evaluation. TL;DR A type-confusion vulnerability in fast-jwt prior to 6.3.0 allows validly signed tokens structured as JSON arrays to completely bypass claim validations such as expiration (exp) and issuer (iss) verification. --- ⚠️ Exploit Status: POC Technical Details - CWE ID: CWE-1287: Improper Validation of Specified Type of Input - Attack Vector: Network (AV:N) - CVSS Base Score: 8.1 - Exploit Status: Proof of Concept available - CISA KEV Status: Not listed - Remediation Status: Patched in v6.3.0 Affected Systems - Applications utilizing fast-jwt library versions prior to 6.3.0 - fast-jwt: < 6.3.0 (Fixed in: 6.3.0) Code Analysis Commit: 86e83ef fix: reject array payloads explicitly to avoid silent validation bypass @@ -62,7 +62,7 @@ function decode({ complete, checkTyp }, token) { // 10. Verify that the resulting octet sequence is a UTF-8-encoded // representation of a completely valid JSON object conforming to // RFC 7159 [RFC7159]; let the JWT Claims Set be this JSON object. - if (!payload || typeof payload !== 'object') { + if (!payload || typeof payload !== 'object' || Array.isArray(payload)) { throw new TokenError(TokenError.codes.invalidPayload, 'The payload must be an object', { payload }) } Mitigation Strategies - Upgrade fast-jwt dependency to version 6.3.0 or later. - Enforce strict claims verification using the opt-in requiredClaims configuration. - Deploy WAF rules to detect and reject base64url-encoded array payloads (beginning with the Wy pattern). Remediation Steps: 1. Locate all node projects using fast-jwt as a dependency. 2. Update package.json to reference fast-jwt version 6.3.0 or newer. 3. Execute npm install or yarn install to update lockfiles. 4. Ensure production environments are thoroughly redeployed and signature configurations are validated. 5. Set requiredClaims for all configurations requiring expiration, issuer, and audience validations. References - GHSA-5hjw-83fp-phq9: Claim validation bypass - PR #639: Fix array payload check - fast-jwt v6.3.0 Release Notes - NVD CVE-2026-107723 Details - CVE-2026-107723 Record --- Read the full report for CVE-2026-107723 on our website for more details including interactive diagrams and full exploit analysis.
CVE-2026-107721: CVE-2026-107721: Time Validation Bypass in NearForm fast-jwt due to Loose Temporal Option Validation CVE-2026-107721: Time Validation Bypass in NearForm fast-jwt due to Loose Temporal Option Validation > Vulnerability ID: CVE-2026-107721 > CVSS Score: 5.9 > Published: 2026-10-08 NearForm fast-jwt prior to version 6.3.0 is vulnerable to an input validation flaw where configuring verifier properties (such as clockTolerance, clockTimestamp, and cacheTTL) with non-finite values like Infinity or NaN allows attackers to bypass temporal claim validations, including expiration (exp) and activation (nbf) boundaries. This validation bypass can result in unauthorized session persistence and cache poisoning. TL;DR A flaw in fast-jwt prior to v6.3.0 permits non-finite values (such as Infinity) to bypass validation during verifier initialization. This causes token expiration and activation checks to succeed unconditionally, resulting in complete bypass of JWT expiration controls. --- ⚠️ Exploit Status: POC Technical Details - CWE ID: CWE-613, CWE-682 - Attack Vector: Network - CVSS v3.1: 5.9 (Medium) - Exploit Status: Proof of Concept (Regression Tests) - CISA KEV Status: Not Listed - Remediation Status: Patched in version 6.3.0 Affected Systems - Node.js applications running fast-jwt packages prior to version 6.3.0 - fast-jwt: < 6.3.0 (Fixed in: 6.3.0) Code Analysis Commit: c0fb5b8 reject non-finite clockTimestamp, clockTolerance, and cacheTTL options Mitigation Strategies - Upgrade fast-jwt to version 6.3.0 or higher - Implement input sanitization using Number.isFinite() on configuration properties - Avoid passing unsanitized external variables to verifier initialization configurations Remediation Steps: 1. Execute 'npm install fast-jwt@latest' in the project directory to update the dependency 2. Verify that package lock-files show fast-jwt version is 6.3.0 or higher 3. Audit code for usages of createVerifier and verify that options are static or strictly validated References - GitHub Security Advisory GHSA-687g-22h4-j4w4 - Fix Commit on GitHub - fast-jwt Release Version 6.3.0 - CVE.org Authority Record - NVD Authority Record --- Read the full report for CVE-2026-107721 on our website for more details including interactive diagrams and full exploit analysis.
CVE-2026-107722: CVE-2026-107722: Algorithm Confusion via Non-Whitespace Prefix Bypass in fast-jwt CVE-2026-107722: Algorithm Confusion via Non-Whitespace Prefix Bypass in fast-jwt > Vulnerability ID: CVE-2026-107722 > CVSS Score: 9.8 > Published: 2026-10-08 A critical cryptographic vulnerability in fast-jwt versions 6.2.x prior to 6.3.0 allows unauthenticated remote attackers to execute an asymmetric-to-symmetric algorithm confusion attack due to incomplete validation of leading non-whitespace prefixes. TL;DR Incomplete key sanitization in fast-jwt allows RSA-to-HMAC algorithm confusion, enabling complete authentication bypass. --- ⚠️ Exploit Status: POC Technical Details - CWE ID: CWE-347 - Attack Vector: Network (AV:N) - CVSS Score: 9.8 (Critical) - Impact: Complete Authentication Bypass - Exploit Status: Proof-of-Concept (PoC) available in test suite - KEV Status: Not Listed Affected Systems - fast-jwt Node.js library - fast-jwt: >= 6.2.0 < 6.3.0 (Fixed in: 6.3.0) Code Analysis Commit: d96bbc6 Fix algorithm confusion with non-whitespace prefix Exploit Details - GitHub Security Advisory: GHSA-ww5h-9m49-7xx4: Algorithm Confusion via Non-Whitespace Prefix Bypass in fast-jwt Mitigation Strategies - Upgrade fast-jwt to 6.3.0 or higher - Configure an explicit algorithm allowlist in verifier options Remediation Steps: 1. Verify the installed fast-jwt version in package.json 2. Execute 'npm install fast-jwt@6.3.0' to update the dependency 3. Audit JWT verifier configurations and enforce explicit algorithm parameters References - GitHub Security Advisory GHSA-ww5h-9m49-7xx4 - GitHub Pull Request #632 - Fix Commit d96bbc6 --- Read the full report for CVE-2026-107722 on our website for more details including interactive diagrams and full exploit analysis.
CVE-2026-107720: CVE-2026-107720: Signature Verification Bypass in NearForm fast-jwt CVE-2026-107720: Signature Verification Bypass in NearForm fast-jwt > Vulnerability ID: CVE-2026-107720 > CVSS Score: 7.4 > Published: 2026-10-08 CVE-2026-107720 is a critical signature verification bypass vulnerability in NearForm's fast-jwt Node.js library. Under specific configurations where the token verifier is initialized with a falsy cryptographic key (such as an empty string or null) and a non-empty algorithms allowlist, the library erroneously skips signature validation. This allows unauthenticated remote attackers to submit fabricated, unsigned JSON Web Tokens and bypass the authorization boundary of the application entirely. TL;DR A flaw in fast-jwt prior to 6.3.1 allows attackers to forge JSON Web Tokens and bypass authorization checks entirely if the library is configured with a blank/null key and an explicit list of allowed algorithms. --- ⚠️ Exploit Status: POC Technical Details - CWE ID: CWE-347 (Improper Verification of Cryptographic Signature) - Attack Vector: Network (AV:N) - CVSS v3.1 Score: 7.4 (High) - Exploit Status: Proof of Concept (PoC) available - CISA KEV Status: Not listed - Impact: Complete authentication and authorization bypass Affected Systems - All Node.js applications using NearForm fast-jwt versions prior to 6.3.1 - fast-jwt: < 6.3.1 (Fixed in: 6.3.1) Code Analysis Commit: e22a151 Fix validation logical flaw when key is falsy and non-none algorithm list is used Mitigation Strategies - Upgrade the fast-jwt dependency to version 6.3.1 or higher immediately. - Implement robust environment variable validation to crash the application if cryptographic keys are resolved as empty or null. - Explicitly omit or restrict the use of the 'none' algorithm unless it is required by design. Remediation Steps: 1. Locate the package.json file of the application and check the fast-jwt version. 2. Execute the package manager update command: 'npm install fast-jwt@6.3.1' or equivalent. 3. Audit the application bootstrap code to ensure that the secrets supplied to 'createVerifier' are verified as non-empty during initialization. 4. Re-deploy the application and confirm through logging that no warning or key initialization errors are present. References - Official Security Advisory (GitHub) - Official Fix Commit - NVD CVE Entry --- Read the full report for CVE-2026-107720 on our website for more details including interactive diagrams and full exploit analysis.