Impact Analysis

This vulnerability can impact you by allowing an attacker to perform Server-Side Request Forgery (SSRF) attacks through the PyJWKClient component. Specifically, an attacker could cause the application to read arbitrary local files or fetch data using unsupported URL schemes like file:// or ftp://.

In a more severe chained attack, if the attacker has write access to the filesystem or can influence the jku URL derivation, they could plant a malicious JWKS file. This would enable them to forge tokens that the application would accept as valid, potentially bypassing authentication or authorization controls.

However, the direct impact is limited to SSRF and requires additional application-layer flaws for token forgery to succeed.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if your application uses PyJWT versions 2.12.1 or earlier and if it uses PyJWKClient to fetch JSON Web Key Sets (JWKS) without restricting URL schemes.

You can look for usage of the jku parameter in JWT headers or configuration files that might accept attacker-influenced URLs.

To detect potential exploitation attempts on your system or network, monitor for unusual file://, ftp://, or data: scheme requests originating from your application.

Specific commands depend on your environment, but examples include:

• Use network monitoring tools like tcpdump or Wireshark to capture outgoing requests and filter for non-HTTP(S) schemes.
• Search your codebase for PyJWKClient usage and check the PyJWT version with commands like `pip show pyjwt`.
• Audit logs for suspicious access patterns or errors related to file://, ftp://, or data: URI fetches.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate mitigation step is to upgrade PyJWT to version 2.13.0 or later, where the vulnerability is fixed.

This fixed version adds an allowed_schemes parameter to PyJWKClient that restricts URL schemes to only "https" and "http", preventing SSRF via file://, ftp://, or data: schemes.

If upgrading is not immediately possible, review and sanitize any inputs that influence the jku URL to ensure they cannot be attacker-controlled or contain disallowed schemes.

Additionally, monitor and restrict filesystem write access to paths that could be targeted for planting malicious JWK Sets.

Useful 0 Not Useful 0

Executive Summary

CVE-2026-48522 is a vulnerability in the PyJWKClient component of the PyJWT Python library. Prior to version 2.13.0, PyJWKClient does not restrict the URL schemes it accepts when fetching JSON Web Key Sets (JWKS). This means it can fetch resources using schemes like file://, ftp://, and data:, in addition to HTTP/HTTPS.

If an attacker can influence the jku (JWK Set URL) parameter, for example through a JWT header or configuration, they can exploit this to perform Server-Side Request Forgery (SSRF). This could allow reading arbitrary local files or attempting other protocol fetches. Additionally, if the attacker can write to the targeted filesystem path, they could plant a malicious JWKS file and forge tokens that PyJWT would verify as valid.

The vulnerability is fixed in PyJWT version 2.13.0 by restricting allowed URL schemes to only HTTP and HTTPS.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability in PyJWT allows an attacker to exploit Server-Side Request Forgery (SSRF) and potentially forge tokens by manipulating the jku URL scheme. Such token forgery and unauthorized access could lead to unauthorized data access or manipulation.

In the context of compliance with standards like GDPR or HIPAA, this vulnerability could undermine the integrity and confidentiality of authentication tokens, potentially leading to unauthorized access to personal or sensitive data. This could result in violations of data protection requirements, including improper access controls and failure to protect data confidentiality.

However, the vulnerability requires additional application-layer flaws (such as attacker write access to filesystem paths or untrusted jku derivation) to fully exploit token forgery, meaning the risk depends on the overall application security posture.

Useful 0 Not Useful 0