Vulnerability in fast-jwt (CVE-2026-107719)
Summary
Vulnerability in fast-jwt (CVE-2026-107719). Risk of unauthorized operations or information disclosure. Exploitable via cacheSet. Mitigation: upgrade to 6.3.4 or later.
Original description
The description as published by the source.
Summary
cacheSet only derives its exp cache deadline inside hasIat (src/verifier.js:127-140). JWT iat is optional. For a valid token with exp but no iat, cacheSet substitutes clockTimestamp + clockTolerance + cacheTTL (src/verifier.js:142-146). Later, the cache path returns the saved payload before decoding or invoking verifyToken (src/verifier.js:372-388). Since expiration validation is in verifyToken, the expired token remains accepted until the cache deadline.
Details
The bug is an expiration-check bypass caused by caching.
Normally, verification works like this:
- Verify signature.
- Check exp against the current time.
- Return the JWT claims.
With caching enabled, fast-jwt saves successful verification results so it can avoid repeating crypto work for the same token.
The intended invariant is:
A cached token must stop being accepted at the same time as a non-cached token.
But the cache computes its expiration incorrectly.
In fast-jwt/src/verifier.js:127, the code first checks whether the payload has an iat (“issued at”) claim:
const hasIat = payload && typeof payload.iat === 'number'
if (hasIat) {
if (!ignoreExpiration && typeof payload.exp === 'number') {
cacheValue[2] = payload.exp * 1000 + clockTolerance
}
}
That means exp is considered only when iat exists.
However, iat is optional in JWT. A perfectly valid JWT may contain:
{
"sub": "alice",
"exp": 1700000001
}
w…
Source: GitHub Security Advisories (Global) NVD GitHub Advisory
Auto-generated summary
Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.
A vulnerability tracked as CVE-2026-107719 has been found in fast-jwt.
Attackers can target a specific entry point like cacheSet over the network to misuse the product.
Risk of unauthorized operations or information disclosure. CVSS score: 4.2/10.
What to do: upgrade fast-jwt to 6.3.4 or later.
If unsure, ask your IT team or search "fast-jwt CVE-2026-107719" on the vendor's site.
CVE-2026-107719 (fast-jwt) — CWE-613 / CVSS v3 4.2
Attack vector: remote (network-reachable) / no user interaction
Attack surface: cacheSet / exp / hasIat / iat
Patched: 6.3.4 — apply immediately
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.
A vulnerability (CWE-613) exists in fast-jwt. Attackers reach the vulnerable code path via cacheSet.
Check the vendor advisory for the affected versions of fast-jwt. Attack surface: cacheSet / exp / hasIat / iat.
Severity: Medium (CVSS 4.2/10). Risk of unauthorized operations or information disclosure.
Update to 6.3.4.
Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.
Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Run grep -r 'fast-jwt' . against your dependency files (package-lock.json, requirements.txt, go.sum) to find affected services.
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1Identify exposure identify
grep -r 'fast-jwt' . | grep -v node_modulesリポジトリと本番環境の依存ファイル (package-lock.json / requirements.txt / go.sum / Gemfile.lock 等) で
fast-jwtを grep し、稼働しているサービス・バージョンを把握する。 -
2Apply patch patch
Upgrade fast-jwt to 6.3.4ステージング環境で 6.3.4 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスを含めること。
-
3Post-deployment verification verify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。
Affected packages
References
- package github.com
- web github.com
- web github.com
- web github.com
- web github.com