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 RS256-only verifier.

Expected output:

mixed algorithms: forged token accepted
inferred algorithms: forged token accepted
RS256-only control: forged token rejected
VULNERABLE: fast-jwt@6.2.4 accepted attacker-signed HS256 claims

The accepted token contains:

{
  "sub": "attacker",
  "role": "admin",
  "admin": true
}

The PoC operates entirely locally using a newly generated key pair. It
does not contact any production service, identity provider, or
third-party application.

Impact

An affected application may accept attacker-generated JWT claims as
authentic.

Depending on how verified claims are used, an attacker could potentially
forge:

user or subject identifiers;
administrator roles;
authorization scopes;
permissions;
tenant or organization identifiers; and
application-specific authorization flags.

This may result in authentication bypass, horizontal privilege
escalation, vertical privilege escalation, or unauthorized access to
protected application data.

Exploitation requires all of the following:

The application passes raw serialized public JWK or JWKS JSON text as
the verifier key.
HS256 is explicitly permitted or is inferred from the non-PEM string.
The attacker knows the exact serialized bytes supplied to the
verifier.

Public JWK/JWKS material is normally available to relying parties and
often exposed through public discovery endpoints. However, property
ordering, whitespace, or other serialization differences may affect an
attacker's ability to reproduce the exact HMAC key bytes.

These integration and serialization requirements are represented by
High attack complexity.

Applications that supply a supported PEM public key and restrict
verification to the expected asymmetric algorithm family are not
affected by this PoC.

Earlier package versions were not assessed as part of this report.

Suggested remediation

Structured public-key representations should be detected before an
arbitrary non-PEM string is classified as symmetric key material.

At minimum, JSON strings containing asymmetric JWK or JWKS structures
should be rejected for HS* verification. Relevant asymmetric kty
values include:

RSA
EC
OKP

Potential approaches include:

Parse JSON-looking verifier strings before HMAC classification.
Reject asymmetric JWK/JWKS structures for HS256, HS384, and HS512.
Do not treat all non-PEM strings as symmetric secrets merely because
PEM detection failed.
Require explicit algorithm selection when the key format is
ambiguous.
Bind the permitted algorithm family to the semantic key type rather
than the success or failure of PEM detection.

Regression tests should cover:

compact serialized JWK JSON;
pretty-printed JWK JSON;
raw JWKS JSON;
RSA, EC, and OKP public keys;
mixed symmetric/asymmetric algorithm allowlists;
default algorithm detection;
asymmetric-only algorithm controls;
trailing whitespace and newline variants; and
property-order and serialization variants.
[fast-jwt-raw-jwk-hs256-submit.zip](https://github.com/user-attachments/files/30396435/fast-jwt-raw-jwk-hs256-submit.zip)