https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 20:18:24 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-48522 <p><strong>Affected:</strong> Alpaquita:25: py3-jwt, Alpaquita:stream: py3-jwt</p> <p><strong>Affected:</strong> Alpaquita:25: py3-jwt, Alpaquita:stream: py3-jwt</p> https://cve.radiocsirt.org/vuln/bell-cve-2026-48522 https://cve.radiocsirt.org/vuln/brew-azure-cli-cve-2026-48522 <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>&gt; [!NOTE] &gt; The library does not directly return non-HTTP(S) URI contents to the attacker; the chained &#34;plant a JWKS to forge tokens&#34; 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.</p> <p>## Summary</p> <p>PyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib&#39;s default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict which schemes PyJWKClient will fetch.</p> <p>If an application&#39;s `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:</p> <p>1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) — the file&#39;s contents are passed to `json.load`. 2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface). 3. **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.</p> <p>## Affected versions</p> <p>Tested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.</p> <p>##…</p> <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>&gt; [!NOTE] &gt; The library does not directly return non-HTTP(S) URI contents to the attacker; the chained &#34;plant a JWKS to forge tokens&#34; 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.</p> <p>## Summary</p> <p>PyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib&#39;s default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict which schemes PyJWKClient will fetch.</p> <p>If an application&#39;s `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:</p> <p>1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) — the file&#39;s contents are passed to `json.load`. 2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface). 3. **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.</p> <p>## Affected versions</p> <p>Tested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.</p> <p>##…</p> https://cve.radiocsirt.org/vuln/brew-azure-cli-cve-2026-48522 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/certfr-2026-avi-0933 https://cve.radiocsirt.org/vuln/cleanstart-2026-af67526 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: jupyterhub-k8s-hub</p> <p>Multiple security vulnerabilities affect the jupyterhub-k8s-hub package. These issues are resolved in later releases. See references for individual vulnerability details.</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: jupyterhub-k8s-hub</p> <p>Multiple security vulnerabilities affect the jupyterhub-k8s-hub package. These issues are resolved in later releases. See references for individual vulnerability details.</p> https://cve.radiocsirt.org/vuln/cleanstart-2026-af67526 https://cve.radiocsirt.org/vuln/euvd-2026-323998 EUVD-2026-323998 https://cve.radiocsirt.org/vuln/euvd-2026-323998 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48522 <p>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&#39;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&#39;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 &#34;plant a JWKS to forge tokens&#34; 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.</p> <p>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&#39;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&#39;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 &#34;plant a JWKS to forge tokens&#34; 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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48522 https://cve.radiocsirt.org/vuln/ghsa-993g-76c3-p5m4 <p><strong>Affected:</strong> PyPI: PyJWT</p> <p>&gt; [!NOTE] &gt; The library does not directly return non-HTTP(S) URI contents to the attacker; the chained &#34;plant a JWKS to forge tokens&#34; 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.</p> <p>## Summary</p> <p>PyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib&#39;s default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict which schemes PyJWKClient will fetch.</p> <p>If an application&#39;s `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:</p> <p>1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) — the file&#39;s contents are passed to `json.load`. 2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface). 3. **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.</p> <p>## Affected versions</p> <p>Tested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.</p> <p>##…</p> <p><strong>Affected:</strong> PyPI: PyJWT</p> <p>&gt; [!NOTE] &gt; The library does not directly return non-HTTP(S) URI contents to the attacker; the chained &#34;plant a JWKS to forge tokens&#34; 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.</p> <p>## Summary</p> <p>PyJWKClient passes its `uri` argument directly to `urllib.request.urlopen()` which uses Python stdlib&#39;s default `OpenerDirector` registering `HTTPHandler`, `HTTPSHandler`, `FTPHandler`, **`FileHandler`**, and `DataHandler`. There is currently no documented option to restrict which schemes PyJWKClient will fetch.</p> <p>If an application&#39;s `jku` URL ingestion path accepts attacker-influenced URLs (e.g., from JWT header, configuration file, OAuth flow parameter), the attacker can:</p> <p>1. Cause PyJWKClient to read arbitrary local files via `file://` (SSRF on local filesystem) — the file&#39;s contents are passed to `json.load`. 2. Cause PyJWKClient to attempt FTP / data-URI fetches (broader SSRF surface). 3. **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.</p> <p>## Affected versions</p> <p>Tested and reproducible on **PyJWT 2.11.0 and 2.12.1**. Likely all versions back to PyJWKClient introduction.</p> <p>##…</p> https://cve.radiocsirt.org/vuln/ghsa-993g-76c3-p5m4 https://cve.radiocsirt.org/vuln/msrc_cve-2026-48522 msrc_CVE-2026-48522 https://cve.radiocsirt.org/vuln/msrc_cve-2026-48522 https://cve.radiocsirt.org/vuln/opensuse-su-2026:11024-1 <p>python311-PyJWT-2.13.0-1.1 on GA media</p> <p>python311-PyJWT-2.13.0-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11024-1 https://cve.radiocsirt.org/vuln/pysec-2026-175 <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>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&#39;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&#39;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 &#34;plant a JWKS to forge tokens&#34; 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.</p> <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>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&#39;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&#39;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 &#34;plant a JWKS to forge tokens&#34; 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.</p> https://cve.radiocsirt.org/vuln/pysec-2026-175 https://cve.radiocsirt.org/vuln/suse-su-2026:22138-1 <p>Security update for python-PyJWT</p> <p>Security update for python-PyJWT</p> https://cve.radiocsirt.org/vuln/suse-su-2026:22138-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-48522 <p><strong>Affected:</strong> Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:25.10: pyjwt, Ubuntu:26.04:LTS: pyjwt</p> <p>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&#39;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&#39;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 &#34;plant a JWKS to forge tokens&#34; 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.</p> <p><strong>Affected:</strong> Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:25.10: pyjwt, Ubuntu:26.04:LTS: pyjwt</p> <p>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&#39;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&#39;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 &#34;plant a JWKS to forge tokens&#34; 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.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-48522