https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 17:10:52 +0000 https://vulnerability.circl.lu/vuln/brew-azure-cli-cve-2026-102273 <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>### Summary</p> <p>PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level `kty` member.</p> <p>### Impact</p> <p>An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:</p> <p>* allows both HS* and asymmetric algorithms; * passes raw public JWK/JWKS JSON as `key=`; and * uses that same value as the HMAC secret.</p> <p>This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT&#39;s algorithm-selection guidance.</p> <p>### Fix status</p> <p>The fix is on `master` in commit `801cd12` (`fix: reject public JWK container HMAC keys`). `HMACAlgorithm.prepare_key` now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.</p> <p>The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were…</p> <p><strong>Affected:</strong> Homebrew: azure-cli</p> <p>### Summary</p> <p>PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level `kty` member.</p> <p>### Impact</p> <p>An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:</p> <p>* allows both HS* and asymmetric algorithms; * passes raw public JWK/JWKS JSON as `key=`; and * uses that same value as the HMAC secret.</p> <p>This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT&#39;s algorithm-selection guidance.</p> <p>### Fix status</p> <p>The fix is on `master` in commit `801cd12` (`fix: reject public JWK container HMAC keys`). `HMACAlgorithm.prepare_key` now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.</p> <p>The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were…</p> https://vulnerability.circl.lu/vuln/brew-azure-cli-cve-2026-102273 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1249 certfr-2026-avi-1249 https://vulnerability.circl.lu/vuln/certfr-2026-avi-1249 https://vulnerability.circl.lu/vuln/cleanstart-2026-fp98505 <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>CVE-2026-102273 affects multiple packages. PyJWT is a Python implementation of JSON Web Token standards. See references for individual vulnerability details.</p> <p><strong>Affected:</strong> CleanStart: airflow-3</p> <p>CVE-2026-102273 affects multiple packages. PyJWT is a Python implementation of JSON Web Token standards. See references for individual vulnerability details.</p> https://vulnerability.circl.lu/vuln/cleanstart-2026-fp98505 https://vulnerability.circl.lu/vuln/fkie_cve-2026-102273 <p>PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.</p> <p>PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-102273 https://vulnerability.circl.lu/vuln/ghsa-w2cx-738m-mc7w <p><strong>Affected:</strong> PyPI: PyJWT</p> <p>### Summary</p> <p>PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level `kty` member.</p> <p>### Impact</p> <p>An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:</p> <p>* allows both HS* and asymmetric algorithms; * passes raw public JWK/JWKS JSON as `key=`; and * uses that same value as the HMAC secret.</p> <p>This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT&#39;s algorithm-selection guidance.</p> <p>### Fix status</p> <p>The fix is on `master` in commit `801cd12` (`fix: reject public JWK container HMAC keys`). `HMACAlgorithm.prepare_key` now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.</p> <p>The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were…</p> <p><strong>Affected:</strong> PyPI: PyJWT</p> <p>### Summary</p> <p>PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level `kty` member.</p> <p>### Impact</p> <p>An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:</p> <p>* allows both HS* and asymmetric algorithms; * passes raw public JWK/JWKS JSON as `key=`; and * uses that same value as the HMAC secret.</p> <p>This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT&#39;s algorithm-selection guidance.</p> <p>### Fix status</p> <p>The fix is on `master` in commit `801cd12` (`fix: reject public JWK container HMAC keys`). `HMACAlgorithm.prepare_key` now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.</p> <p>The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were…</p> https://vulnerability.circl.lu/vuln/ghsa-w2cx-738m-mc7w https://vulnerability.circl.lu/vuln/msrc_cve-2026-102273 msrc_CVE-2026-102273 https://vulnerability.circl.lu/vuln/msrc_cve-2026-102273 https://vulnerability.circl.lu/vuln/pysec-2026-4151 <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>### Summary</p> <p>PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level `kty` member.</p> <p>### Impact</p> <p>An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:</p> <p>* allows both HS* and asymmetric algorithms; * passes raw public JWK/JWKS JSON as `key=`; and * uses that same value as the HMAC secret.</p> <p>This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT&#39;s algorithm-selection guidance.</p> <p>### Fix status</p> <p>The fix is on `master` in commit `801cd12` (`fix: reject public JWK container HMAC keys`). `HMACAlgorithm.prepare_key` now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.</p> <p>The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were…</p> <p><strong>Affected:</strong> PyPI: pyjwt</p> <p>### Summary</p> <p>PyJWT 2.13.0 contains an incomplete defense against algorithm confusion when an application mixes symmetric and asymmetric algorithms in one verification path. A public RSA, EC, or OKP JWK can be accepted as an HMAC secret when it is wrapped in a JWKS object, nested in an array, or represented in another container form that does not expose a top-level `kty` member.</p> <p>### Impact</p> <p>An attacker who knows the public key material can forge HS256/HS384/HS512 tokens if the application simultaneously:</p> <p>* allows both HS* and asymmetric algorithms; * passes raw public JWK/JWKS JSON as `key=`; and * uses that same value as the HMAC secret.</p> <p>This can allow forged JWT claims in affected application configurations. The issue does not affect applications that keep symmetric and asymmetric verification paths separate and follow PyJWT&#39;s algorithm-selection guidance.</p> <p>### Fix status</p> <p>The fix is on `master` in commit `801cd12` (`fix: reject public JWK container HMAC keys`). `HMACAlgorithm.prepare_key` now rejects public JWK members found in objects, arrays, nested containers, BOM/UTF variants, and recursion-limit inputs. It also recognizes escaped JSON member names without treating ordinary string values as JWKs. Ordinary JSON secrets remain accepted byte-for-byte.</p> <p>The change was tested with focused regression tests and the full local tox matrix. Available Python 3.9, 3.12, and 3.13 crypto/no-crypto suites, mypy, package metadata, and coverage passed; unavailable interpreters were…</p> https://vulnerability.circl.lu/vuln/pysec-2026-4151 https://vulnerability.circl.lu/vuln/rhsa-2026:79378 <p>fflate: fflate: Denial of Service via crafted ZIP archives sqlparse: sqlparse: Denial of Service via inefficient SQL parsing anyio: AnyIO: TLS certificate spoofing via improper internationalized domain name encoding aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade gitpython: GitPython: Remote Code Execution via malicious Git hooks gitpython: GitPython: Arbitrary File Overwrite via `git read-tree` option injection gitpython: GitPython: Arbitrary command execution via crafted kwargs gitpython: GitPython: Arbitrary code execution via config-name injection gitpython: GitPython: Arbitrary file creation via path traversal in .gitmodules submodule names gitpython: GitPython before 3.1.59 Remote Code Execution via Config Injection tornado: Tornado: Denial of Service via memory amplification in multipart parsing authlib: authlib: Signature verification bypass via deserialize_json pyjwt: pyjwt: Token forgery via acceptance of public JWK containers as HMAC secrets</p> <p>fflate: fflate: Denial of Service via crafted ZIP archives sqlparse: sqlparse: Denial of Service via inefficient SQL parsing anyio: AnyIO: TLS certificate spoofing via improper internationalized domain name encoding aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade gitpython: GitPython: Remote Code Execution via malicious Git hooks gitpython: GitPython: Arbitrary File Overwrite via `git read-tree` option injection gitpython: GitPython: Arbitrary command execution via crafted kwargs gitpython: GitPython: Arbitrary code execution via config-name injection gitpython: GitPython: Arbitrary file creation via path traversal in .gitmodules submodule names gitpython: GitPython before 3.1.59 Remote Code Execution via Config Injection tornado: Tornado: Denial of Service via memory amplification in multipart parsing authlib: authlib: Signature verification bypass via deserialize_json pyjwt: pyjwt: Token forgery via acceptance of public JWK containers as HMAC secrets</p> https://vulnerability.circl.lu/vuln/rhsa-2026:79378 https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-102273 <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: pyjwt, Ubuntu:Pro:18.04:LTS: pyjwt, Ubuntu:Pro:20.04:LTS: pyjwt, Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:26.04:LTS: pyjwt</p> <p>PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.</p> <p><strong>Affected:</strong> Ubuntu:Pro:16.04:LTS: pyjwt, Ubuntu:Pro:18.04:LTS: pyjwt, Ubuntu:Pro:20.04:LTS: pyjwt, Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:26.04:LTS: pyjwt</p> <p>PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because HMAC key guard only recognizes top-level public JWK forms and misses container representations. This occurs when an application allows HMAC and asymmetric algorithms and passes a public JWK container as the raw key. As a result, public asymmetric key material is accepted as the HMAC secret. Consequently, an attacker who knows the public key can forge a token with arbitrary authenticated claims. This issue is fixed in version 2.14.0.</p> https://vulnerability.circl.lu/vuln/ubuntu-cve-2026-102273