CVE-2026-107724: 
JavaScript vulnerability analysis and mitigation

CVE-2026-107724 is a JWT algorithm confusion vulnerability in the fast-jwt npm package (by Nearform) that allows an attacker to forge arbitrary HS256-signed tokens by exploiting the library's misclassification of raw public JWK/JWKS JSON as an HMAC secret. It affects exclusively version 6.2.4 and was disclosed on July 28, 2026, with the GitHub Advisory Database entry published on October 8, 2026. The vulnerability carries a CVSS v3.1 base score of 7.4 (High) (Github Advisory, Feedly).

The root cause (CWE-347: Improper Verification of Cryptographic Signature) lies in src/crypto.js's performDetectPublicKeyAlgorithms() function, which classifies any non-PEM string as symmetric (HMAC) key material. A serialized RSA, EC, or OKP public JWK is valid JSON but lacks a PEM header, so it falls through to the return hsAlgorithms branch, causing the entire public JSON string to be used as an HMAC secret. Because public JWK material is public by design (often exposed via JWKS discovery endpoints), an attacker who obtains the exact serialized bytes can compute a valid HMAC-SHA256 signature over arbitrary JWT claims and have it accepted by createVerifier. Exploitation requires: (1) the application passes raw serialized public JWK/JWKS JSON as the verifier key, (2) HS256 is explicitly permitted or inferred, and (3) the attacker knows the exact serialized bytes (including property ordering and whitespace). A PoC was included in the advisory submission (Github Advisory).

Successful exploitation allows an unauthenticated remote attacker to forge JWT tokens containing arbitrary claims — including subject identifiers, administrator roles, authorization scopes, tenant identifiers, and application-specific permission flags — that the vulnerable application accepts as authentic. This can result in authentication bypass, horizontal or vertical privilege escalation, and unauthorized access to protected application data. Availability is not directly impacted, but the integrity and confidentiality of the application's authentication and authorization layer are fully compromised for affected deployments (Github Advisory).

A functional PoC was included with the original advisory submission (as a ZIP attachment), demonstrating token forgery with both a mixed ['HS256', 'RS256'] allowlist and inferred-algorithm configurations. There is no evidence of in-the-wild exploitation at this time, and the EPSS score is 0.0, indicating very low current exploitation probability. The vulnerability is not listed in the CISA KEV catalog. Attack complexity is rated High due to the requirement that the attacker reproduce the exact serialized JWK bytes used by the verifier (Github Advisory, Feedly).

1. Reconnaissance: Identify applications using fast-jwt version 6.2.4 as a dependency (e.g., via npm list fast-jwt or inspecting package-lock.json). Determine if the application passes raw public JWK/JWKS JSON text directly as the verifier key rather than a PEM-encoded public key.
2. Obtain the public JWK bytes: Retrieve the exact serialized public JWK or JWKS JSON used by the target application's verifier. This material is often publicly available via OIDC/OAuth2 discovery endpoints (e.g., /.well-known/jwks.json) or application source code.
3. Craft the forged token: Using Node.js, construct a JWT header {"alg":"HS256","typ":"JWT"} and a payload with arbitrary claims (e.g., {"sub":"attacker","role":"admin","admin":true}). Base64url-encode both parts.
4. Compute the HMAC signature: Use the exact serialized public JWK JSON string as the HMAC-SHA256 key to sign header.payload:

   const sig = createHmac('sha256', rawJwkString).update(`${header}.${payload}`).digest('base64url');
   const forgedToken = `${header}.${payload}.${sig}`;

5. Submit the forged token: Send the forged token to the target application in the Authorization: Bearer <forgedToken> header. If the application uses createVerifier({ key: rawJwk }) or createVerifier({ key: rawJwk, algorithms: ['HS256', 'RS256'] }), the token will be accepted as valid.
6. Achieve objective: The application processes the attacker-controlled claims, granting elevated privileges or bypassing authentication controls (Github Advisory).

• Logs: JWT tokens with alg: HS256 being accepted by services that are configured with asymmetric (RSA/EC/OKP) public keys; unexpected sub, role, or admin claim values in application access logs that do not correspond to legitimate users.
• Network: Requests to JWKS discovery endpoints (e.g., /.well-known/jwks.json) from unusual or external IP addresses shortly before suspicious authenticated activity, suggesting an attacker is harvesting public key material.
• Application Behavior: Authenticated sessions or API calls with administrative privileges originating from accounts or identifiers not present in the user directory; authorization decisions granting elevated access inconsistent with the user's actual role.
• Dependency Audit: Presence of fast-jwt@6.2.4 in node_modules or package-lock.json in Node.js applications (Github Advisory).

Upgrade fast-jwt to version 6.3.0 or later, which introduces assertNotAsymmetricJwkJson() to detect and reject raw asymmetric JWK/JWKS JSON before it can be classified as an HMAC secret (fast-jwt v6.3.0, fix PR #636). As an immediate workaround prior to upgrading, ensure verifiers are configured with PEM-encoded public keys (not raw JWK JSON) and restrict the algorithms allowlist to asymmetric-only values (e.g., algorithms: ['RS256']), which prevents HS256 from being inferred or accepted. Applications already using PEM keys with an asymmetric-only algorithm allowlist are not affected.

The vulnerability was reported by researcher the-vibe-dev and addressed promptly by Nearform maintainer SociableSteve, with the fix merged and released in v6.3.0 on July 28, 2026 — the same day the advisory was published. Reviewer lv10 provided thorough code review commentary, noting the fix correctly handles all three JWKS serialization shapes (single JWK, {keys: [...]}, and bare keys array) and that the dynamic key-callback path used by real JWKS integrations (e.g., get-jwks) is protected unconditionally (fix PR #636). The advisory notes this is at least the third security advisory in a related lineage of algorithm-confusion issues in fast-jwt, suggesting ongoing scrutiny of the library's key detection logic.