JWT libraries have been fighting the same class of bug for a decade: a verifier that is handed a public key and a token whose header says HS256, and which decides the key must therefore be an HMAC secret. CVE-2026-107722 is a later round of that fight, and what makes it worth reading is not the bypass itself but where the previous fix stopped.
What is affected
The CVE record covers the npm package fast-jwt, from version 6.2.0 until 6.3.0. The vulnerability is explicitly described as an incomplete patch of an earlier issue, CVE-2026-34950. Version 6.3.0 contains the current fix.
The record rates it 9.8 under CVSS 3.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. The attack is network-reachable, needs no privileges and no user interaction, and affects confidentiality, integrity and availability. That score reflects the consequence, not the effort: forging a token requires only the public key.
The mechanism, as the advisory describes it
In src/crypto.js, a function called performDetectPublicKeyAlgorithms decides whether a key string is an RSA public key or something else. It trims whitespace before matching. The matcher that recognises a PEM header, publicKeyPemMatcher, remains anchored to the start of the string.
Those two behaviours disagree about where the key begins. Trimming removes whitespace, but the matcher is evaluating the already-trimmed value while still requiring its first character to be part of the PEM header. Any non-whitespace content in front of the header, such as a comment line, a control character, a zero-width character, or text that wraps the key, prevents PEM detection. The value then falls through to the HMAC branch.
Once the code treats a public key as an HMAC secret, the classic attack applies. The attacker, who knows the public key by definition, computes an HS256 signature over arbitrary claims using those public bytes as the shared secret. If the verification path infers HS256 or permits it, the forged token validates.
Incomplete patches and the shapes they leave behind
Security fixes for parsing bugs tend to remove the input that triggered the report. A prefix that was plain whitespace is a natural thing to normalise, and normalising it makes the original proof of concept fail. The structural problem, which is that key classification and key consumption consult different notions of the same string, remains.
This is a recurring pattern in parsers that sit between formats. Detection logic and execution logic each carry their own assumptions about the boundaries of a value. A fix that touches only one of them changes the observable behaviour without changing the decision path.
The advisory's own mitigation names the durable answer: use an asymmetric-only algorithm allowlist. If the verifier is configured to accept only RS256, ES256 or similar, the HMAC fallback never runs, and how a key string was classified stops mattering.
Where this bites hardest
A JWT verification bypass is not a library-internal curiosity. It is an authentication bypass wherever the token carries identity, which in 2026 means most API surfaces and a growing number of internal service meshes.
The exposure that matters is the subset where token verification is the only gate. A gateway that validates a token and forwards a user identifier downstream, an internal job runner that authorises by claim, a webhook receiver that trusts a signed body: each of these converts one misclassified key into a privilege decision made by an attacker.
HS256 acceptance is usually inherited rather than chosen. It arrives with a default configuration, a copied code sample, or a multi-tenant service that lets each tenant supply its own verification settings. Nobody writes a design document titled "we will allow symmetric and asymmetric verification against the same key input". It accumulates.
That inheritance is also why the fix in 6.3.0 will not be universally applied. Applications pin versions in lockfiles, and library updates in large dependency trees move at the speed of the slowest maintainer. The vulnerable range is narrow, from 6.2.0 to 6.3.0, which limits the population, but narrow ranges are exactly the ones that get skipped when teams sample their inventory quarterly.
What to check, in order
Inventory. Search for
fast-jwtin lockfiles and container images, then confirm which resolved versions fall in the 6.2.x line. Package manager audit output is the fastest source; a container image scan catches the copies that arrive as transitive dependencies.Read the verifier configuration, not just the version. Look for any place where a key is supplied as a string that might carry comments or wrapper text: environment variables, mounted secrets, configuration files assembled by a template, key material pasted into a UI. Those are the inputs that trigger the misclassification.
Restrict the accepted algorithms. If the verifier can be configured with an asymmetric-only allowlist, do that before upgrading. It is the mitigation the advisory itself recommends and it survives a delayed rollout.
Check what the tokens authorise. A verification bypass matters most where the token is the sole authorisation decision. Services that combine a token check with a second, independent check, such as a scoped lookup against a session store, keep some protection when the first gate fails.
Detection notes
Forged tokens carry a distinguishing property: they are signed with a key the legitimate issuer never uses. Where the application logs token metadata at validation time, comparing the algorithm in the header against the expected algorithm for that endpoint will surface attempts early, even when the signature check passes.
Validation failures of a new kind are also a signal. If a verifier starts rejecting tokens it previously accepted, or accepts tokens whose headers differ from the tenant's configured algorithm, the change deserves investigation rather than a note in a log file.
Key rotation is not a fix here. The bypass does not require the attacker to know a secret, so rotating the public key pair changes nothing about exploitability, and rotating the HMAC secret changes nothing when the HMAC secret is the public key.
The broader lesson
A parser fix must be evaluated against the decision it feeds. When detection logic and consumption logic disagree about the same string, closing one path leaves the other open, and the next researcher will find the prefix that the previous fix forgot. Allowlisting an algorithm removes the decision entirely, which is why it holds.
References
CVE.org record for CVE-2026-107722: https://www.cve.org/CVERecord?id=CVE-2026-107722
fast-jwt security advisory GHSA-ww5h-9m49-7xx4: https://github.com/nearform/fast-jwt/security/advisories/GHSA-ww5h-9m49-7xx4
fast-jwt release v6.3.0: https://github.com/nearform/fast-jwt/releases/tag/v6.3.0