CVE-2026-44351: fast-jwt: Empty HMAC Secret Accepted in Async Key Resolver (JWT Auth Bypass)
Versions of fast-jwt before 6.2.4 can accept JWTs verified against an empty HMAC key when the application's async key resolver returns an empty string. The sources describe this as a critical authentication bypass with a CVSS 3.1 score of 9.1, and the description states it is fixed in 6.2.4. No confirmed exploitation appears in the sources consulted, and the CVE is not listed in CISA KEV.
Overview
The record describes an authentication flaw in the async key-resolver flow of fast-jwt, a JSON Web Token implementation. When the application's key resolver returns an empty string, the library treats it as a valid, zero-length HMAC secret. The weakness is classified as CWE-287, Improper Authentication. The fix is stated to be in version 6.2.4.
Impact
According to the record, an unauthenticated attacker could produce tokens that the verifier accepts as authentic, and the verifier would then return the attacker-chosen claims, such as subject, admin flags or scopes. The record lists a CVSS 3.1 score of 9.1 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, which indicates high confidentiality and integrity impact with no availability impact.
Affected products and versions
- Nearform Fast-jwt, versions before 6.2.4 (recorded as version < 6.2.4).
The record's fixes field is empty, so the fixed version is taken from the description, which states the vulnerability is fixed in 6.2.4. Exposure depends on whether an application uses an async key resolver that can return an empty string; the record does not say how common this pattern is.
Exploitation status
CISA KEV does not list this CVE, and the record's SSVC exploitation value is none. The EPSS probability is 0.00334 with a percentile of 0.24968. No confirmed exploitation appears in the sources consulted. The record marks the issue as automatable.
Remediation and mitigation
- Upgrade fast-jwt to version 6.2.4 or later, as stated in the description.
- Review every key resolver used with fast-jwt and make sure none can return an empty string or other empty key material. Configure it to fail closed when no valid key is found.
- Confirm that tokens are accepted only with the algorithms and key types the application intends to use.
- If unexpected tokens may have been accepted, review authentication and session controls and rotate any credentials or secrets that could have been affected.
Detection guidance
- Inventory direct and transitive dependencies on fast-jwt and flag any version below 6.2.4.
- Review application logs for successful authentications or privileged actions tied to unexpected identities or token claims.
- Look for tokens that use HMAC algorithms in services that are expected to verify asymmetric signatures, since this can indicate a key-confusion or empty-key condition.
Limitations of the available information
The record has no fixed-version field entry, so the 6.2.4 fix relies on the description. The sources do not describe exploitation activity, proof-of-concept availability or the number of affected deployments. The EPSS date in the record (2026-10-13) should be verified against the source before it is relied on. The CVSS data comes from the GitHub and CNA entries in the record, and no separate NVD score is included.
Frequently asked questions
Which fast-jwt versions are affected by this CVE?
The record lists Nearform Fast-jwt versions before 6.2.4 as affected. The description states the issue is fixed in 6.2.4.
Is this CVE known to be exploited in the wild?
No. CISA KEV does not list it, and no confirmed exploitation appears in the sources consulted.
What should teams do first?
Inventory fast-jwt dependencies, upgrade to 6.2.4 or later, and make sure key resolvers never return an empty key.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.