CVE-2026-101918 is a Medium (CVSS 5.3) uncaught exception flaw in PyJWT from 2.0.0a1 before 2.15.0. A deeply nested JSON payload raises a RecursionError that the documented handling does not catch, which can return an HTTP 500. Upgrade to PyJWT 2.15.0 or later.
What's affected
The weakness is CWE-248 (uncaught exception). The record says PyJWT from 2.0.0a1 until 2.15.0 is affected. The GitHub advisory lists versions from 2.0.0a1 up to and including 2.14.0, with 2.15.0 as the patched version. The two are consistent.
To verify a token with a key from a JWKS endpoint, a service first has to read the token's payload to find out which key to use. PyJWT parses the payload with Python's JSON module, and the code catches only ValueError. A payload that is valid JSON but nested thousands of levels deep makes the parser raise RecursionError, which is not a ValueError.
As a result the exception escapes as a raw, undocumented type. It is not a DecodeError or any other PyJWT error class, so the error handling patterns in the project's documentation miss it. The advisory says the token needs no valid signature, and the failure happens before signature checking. An unauthenticated request can then cause an unhandled exception, which may produce an HTTP 500 response. The record also names jwt/api_jwt.py with signature verification turned off as part of the affected implementation.
How to check if you're exposed
Check the version.
pip show pyjwt
Versions from 2.0.0a1 to 2.14.0 are affected. Then look at your error handling around token decoding. If your code catches only the PyJWT exception classes, the escaped exception will reach your framework's default handler and likely become a 500 error.
Also check whether your service calls PyJWKClient.get_signing_key_from_jwt or decodes a token with signature verification turned off, since those are the paths the advisory names.
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.15.0 or later.
- In the meantime, catch broad exceptions around the pre-verification decode and treat them as an invalid token, returning a 401.
- Limit the size of the Authorization header at the proxy so very large tokens never reach the application.
- Check error logs for spikes in 500 responses from authentication endpoints.
- Rebuild images and redeploy after the upgrade.
Why it matters
Parsing untrusted input before authentication is a place where every unexpected exception matters. If the handler does not turn a failure into a clean rejection, the caller learns something about your stack or takes a worker down.
The impact here is mild, a failed request, which explains the 5.3 score. The fix is cheap, and so is the defensive pattern: a broad catch and a small header size limit. The record does not mark the CVE as known exploited.
Quick check
Which PyJWT version fixes it?
2.15.0, per the record and the GitHub advisory.
Can this crash my whole service?
The advisory describes an unhandled exception and a possible HTTP 500. A well behaved web framework isolates it to the request, but check how yours handles unexpected exceptions.
Sources
Last reviewed: 18 October 2026.
