CVE-2026-44351
published 2026-05-13CVE-2026-44351: fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.2.4, a critical authentication-bypass vulnerability in fast-jwt's async key-resolver…
PriorityP265critical9.1CVSS 3.1
AVNACLPRNUINSUCHIHAN
EPSS
0.25%
16.2th percentile
fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.2.4, a critical authentication-bypass vulnerability in fast-jwt's async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (''), for example via the common keys[decoded.header.kid] || '' JWKS-style fallback, fast-jwt converts it to a zero-length Buffer, hands it to crypto.createSecretKey, derives allowedAlgorithms = ['HS256','HS384','HS512'] from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes HMAC-SHA256(key='', input='${header}.${payload}'), which Node accepts without complaint — and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. This vulnerability is fixed in 6.2.4.
Affected
4 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| jwt_project | jwt | >= 0 < 3.2.0 | 3.2.0 |
| nearform | fast-jwt | < 6.2.4 | 6.2.4 |
| nearform | fast-jwt | >= 0 < 6.2.4 | 6.2.4 |
| pyjwt_project | pyjwt | >= 0 < 2.14.0 | 2.14.0 |
CVSS provenance
nvdv3.19.1CRITICALCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
ghsa9.1CRITICAL
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
GHSA
PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery
ghsa·2026-10-22·CVSS 9.1
CVE-2026-44351 [CRITICAL] CWE-347 PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery
PyJWT: HS256/384/512 verify accepts empty HMAC key via oct JWK (PyJWK/PyJWKClient) enabling token forgery
### Summary
`HMACAlgorithm.from_jwk` accepts a symmetric (`kty=oct`) JWK whose `k` value is
the empty string and returns a zero-length key without raising. When a token is
then verified with that key object (a `PyJWK`, or a `PyJWK` resolved by
`PyJWKSet` / `PyJWKClient`), the HMAC verifier computes
`HMAC(key=b"", signing_input)` and accepts any token an attacker forged with the
same empty key. The attacker needs no secret knowledge: they reproduce the digest
locally with an empty key and set the token's `kid` to the empty-`k` JWK.
The empty-key rejection that `HMACAlgorithm.prepare_key` performs for
string/bytes secrets (added in 2.13.0) was never propagated to the sibling
`from_jwk
GHSA
ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351
ghsa·2026-05-18·CVSS 9.1
CVE-2026-45363 [CRITICAL] CWE-1391 ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351
ruby-jwt: Empty-key HMAC bypass; cross-language sibling of CVE-2026-44351
`JWT.decode(token, '', true, algorithm: 'HS256')` accepts an attacker-forged token.
`OpenSSL::HMAC.digest('SHA256', '', payload)` returns a valid digest under an empty key, and no `raise
InvalidKeyError if key.empty?` precondition exists in the HMAC algorithm.
```
JWT.decode(token, "", true, algorithm: 'HS256')
-> JWA::Hmac.verify(verification_key: "", ...)
-> OpenSSL::HMAC.digest('SHA256', "", signing_input) == signature
```
The same path is reached when a keyfinder block or key_finder: argument returns "", nil, or an
array containing nil for an unknown key. JWT::Decode#find_key only rejects literal nil and empty
arrays, and JWT::JWA::Hmac silently coerces nil to "" (signing_key ||= '') before signing.
```
JWT.d
GHSA
fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver
ghsa·2026-05-06
CVE-2026-44351 [CRITICAL] CWE-1391 fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver
fast-jwt: JWT auth bypass due to empty HMAC secret accepted by async key resolver
### Summary
A critical authentication-bypass vulnerability in `fast-jwt`'s async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (`''`), for example via the common `keys[decoded.header.kid] || ''` JWKS-style fallback, fast-jwt converts it to a zero-length `Buffer`, hands it to `crypto.createSecretKey`, derives `allowedAlgorithms = ['HS256','HS384','HS512']` from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes `HMAC-SHA256(key='', input='${header}.${payload}')`, which Node accepts without complaint — and the verifier returns the attacker
No detection rules found.
No public exploits indexed.
No writeups or analysis indexed.
2026-05-13
Published