CVE-2026-107724

fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.2.4, fast-jwt can classify raw serialized public JWK or JWKS JSON as an HMAC secret because src/crypto.js performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use those bytes as an HMAC key and create a token containing arbitrary claims that createVerifier accepts. Serialization ordering or whitespace differences can prevent exploitation, and applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected. This issue is fixed in version 6.3.0.

fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.2.4, fast-jwt can classify raw serialized public JWK or JWKS JSON as an HMAC secret because src/crypto.js performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use those bytes as an HMAC key and create a token containing arbitrary claims that createVerifier accepts. Serialization ordering or whitespace differences can prevent exploitation, and applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected. This issue is fixed in version 6.3.0.

Summary

fast-jwt 6.2.4 silently classifies raw serialized public JWK JSON as an HMAC secret.

If an application supplies public JWK JSON text as the verifier key and HS256 is explicitly allowed or automatically inferred, an attacker who knows the same public JSON text can use it as an HMAC key and create an arbitrary HS256 token that fast-jwt accepts as valid.

This can result in authentication or authorization bypass through forged JWT claims.

The PoC demonstrates the issue with a serialized RSA public JWK. The same non-PEM classification also applies to raw JWKS JSON text, although the attached standalone PoC focuses on the smallest JWK case.

Details

The verifier accepts a string or Buffer as key material. In src/crypto.js, performDetectPublicKeyAlgorithms() attempts to infer the permitted algorithm family from the supplied string.

Strings matching supported PEM public-key formats are classified as asymmetric keys. Any other non-empty string is assumed to be an HMAC secret:

function performDetectPublicKeyAlgorithms(key) {
  const trimmedKey = key.trim()
  const publicKeyPemMatch = trimmedKey.match(publicKeyPemMatcher)

  if (trimmedKey.match(privateKeyPemMatcher)) {
    throw new TokenError(
      TokenError.codes.invalidKey,
      'Private keys are not supported for verifying.'
    )
  } else if (
    publicKeyPemMatch &&
    publicKeyPemMatch[1] === 'RSA'
  ) {
    return rsaAlgorithms
  } else if (
    !publicKeyPemMatch &&
    !trimmedKey.includes(publicKeyX509CertMatcher)
  ) {
    // Not a PEM, assume a plain secret
    return hsAlgorithms
  }

  // ...
}

A serialized RSA, EC, or OKP public JWK is valid JSON, but it is not PEM
and does not contain a certificate header. It therefore reaches:

return hsAlgorithms

The HS256 verification path then uses the complete public JSON string as
the HMAC key.

Because JWK public-key material is public by design, an attacker can know
the verifier's cryptographic key material. When that public material is
reinterpreted as an HMAC secret, the attacker can calculate a valid
HS256 signature over arbitrary claims.

The vulnerable transition is:

Public asymmetric JWK JSON
        |
        v
Does not match PEM detection
        |
        v
Classified as a plain secret
        |
        v
HS256 permitted or inferred
        |
        v
Attacker signs using public JSON bytes
        |
        v
Forged token accepted

The attached PoC demonstrates both relevant configurations:

An explicit mixed-family allowlist:
createVerifier({
  key: rawJwk,
  algorithms: ['HS256', 'RS256']
})
No explicit algorithm allowlist:
createVerifier({
  key: rawJwk
})

In the second configuration, fast-jwt detects the raw non-PEM string as
symmetric key material and permits the HS algorithm family.

An RS256-only verifier rejects the same forged token, providing a
negative control:

createVerifier({
  key: rawJwk,
  algorithms: ['RS256']
})

The documentation describes asymmetric verifier keys as PEM-encoded
public keys. The security issue is not that the raw JWK is successfully
parsed as an asymmetric key. It is that ambiguous structured public-key
text is silently reclassified as a symmetric secret rather than being
rejected, and that this classification permits an attacker-controlled
HS256 token.

PoC

Requirements:

Node.js 20 or newer
npm
The attached submission ZIP

Extract the attachment and run:

cd poc
npm install
node poc.js

The PoC performs the following steps:

Generates a fresh RSA key pair locally.
Exports only the public key as a JWK.
Adds ordinary public JWK metadata such as kid, use, and alg.
Serializes the public JWK as JSON.
Uses the serialized public JWK text as an HS256 HMAC key.
Creates a token containing attacker-selected administrative claims.
Supplies the same raw public JSON string to the real
fast-jwt verifier.
Confirms acceptance with a mixed HS256/RS256 allowlist.
Confirms acceptance when algorithm detection is left enabled.
Confirms rejection with an…

fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.2.4, fast-jwt can classify raw serialized public JWK or JWKS JSON as an HMAC secret because src/crypto.js performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use those bytes as an HMAC key and create a token containing arbitrary claims that createVerifier accepts. Serialization ordering or whitespace differences can prevent exploitation, and applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected. This issue is fixed in version 6.3.0.

fast-jwt provides fast JSON Web Token (JWT) implementation. In 6.2.4, fast-jwt can classify raw serialized public JWK or JWKS JSON as an HMAC secret because src/crypto.js performDetectPublicKeyAlgorithms treats non-PEM strings as symmetric key material. If HS256 is explicitly allowed or inferred, an attacker who knows the exact serialized public-key bytes can use those bytes as an HMAC key and create a token containing arbitrary claims that createVerifier accepts. Serialization ordering or whitespace differences can prevent exploitation, and applications using supported PEM keys with an asymmetric-only algorithm allowlist are not affected. This issue is fixed in version 6.3.0.

Summary

fast-jwt 6.2.4 silently classifies raw serialized public JWK JSON as an HMAC secret.

If an application supplies public JWK JSON text as the verifier key and HS256 is explicitly allowed or automatically inferred, an attacker who knows the same public JSON text can use it as an HMAC key and create an arbitrary HS256 token that fast-jwt accepts as valid.

This can result in authentication or authorization bypass through forged JWT claims.

The PoC demonstrates the issue with a serialized RSA public JWK. The same non-PEM classification also applies to raw JWKS JSON text, although the attached standalone PoC focuses on the smallest JWK case.

Details

The verifier accepts a string or Buffer as key material. In src/crypto.js, performDetectPublicKeyAlgorithms() attempts to infer the permitted algorithm family from the supplied string.

Strings matching supported PEM public-key formats are classified as asymmetric keys. Any other non-empty string is assumed to be an HMAC secret:

function performDetectPublicKeyAlgorithms(key) {
  const trimmedKey = key.trim()
  const publicKeyPemMatch = trimmedKey.match(publicKeyPemMatcher)

  if (trimmedKey.match(privateKeyPemMatcher)) {
    throw new TokenError(
      TokenError.codes.invalidKey,
      'Private keys are not supported for verifying.'
    )
  } else if (
    publicKeyPemMatch &&
    publicKeyPemMatch[1] === 'RSA'
  ) {
    return rsaAlgorithms
  } else if (
    !publicKeyPemMatch &&
    !trimmedKey.includes(publicKeyX509CertMatcher)
  ) {
    // Not a PEM, assume a plain secret
    return hsAlgorithms
  }

  // ...
}

A serialized RSA, EC, or OKP public JWK is valid JSON, but it is not PEM
and does not contain a certificate header. It therefore reaches:

return hsAlgorithms

The HS256 verification path then uses the complete public JSON string as
the HMAC key.

Because JWK public-key material is public by design, an attacker can know
the verifier's cryptographic key material. When that public material is
reinterpreted as an HMAC secret, the attacker can calculate a valid
HS256 signature over arbitrary claims.

The vulnerable transition is:

Public asymmetric JWK JSON
        |
        v
Does not match PEM detection
        |
        v
Classified as a plain secret
        |
        v
HS256 permitted or inferred
        |
        v
Attacker signs using public JSON bytes
        |
        v
Forged token accepted

The attached PoC demonstrates both relevant configurations:

An explicit mixed-family allowlist:
createVerifier({
  key: rawJwk,
  algorithms: ['HS256', 'RS256']
})
No explicit algorithm allowlist:
createVerifier({
  key: rawJwk
})

In the second configuration, fast-jwt detects the raw non-PEM string as
symmetric key material and permits the HS algorithm family.

An RS256-only verifier rejects the same forged token, providing a
negative control:

createVerifier({
  key: rawJwk,
  algorithms: ['RS256']
})

The documentation describes asymmetric verifier keys as PEM-encoded
public keys. The security issue is not that the raw JWK is successfully
parsed as an asymmetric key. It is that ambiguous structured public-key
text is silently reclassified as a symmetric secret rather than being
rejected, and that this classification permits an attacker-controlled
HS256 token.

PoC

Requirements:

Node.js 20 or newer
npm
The attached submission ZIP

Extract the attachment and run:

cd poc
npm install
node poc.js

The PoC performs the following steps:

Generates a fresh RSA key pair locally.
Exports only the public key as a JWK.
Adds ordinary public JWK metadata such as kid, use, and alg.
Serializes the public JWK as JSON.
Uses the serialized public JWK text as an HS256 HMAC key.
Creates a token containing attacker-selected administrative claims.
Supplies the same raw public JSON string to the real
fast-jwt verifier.
Confirms acceptance with a mixed HS256/RS256 allowlist.
Confirms acceptance when algorithm detection is left enabled.
Confirms rejection with an…