jpadilla pyjwt up to 2.12.x Configuration File urllib.request.urlopen confused deputy

Summaryinfo

A vulnerability was found in jpadilla pyjwt up to 2.12.x. It has been rated as problematic. The affected element is the function urllib.request.urlopen of the component Configuration File Handler. The manipulation leads to confused deputy. This vulnerability is traded as CVE-2026-48522. It is possible to initiate the attack remotely. There is no exploit available. Upgrading the affected component is advised.

Detailsinfo

A vulnerability, which was classified as problematic, has been found in jpadilla pyjwt up to 2.12.x. This issue affects the function urllib.request.urlopen of the component Configuration File Handler. The manipulation with an unknown input leads to a confused deputy vulnerability. Using CWE to declare the problem leads to CWE-441. The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor. Impacted is confidentiality, integrity, and availability. The summary by CVE is:

PyJWT is a JSON Web Token implementation in Python. Prior to 2.13.0, PyJWKClient passes its uri argument directly to urllib.request.urlopen() which uses Python stdlib's default OpenerDirector registering HTTPHandler, HTTPSHandler, FTPHandler, FileHandler, and DataHandler. There is currently no documented option to restrict which schemes PyJWKClient will fetch. If an application's jku URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can cause PyJWKClient to read arbitrary local files via file:// (SSRF on local filesystem), cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface), or forge tokens that PyJWT verifies as valid. The library does not directly return non-HTTP(S) URI contents to the attacker; the chained "plant a JWKS to forge tokens" scenario described in the original report requires additional application-layer flaws (attacker write access to a filesystem path, untrusted jku derivation) that this fix does not address. This vulnerability is fixed in 2.13.0.

It is possible to read the advisory at github.com. The identification of this vulnerability is CVE-2026-48522 since 05/21/2026. The exploitation is known to be difficult. The attack may be initiated remotely. No form of authentication is needed for a successful exploitation. It demands that the victim is doing some kind of user interaction. Technical details of the vulnerability are known, but there is no available exploit.

Upgrading to version 2.13.0 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• jpadilla

Name

• pyjwt

Version

• 2.0
• 2.1
• 2.2
• 2.3
• 2.4
• 2.5
• 2.6
• 2.7
• 2.8
• 2.9
• 2.10
• 2.11
• 2.12

Website

• Product: https://github.com/jpadilla/pyjwt/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion