GHSA-G3JJ-5CMM-3HXX
Vulnerability from github – Published: 2026-10-08 22:01 – Updated: 2026-10-08 22:01Summary
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:
```js 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
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "fast-jwt"
},
"ranges": [
{
"events": [
{
"introduced": "6.2.4"
},
{
"fixed": "6.3.0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"6.2.4"
]
}
],
"aliases": [
"CVE-2026-107724"
],
"database_specific": {
"cwe_ids": [
"CWE-347"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-08T22:01:53Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\n`fast-jwt` 6.2.4 silently classifies raw serialized public JWK JSON\nas an HMAC secret.\n\nIf an application supplies public JWK JSON text as the verifier key and\nHS256 is explicitly allowed or automatically inferred, an attacker who\nknows the same public JSON text can use it as an HMAC key and create an\narbitrary HS256 token that `fast-jwt` accepts as valid.\n\nThis can result in authentication or authorization bypass through forged\nJWT claims.\n\nThe PoC demonstrates the issue with a serialized RSA public JWK. The same\nnon-PEM classification also applies to raw JWKS JSON text, although the\nattached standalone PoC focuses on the smallest JWK case.\n\n### Details\n\nThe verifier accepts a string or Buffer as key material. In\n`src/crypto.js`, `performDetectPublicKeyAlgorithms()` attempts to infer\nthe permitted algorithm family from the supplied string.\n\nStrings matching supported PEM public-key formats are classified as\nasymmetric keys. Any other non-empty string is assumed to be an HMAC\nsecret:\n\n```js\nfunction performDetectPublicKeyAlgorithms(key) {\n const trimmedKey = key.trim()\n const publicKeyPemMatch = trimmedKey.match(publicKeyPemMatcher)\n\n if (trimmedKey.match(privateKeyPemMatcher)) {\n throw new TokenError(\n TokenError.codes.invalidKey,\n \u0027Private keys are not supported for verifying.\u0027\n )\n } else if (\n publicKeyPemMatch \u0026\u0026\n publicKeyPemMatch[1] === \u0027RSA\u0027\n ) {\n return rsaAlgorithms\n } else if (\n !publicKeyPemMatch \u0026\u0026\n !trimmedKey.includes(publicKeyX509CertMatcher)\n ) {\n // Not a PEM, assume a plain secret\n return hsAlgorithms\n }\n\n // ...\n}\n\nA serialized RSA, EC, or OKP public JWK is valid JSON, but it is not PEM\nand does not contain a certificate header. It therefore reaches:\n\nreturn hsAlgorithms\n\nThe HS256 verification path then uses the complete public JSON string as\nthe HMAC key.\n\nBecause JWK public-key material is public by design, an attacker can know\nthe verifier\u0027s cryptographic key material. When that public material is\nreinterpreted as an HMAC secret, the attacker can calculate a valid\nHS256 signature over arbitrary claims.\n\nThe vulnerable transition is:\n\nPublic asymmetric JWK JSON\n |\n v\nDoes not match PEM detection\n |\n v\nClassified as a plain secret\n |\n v\nHS256 permitted or inferred\n |\n v\nAttacker signs using public JSON bytes\n |\n v\nForged token accepted\n\nThe attached PoC demonstrates both relevant configurations:\n\nAn explicit mixed-family allowlist:\ncreateVerifier({\n key: rawJwk,\n algorithms: [\u0027HS256\u0027, \u0027RS256\u0027]\n})\nNo explicit algorithm allowlist:\ncreateVerifier({\n key: rawJwk\n})\n\nIn the second configuration, fast-jwt detects the raw non-PEM string as\nsymmetric key material and permits the HS algorithm family.\n\nAn RS256-only verifier rejects the same forged token, providing a\nnegative control:\n\ncreateVerifier({\n key: rawJwk,\n algorithms: [\u0027RS256\u0027]\n})\n\nThe documentation describes asymmetric verifier keys as PEM-encoded\npublic keys. The security issue is not that the raw JWK is successfully\nparsed as an asymmetric key. It is that ambiguous structured public-key\ntext is silently reclassified as a symmetric secret rather than being\nrejected, and that this classification permits an attacker-controlled\nHS256 token.\n\nPoC\n\nRequirements:\n\nNode.js 20 or newer\nnpm\nThe attached submission ZIP\n\nExtract the attachment and run:\n\ncd poc\nnpm install\nnode poc.js\n\nThe PoC performs the following steps:\n\nGenerates a fresh RSA key pair locally.\nExports only the public key as a JWK.\nAdds ordinary public JWK metadata such as kid, use, and alg.\nSerializes the public JWK as JSON.\nUses the serialized public JWK text as an HS256 HMAC key.\nCreates a token containing attacker-selected administrative claims.\nSupplies the same raw public JSON string to the real\nfast-jwt verifier.\nConfirms acceptance with a mixed HS256/RS256 allowlist.\nConfirms acceptance when algorithm detection is left enabled.\nConfirms rejection with an RS256-only verifier.\n\nExpected output:\n\nmixed algorithms: forged token accepted\ninferred algorithms: forged token accepted\nRS256-only control: forged token rejected\nVULNERABLE: fast-jwt@6.2.4 accepted attacker-signed HS256 claims\n\nThe accepted token contains:\n\n{\n \"sub\": \"attacker\",\n \"role\": \"admin\",\n \"admin\": true\n}\n\nThe PoC operates entirely locally using a newly generated key pair. It\ndoes not contact any production service, identity provider, or\nthird-party application.\n\nImpact\n\nAn affected application may accept attacker-generated JWT claims as\nauthentic.\n\nDepending on how verified claims are used, an attacker could potentially\nforge:\n\nuser or subject identifiers;\nadministrator roles;\nauthorization scopes;\npermissions;\ntenant or organization identifiers; and\napplication-specific authorization flags.\n\nThis may result in authentication bypass, horizontal privilege\nescalation, vertical privilege escalation, or unauthorized access to\nprotected application data.\n\nExploitation requires all of the following:\n\nThe application passes raw serialized public JWK or JWKS JSON text as\nthe verifier key.\nHS256 is explicitly permitted or is inferred from the non-PEM string.\nThe attacker knows the exact serialized bytes supplied to the\nverifier.\n\nPublic JWK/JWKS material is normally available to relying parties and\noften exposed through public discovery endpoints. However, property\nordering, whitespace, or other serialization differences may affect an\nattacker\u0027s ability to reproduce the exact HMAC key bytes.\n\nThese integration and serialization requirements are represented by\nHigh attack complexity.\n\nApplications that supply a supported PEM public key and restrict\nverification to the expected asymmetric algorithm family are not\naffected by this PoC.\n\nEarlier package versions were not assessed as part of this report.\n\nSuggested remediation\n\nStructured public-key representations should be detected before an\narbitrary non-PEM string is classified as symmetric key material.\n\nAt minimum, JSON strings containing asymmetric JWK or JWKS structures\nshould be rejected for HS* verification. Relevant asymmetric kty\nvalues include:\n\nRSA\nEC\nOKP\n\nPotential approaches include:\n\nParse JSON-looking verifier strings before HMAC classification.\nReject asymmetric JWK/JWKS structures for HS256, HS384, and HS512.\nDo not treat all non-PEM strings as symmetric secrets merely because\nPEM detection failed.\nRequire explicit algorithm selection when the key format is\nambiguous.\nBind the permitted algorithm family to the semantic key type rather\nthan the success or failure of PEM detection.\n\nRegression tests should cover:\n\ncompact serialized JWK JSON;\npretty-printed JWK JSON;\nraw JWKS JSON;\nRSA, EC, and OKP public keys;\nmixed symmetric/asymmetric algorithm allowlists;\ndefault algorithm detection;\nasymmetric-only algorithm controls;\ntrailing whitespace and newline variants; and\nproperty-order and serialization variants.\n[fast-jwt-raw-jwk-hs256-submit.zip](https://github.com/user-attachments/files/30396435/fast-jwt-raw-jwk-hs256-submit.zip)",
"id": "GHSA-g3jj-5cmm-3hxx",
"modified": "2026-10-08T22:01:53Z",
"published": "2026-10-08T22:01:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/security/advisories/GHSA-g3jj-5cmm-3hxx"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/pull/636"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/commit/10f9591349199ed2ab9fa1748ce92cdca697f6cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/nearform/fast-jwt"
},
{
"type": "WEB",
"url": "https://github.com/nearform/fast-jwt/releases/tag/v6.3.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "fast-jwt treats raw public JWK JSON as an HMAC secret, enabling HS256 token forgery"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.