A public key became a shared secret.

JWT verification has two linked inputs: the token’s signature algorithm, and the semantic type of the verification key. Losing the second turns the first into an attacker’s choice.

The selected JWT algorithm family must be cryptographically bound to the semantic key type; asymmetric public material must never fall back to an HMAC byte string.

The vulnerable deployment prerequisites are specific:

1. the application supplies raw serialized JWK/JWKS JSON as a string or buffer rather than converting it into a native asymmetric key object;
2. the verifier accepts HS256 alongside an asymmetric family, or lets fast-jwt infer allowed algorithms; and
3. the attacker knows the exact serialized public-key bytes used by the verifier, including property ordering and whitespace when a raw string is used.

An RS256-only verifier is not affected by the demonstrated HS256 forgery path.

In fast-jwt 6.2.4, algorithm detection distinguished recognizable PEM and certificate material from other strings. A non-empty string that was not recognized as PEM fell into the generic HMAC-secret branch:

} else if (!publicKeyPemMatch && !trimmedKey.includes(publicKeyX509CertMatcher)) {
  // Not a PEM, assume a plain secret
  return hsAlgorithms
}

Raw RSA, EC or OKP JWK JSON is not PEM and contains no X.509 header. The verifier therefore loses the semantic information that this string represents public asymmetric key material — even though the JSON’s own kty field says so explicitly.

Once the key is categorized as a secret, an HS256 token using the same serialized JSON bytes as its HMAC key is internally consistent from the verifier’s mistaken point of view.

The key parser used representation shape as a proxy for key semantics. “Not recognizable PEM” became “plain symmetric secret,” even when the string was structured JSON whose kty explicitly identified RSA, EC or OKP public-key material.

Cryptographic policy should fail closed when the key’s semantic type and the requested algorithm family disagree. Falling back from an unrecognized structured key to a generic secret converts intentionally public bytes into authentication material.

The fixing commit is 10f9591349199ed2ab9fa1748ce92cdca697f6cf, released in fast-jwt 6.3.0. It recognizes JSON-looking key strings before the generic raw-secret fallback and rejects asymmetric structures being treated as symmetric key material. The guarded structures are:

1. a top-level JWK with kty of RSA, EC or OKP;
2. a JWKS containing asymmetric keys; and
3. a bare array containing asymmetric JWK values.

Symmetric JWKs using kty: "oct" and ordinary opaque HMAC secrets remain valid. An explicitly all-HS caller is treated as an intentional assertion that the supplied material is meant to be symmetric; the fix targets the mixed-family and inferred cases where asymmetric semantics would otherwise be silently lost.

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

Attack complexity is elevated because exploitation depends on a particular key representation and algorithm configuration, including knowledge of the exact serialized bytes used as the verifier key. Downstream effect depends on what the consuming application trusts from JWT claims — commonly impersonation, authorization bypass, or access granted by forged roles or identities.

That lineage does not expand the published affected range. Earlier releases were explicitly not assessed for the advisory and are not claimed affected here.

Upgrade to fast-jwt 6.3.0 or later. Applications should also make their intended cryptographic model explicit:

1. convert JWK/JWKS data into native asymmetric key objects where appropriate;
2. restrict verifiers to the expected algorithm family rather than mixed symmetric/asymmetric allowlists unless there is a compelling reason;
3. reject keys whose semantic type conflicts with the selected JWT algorithm;
4. avoid “unknown structured key ⇒ raw secret” fallback behaviour entirely.

Regression tests should cover RSA, EC, OKP and oct JWK values as top-level JWKs, JWKS documents, arrays, PEM strings and opaque secrets — across both inferred and explicit algorithm lists.

1. GHSA-g3jj-5cmm-3hxx — fast-jwt advisory and public PoC
2. fast-jwt repository and release history
3. fast-jwt release history

Credit: Discovered and reported by Charles Vosburgh. Research was AI-assisted through source mapping, hypothesis generation, release comparison and evidence organization; final validation, disclosure coordination, severity calibration and publication review remained human.