fast-jwt: Verifier cache accepts expired JWTs without iat.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| nearform | fast-jwt | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Nearform | Fast-jwt |
|
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-x937-hj6v-793p | fast-jwt: Verifier cache accepts expired JWTs without iat. |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.272% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Nearform
Nearform fast-jwt |
|
| Vendors & Products |
Nearform
Nearform fast-jwt |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.3.4, the fast-jwt createVerifier cache can continue accepting a previously valid, signed JWT after its exp time when caching is enabled and the token has exp but no iat. In src/verifier.js, cacheSet derives the exp cache deadline only when iat is present, so the cache falls back to cacheTTL, and a later cache hit returns the saved payload before verifyToken rechecks expiration. An attacker who can replay the same cached bearer token can extend access until the cache entry expires, but cannot forge a token through this issue. This issue is fixed in version 6.3.4. | |
| Title | fast-jwt: Verifier cache accepts expired JWTs without iat. | |
| Weaknesses | CWE-613 | |
| References |
| |
| Metrics |
cvssV3_1
|