https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 04:34:22 +0000 https://cve.radiocsirt.org/vuln/bell-cve-2026-48523 <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-48523 https://cve.radiocsirt.org/vuln/brew-azure-cli-cve-2026-48523 <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>&gt; [!NOTE] &gt; Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.</p> <p>PyJWT `2.9.0` through `2.12.1` allows a verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()` are called with a `PyJWK` key. The token header `alg` is checked against the caller-supplied `algorithms` allow-list, but signature verification is performed with the algorithm bound to the `PyJWK` object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented `PyJWKClient.get_signing_key_from_jwt(...)` flow.</p> <p>### Summary</p> <p>PyJWT&#39;s `PyJWK` verification path allows a verifier-side algorithm allow-list bypass.</p> <p>In affected versions, when a JWT is decoded with a `PyJWK` object, PyJWT verifies that the header `alg` string is present in the caller&#39;s `algorithms=[...]` list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the `PyJWK` object.</p> <p>This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header a…</p> <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>&gt; [!NOTE] &gt; Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.</p> <p>PyJWT `2.9.0` through `2.12.1` allows a verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()` are called with a `PyJWK` key. The token header `alg` is checked against the caller-supplied `algorithms` allow-list, but signature verification is performed with the algorithm bound to the `PyJWK` object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented `PyJWKClient.get_signing_key_from_jwt(...)` flow.</p> <p>### Summary</p> <p>PyJWT&#39;s `PyJWK` verification path allows a verifier-side algorithm allow-list bypass.</p> <p>In affected versions, when a JWT is decoded with a `PyJWK` object, PyJWT verifies that the header `alg` string is present in the caller&#39;s `algorithms=[...]` list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the `PyJWK` object.</p> <p>This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header a…</p> https://cve.radiocsirt.org/vuln/brew-azure-cli-cve-2026-48523 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-322482 EUVD-2026-322482 https://cve.radiocsirt.org/vuln/euvd-2026-322482 https://cve.radiocsirt.org/vuln/fkie_cve-2026-48523 <p>PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.</p> <p>PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-48523 https://cve.radiocsirt.org/vuln/ghsa-jq35-7prp-9v3f <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>&gt; [!NOTE] &gt; Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.</p> <p>PyJWT `2.9.0` through `2.12.1` allows a verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()` are called with a `PyJWK` key. The token header `alg` is checked against the caller-supplied `algorithms` allow-list, but signature verification is performed with the algorithm bound to the `PyJWK` object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented `PyJWKClient.get_signing_key_from_jwt(...)` flow.</p> <p>### Summary</p> <p>PyJWT&#39;s `PyJWK` verification path allows a verifier-side algorithm allow-list bypass.</p> <p>In affected versions, when a JWT is decoded with a `PyJWK` object, PyJWT verifies that the header `alg` string is present in the caller&#39;s `algorithms=[...]` list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the `PyJWK` object.</p> <p>This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header a…</p> <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>&gt; [!NOTE] &gt; Scored assuming a deployment where algorithm policy functions as an authentication/authorization boundary. In deployments where the algorithm policy enforces crypto agility only, the practical confidentiality impact is lower and the issue is closer to an integrity-of-policy-enforcement bug.</p> <p>PyJWT `2.9.0` through `2.12.1` allows a verifier-side algorithm allow-list bypass when `jwt.decode()` or `jwt.decode_complete()` are called with a `PyJWK` key. The token header `alg` is checked against the caller-supplied `algorithms` allow-list, but signature verification is performed with the algorithm bound to the `PyJWK` object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented `PyJWKClient.get_signing_key_from_jwt(...)` flow.</p> <p>### Summary</p> <p>PyJWT&#39;s `PyJWK` verification path allows a verifier-side algorithm allow-list bypass.</p> <p>In affected versions, when a JWT is decoded with a `PyJWK` object, PyJWT verifies that the header `alg` string is present in the caller&#39;s `algorithms=[...]` list, but it does not actually use the header algorithm to verify the signature. Instead, it verifies with the algorithm already bound to the `PyJWK` object.</p> <p>This lets an attacker who controls a registered JWK/JWKS private key sign with a disallowed algorithm and have the token accepted as long as the JWT header a…</p> https://cve.radiocsirt.org/vuln/ghsa-jq35-7prp-9v3f 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-176 <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. 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.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.</p> https://cve.radiocsirt.org/vuln/pysec-2026-176 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-48523 <p><strong>Affected:</strong> Ubuntu:25.10: pyjwt, Ubuntu:26.04:LTS: pyjwt</p> <p>PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.</p> <p><strong>Affected:</strong> Ubuntu:25.10: pyjwt, Ubuntu:26.04:LTS: pyjwt</p> <p>PyJWT is a JSON Web Token implementation in Python. From 2.9.0 to 2.12.1, there is a verifier-side algorithm allow-list bypass when jwt.decode() or jwt.decode_complete() are called with a PyJWK key. The token header alg is checked against the caller-supplied algorithms allow-list, but signature verification is performed with the algorithm bound to the PyJWK object instead of the header algorithm. An attacker who controls a registered JWK/JWKS private key can sign with a disallowed algorithm, advertise an allowed algorithm in the JWT header, and still be accepted. The issue affects the documented PyJWKClient.get_signing_key_from_jwt(...) flow. This vulnerability is fixed in 2.13.0.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-48523