CVE-2026-101917 in PyJWT
Summary
by MITRE • 09/28/2026
PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT get_signing_key_from_jwt is affected because unknown kid misses force refreshes without a negative cache or minimum refresh interval. This occurs when unauthenticated tokens repeatedly use the same unknown kid or varying kid values absent from the cached JWKS. As a result, each cache miss causes PyJWKClient to refresh the JWKS. Consequently, attacker traffic can amplify outbound requests to the configured JWKS endpoint. This issue is fixed in version 2.14.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/28/2026
The vulnerability identified in PyJWT prior to version 2.14.0 represents a significant resource exhaustion flaw rooted in the implementation of JSON Web Token (JWT) signature verification mechanisms. JWTs are widely used for securely transmitting information between parties as a JSON object, often relying on public key infrastructure where signatures are verified against keys retrieved from a JSON Web Key Set (JWKS). The specific function affected is get_signing_key_from_jwt within the PyJWKClient component. This client is responsible for fetching and caching JWKS endpoints to validate token signatures efficiently. Under normal operation, once a JWKS is fetched, it should be cached to avoid repeated network requests. However, the flaw lies in how the library handles cache misses when an unknown key identifier (kid) is encountered within an incoming JWT.
The technical core of this vulnerability involves the absence of negative caching or minimum refresh intervals for keys that are not found in the JWKS. When a token arrives with a kid value that does not match any key currently cached, the library triggers a fresh fetch from the remote JWKS endpoint to check if the new key has been added. Crucially, there is no mechanism to cache this failure state or enforce a cooldown period between successive refresh attempts for missing keys. This design oversight means that every single request containing an unknown kid results in an outbound HTTP GET request to the configured JWKS URI. In environments where JWTs are processed frequently, such as API gateways or authentication services, this behavior creates a direct path for resource amplification.
From an operational impact perspective, this flaw enables Denial of Service (DoS) attacks through both local and remote vectors. An attacker can craft malicious tokens containing arbitrary or random kid values to trigger repeated JWKS fetches. If the application processes these unauthenticated requests without rate limiting, it can exhaust server resources such as CPU cycles, memory, and network bandwidth on the backend service hosting the PyJWT instance. Furthermore, because each verification attempt generates an outbound request, this vulnerability can also be leveraged for Server-Side Request Forgery (SSRF) amplification or to expose internal infrastructure details if the JWKS endpoint is located within a private network segment that would otherwise not be accessible from the internet. The lack of authentication requirements for triggering these fetches makes exploitation straightforward and highly effective against unpatched systems.
This vulnerability aligns with CWE-787: Out-of-bounds Write in terms of resource consumption logic, though more accurately it maps to CWE-400: Uncontrolled Resource Consumption. In the context of the MITRE ATT&CK framework, this behavior facilitates T1496: Resource Hijacking and potentially T1552.007: Private Keys from Local File Systems if the JWKS fetch leads to further exploitation steps involving key extraction or interception. The attack pattern is consistent with techniques used in amplification attacks where small inputs generate disproportionately large outputs, stressing the target infrastructure.
Mitigation for this issue requires an immediate upgrade to PyJWT version 2.14.0 or later, which implements proper caching strategies including negative caches and minimum refresh intervals to prevent excessive JWKS fetches. For organizations unable to patch immediately due to dependency constraints, defensive measures should include implementing strict rate limiting on endpoints that process JWTs to throttle the frequency of verification requests. Additionally, deploying a Web Application Firewall (WAF) with rules designed to detect anomalous patterns in token payloads or high volumes of signature validation failures can help mitigate the impact by blocking malicious traffic before it reaches the application layer. Ensuring that JWKS endpoints are not exposed directly to untrusted networks and using internal proxies for key retrieval further reduces the attack surface associated with this vulnerability.