CVE-2026-101917 is a Medium (CVSS 5.3) resource consumption flaw in PyJWT before 2.14.0. Each token with an unknown kid forces PyJWKClient to refetch the JWKS, so attacker traffic multiplies requests to your identity provider. Upgrade to PyJWT 2.14.0 or later.
What's affected
The weakness is CWE-770 (allocation of resources without limits or throttling). The record says PyJWT before 2.14.0 is affected, and the GitHub advisory lists versions up to 2.13.0 as affected and 2.14.0 as patched. Both rate it Medium or Moderate.
The advisory describes it as an incomplete fix of an earlier issue, CVE-2026-48524, which was addressed in 2.13.0 by stopping a fetch error from clearing the cache. That closed one path to amplification but did not add a rate limit, a negative cache or a minimum refresh interval for unknown key IDs.
In the affected versions, when the key ID in a token is not in the cached key set, the client refreshes the set unconditionally. The key ID is read from the token header before any signature check, so the attacker needs no valid token and no authentication. Because the failed lookup is not cached, even the same unknown key ID repeated causes a fresh fetch each time.
The effect is outbound amplification. A small stream of inbound requests becomes a larger stream of requests to the configured JWKS endpoint, which might be your own identity service or a third party provider.
How to check if you're exposed
Check the installed version.
pip show pyjwt
Anything up to 2.13.0 is affected. Check inside containers and virtual environments too, since PyJWT is a common transitive dependency. A dependency tree command helps.
pip show pyjwt | grep -i required-by
Then check whether your code uses PyJWKClient and get_signing_key_from_jwt, which is the code path in the advisory. If your service verifies tokens with a fixed key and never calls the JWKS client, the amplification path is not in use.
The free in-browser dependency scan at gold.safeguard.sh/scan can match a lockfile or manifest against known CVEs without installing anything. The Gold directory page for each CVE lists affected packages and fixes as they are published.
What to do now
- Upgrade PyJWT to 2.14.0 or later in every service and image.
- Put rate limits in front of any endpoint that verifies tokens, so that anonymous bursts are slowed before they reach your code.
- Monitor outbound requests to your JWKS endpoint for sudden increases.
- If you maintain your own wrapper around PyJWKClient, add a short negative cache for unknown key IDs.
- Rebuild container images so the fixed version is what runs.
Why it matters
Token verification sits on the unauthenticated edge of most APIs. Anything that costs the server more work than it costs the caller can be abused. Here, a refresh on every unknown key ID gives the caller a cheap way to spend the server's outbound requests.
The impact is limited to availability and load on the key endpoint, which explains the Medium score. The record does not mark the CVE as known exploited. It is a good example of a fix that needs a second pass: the first change removed one path, and this one finishes the job.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is PyJWT 2.14.0 the fixed version?
Yes for this CVE. The record and the GitHub advisory both name 2.14.0.
Do I need to be using JWKS?
The advisory describes PyJWKClient, so services that never use it are not in that code path.
Sources
Last reviewed: 18 October 2026.
