PyJWT did not restrict the URI scheme used by PyJWKClient when resolving a JWKS endpoint. Because the library forwards the supplied URI directly to urllib.request.urlopen(), attackers who can influence the jku value (through a JWT header, config file, or OAuth parameter) may cause the library to attempt requests to file://, ftp:// or data: URLs. This yields server‑side request forgery against local files or remote FTP resources, and if an attacker can also write to a path that will later be served as a JWKS document, they could forge a JWT that the library would accept. The library itself does not return non‑HTTP content to the attacker, so the direct impact is limited to SSRF and the prerequisite for token forgery.

Applications built on the jpadilla:PyJWT package that use PyJWKClient before version 2.13.0 are vulnerable. Any Python project that imports PyJWT and relies on PyJWKClient with potential user‑controlled jku URI inputs is at risk.

The CVSS score of 4.2 indicates moderate severity, but the EPSS score is not available and the vulnerability is not listed in KEV, suggesting that exploitation is unlikely at present. The attack requires an attacker to influence the jku value and to target a code path where JWTs are parsed. The vulnerability alone does not allow arbitrary file reading or token forging; further application flaws such as write access to a JWKS file or lack of input validation are needed. Nonetheless, the presence of non‑HTTP schemes exposes a surface for local or remote SSRF.