PyJWT CVE-2026-48522

Exploitation requires the application to use PyJWKClient (not merely PyJWT's core token API) and to supply PyJWKClient with a URI that is at least partially influenced by attacker-controlled input - specifically from the JWT jku header claim, an OAuth flow parameter, or an externally writable configuration file. Applications that instantiate PyJWKClient with a developer-hardcoded JWKS URL are not vulnerable to this attack path. The CVSS vector AC:H confirms that multiple conditions must align for exploitation, and UI:R confirms that a user action (such as initiating a token verification request) must occur before the malicious URI is fetched. The token-forgery variant described in the advisory additionally requires attacker write access to a local filesystem path accessible via the file:// URI and an application-layer flaw in jku derivation logic - neither of which is addressed by the PyJWT 2.13.0 fix alone. What limits exploitation most practically: the jku URI must be attacker-influenced (uncommon in hardened deployments), and direct content exfiltration is not confirmed without further application-layer weaknesses.

CVSS 4.2 (Medium) with vector AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N reflects a scenario where exploitation is network-reachable but requires high complexity and user interaction before PyJWKClient is invoked with the attacker-controlled URI. The low confidentiality and integrity impact scores align with the description's caveat that the library does not directly return file contents to the attacker - full token forgery requires additional application-layer flaws (attacker write access to a local path, untrusted jku derivation logic). No EPSS score was provided in the input data; one cannot be inferred. No CISA KEV listing and no publicly available exploit code are identified at time of analysis. SSRF vulnerabilities targeting JWT validation libraries have historically seen targeted exploitation in API-heavy cloud environments, but the multiple preconditions here (attacker-controlled jku, AC:H, UI:R) materially reduce the realistic threat surface compared to simpler SSRF classes. The primary risk is to applications that dynamically resolve jku values from incoming JWTs without a hardcoded or allow-listed JWKS endpoint - a pattern common in multi-tenant SaaS or federated identity flows. CVSS AC:H and UI:R are the most significant limiting signals; this is not a broadly automatable vulnerability against default configurations.

An attacker targeting a multi-tenant API that dynamically resolves the jku claim from incoming JWT headers crafts a token with a jku value of file:///etc/passwd or an FTP URI pointing to an attacker-controlled server. When a legitimate user triggers a token-validation flow, PyJWKClient fetches the attacker-supplied URI via urllib; depending on error-handling in the application, the attacker may observe timing differences, error messages, or DNS callbacks that confirm internal resource existence or leak partial file content. No public proof-of-concept exploit is identified at time of analysis, but the attack primitive is well-understood in SSRF research.