https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 18:57:02 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-48525 <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-48525 https://cve.radiocsirt.org/vuln/brew-azure-cli-cve-2026-48525 <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>&gt; [!NOTE] &gt; Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.</p> <p>When verifying detached JWS tokens using the unencoded-payload option (`&#34;b64&#34;: false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules.</p> <p>For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid.</p> <p>This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT.</p> <p>---</p> <p>## Affected Component(s)</p> <p>* `jwt/api_jws.py`</p> <p>* `PyJWS.decode()` / `PyJWS.decode_complete()` * `_load()` (parsing and Base64URL decoding)</p> <p>---</p> <p>## Root Cause (exact logic flaw)</p> <p>### What happens in the code</p> <p>In `jwt/api_jws.py`, `decode_complete()` does the following (order matters):</p> <p>* Calls `_load(jwt)` first, which decodes the token segments * Only after that, checks `header.get(&#34;b64&#34;)` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input</p> <p>This behavior is visible in `deco…</p> <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>&gt; [!NOTE] &gt; Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.</p> <p>When verifying detached JWS tokens using the unencoded-payload option (`&#34;b64&#34;: false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules.</p> <p>For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid.</p> <p>This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT.</p> <p>---</p> <p>## Affected Component(s)</p> <p>* `jwt/api_jws.py`</p> <p>* `PyJWS.decode()` / `PyJWS.decode_complete()` * `_load()` (parsing and Base64URL decoding)</p> <p>---</p> <p>## Root Cause (exact logic flaw)</p> <p>### What happens in the code</p> <p>In `jwt/api_jws.py`, `decode_complete()` does the following (order matters):</p> <p>* Calls `_load(jwt)` first, which decodes the token segments * Only after that, checks `header.get(&#34;b64&#34;)` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input</p> <p>This behavior is visible in `deco…</p> https://cve.radiocsirt.org/vuln/brew-azure-cli-cve-2026-48525 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-329304 EUVD-2026-329304 https://cve.radiocsirt.org/vuln/euvd-2026-329304 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48525 <p>PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&#34;b64&#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.</p> <p>PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&#34;b64&#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48525 https://cve.radiocsirt.org/vuln/ghsa-w7vc-732c-9m39 <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>&gt; [!NOTE] &gt; Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.</p> <p>When verifying detached JWS tokens using the unencoded-payload option (`&#34;b64&#34;: false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules.</p> <p>For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid.</p> <p>This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT.</p> <p>---</p> <p>## Affected Component(s)</p> <p>* `jwt/api_jws.py`</p> <p>* `PyJWS.decode()` / `PyJWS.decode_complete()` * `_load()` (parsing and Base64URL decoding)</p> <p>---</p> <p>## Root Cause (exact logic flaw)</p> <p>### What happens in the code</p> <p>In `jwt/api_jws.py`, `decode_complete()` does the following (order matters):</p> <p>* Calls `_load(jwt)` first, which decodes the token segments * Only after that, checks `header.get(&#34;b64&#34;)` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input</p> <p>This behavior is visible in `deco…</p> <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>&gt; [!NOTE] &gt; Practical impact depends on whether request body-size limits are enforced upstream (proxy/web-server/framework). Deployments with typical body-size caps (≤2 MB) bound the amplifier significantly; deployments accepting larger token inputs are more exposed.</p> <p>When verifying detached JWS tokens using the unencoded-payload option (`&#34;b64&#34;: false`, RFC 7797), PyJWT performs **Base64URL decoding of the compact-serialization payload segment** *before* enforcing the detached-payload rules.</p> <p>For `b64=false`, PyJWT later **discards** that decoded payload and replaces it with the caller-provided `detached_payload`. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces **CPU work + memory allocations** even if the signature is invalid.</p> <p>This creates an **unauthenticated DoS** vector against any endpoint that verifies detached JWS using PyJWT.</p> <p>---</p> <p>## Affected Component(s)</p> <p>* `jwt/api_jws.py`</p> <p>* `PyJWS.decode()` / `PyJWS.decode_complete()` * `_load()` (parsing and Base64URL decoding)</p> <p>---</p> <p>## Root Cause (exact logic flaw)</p> <p>### What happens in the code</p> <p>In `jwt/api_jws.py`, `decode_complete()` does the following (order matters):</p> <p>* Calls `_load(jwt)` first, which decodes the token segments * Only after that, checks `header.get(&#34;b64&#34;)` and if `False`, it replaces `payload = detached_payload` and rebuilds the signing input</p> <p>This behavior is visible in `deco…</p> https://cve.radiocsirt.org/vuln/ghsa-w7vc-732c-9m39 https://cve.radiocsirt.org/vuln/msrc_cve-2026-48525 msrc_CVE-2026-48525 https://cve.radiocsirt.org/vuln/msrc_cve-2026-48525 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-178 <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>PyJWT is a JSON Web Token implementation in Python. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&#34;b64&#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. 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. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&#34;b64&#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.</p> https://cve.radiocsirt.org/vuln/pysec-2026-178 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-48525 <p><strong>Affected:</strong> 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. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&#34;b64&#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.</p> <p><strong>Affected:</strong> 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. From 2.8.0 to 2.12.1, when verifying detached JWS tokens using the unencoded-payload option (&#34;b64&#34;: false, RFC 7797), PyJWT performs Base64URL decoding of the compact-serialization payload segment before enforcing the detached-payload rules. For b64=false, PyJWT later discards that decoded payload and replaces it with the caller-provided detached_payload. In practice, this turns the middle segment into an attacker-controlled “work amplifier”: a remote client can supply an arbitrarily large Base64URL payload segment that forces CPU work + memory allocations even if the signature is invalid. This creates an unauthenticated DoS vector against any endpoint that verifies detached JWS using PyJWT. This vulnerability is fixed in 2.13.0.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-48525