<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Wed, 30 Sep 2026 23:12:07 +0000</lastBuildDate>
    <item>
      <title>BREW-bbot-CVE-2026-102272 — PyJWT BOM Bypass</title>
      <link>https://db.gcve.eu/vuln/brew-bbot-cve-2026-102272</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: bbot&lt;/p&gt;
&lt;p&gt;## Affected Package&lt;/p&gt;
&lt;p&gt;- **Package**: PyJWT (`pyjwt` on PyPI)
- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&amp;amp;source=gmail&amp;amp;ust=1781794518474000&amp;amp;sa=E
- **Affected version**: 2.13.0
- **Vulnerability class**: Algorithm confusion / patch bypass&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 introduced a guard in `HMACAlgorithm.prepare_key()` (file `jwt/algorithms.py`, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.&lt;/p&gt;
&lt;p&gt;The guard uses `bytes.lstrip()` before calling `startswith(b&amp;#34;{&amp;#34;)`:&lt;/p&gt;
&lt;p&gt;```python
stripped = key_bytes.lstrip() # strips ASCII whitespace only
if stripped.startswith(b&amp;#34;{&amp;#34;): # JWK detection
 ...
 raise InvalidKeyError(&amp;#34;The specified key is an asymmetric key...&amp;#34;)
```&lt;/p&gt;
&lt;p&gt;`bytes.lstrip()` with no argument removes only bytes in the ASCII whitespace set (`\x20 \t \n \r \x0b \x0c`). A UTF-8 BOM prefix (`\xef\xbb\xbf`) is not stripped, so `stripped.startswith(b&amp;#34;{&amp;#34;)` returns `False` for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## PoC Sketch (pseudocode — not a weaponized payload)&lt;/p&gt;
&lt;p&gt;```python
# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)
# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.
# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.
# 3. Attacker submits the forged token to a verifier that:
# -…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Homebrew: bbot&lt;/p&gt;
&lt;p&gt;## Affected Package&lt;/p&gt;
&lt;p&gt;- **Package**: PyJWT (`pyjwt` on PyPI)
- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&amp;amp;source=gmail&amp;amp;ust=1781794518474000&amp;amp;sa=E
- **Affected version**: 2.13.0
- **Vulnerability class**: Algorithm confusion / patch bypass&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 introduced a guard in `HMACAlgorithm.prepare_key()` (file `jwt/algorithms.py`, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.&lt;/p&gt;
&lt;p&gt;The guard uses `bytes.lstrip()` before calling `startswith(b&amp;#34;{&amp;#34;)`:&lt;/p&gt;
&lt;p&gt;```python
stripped = key_bytes.lstrip() # strips ASCII whitespace only
if stripped.startswith(b&amp;#34;{&amp;#34;): # JWK detection
 ...
 raise InvalidKeyError(&amp;#34;The specified key is an asymmetric key...&amp;#34;)
```&lt;/p&gt;
&lt;p&gt;`bytes.lstrip()` with no argument removes only bytes in the ASCII whitespace set (`\x20 \t \n \r \x0b \x0c`). A UTF-8 BOM prefix (`\xef\xbb\xbf`) is not stripped, so `stripped.startswith(b&amp;#34;{&amp;#34;)` returns `False` for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## PoC Sketch (pseudocode — not a weaponized payload)&lt;/p&gt;
&lt;p&gt;```python
# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)
# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.
# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.
# 3. Attacker submits the forged token to a verifier that:
# -…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/brew-bbot-cve-2026-102272</guid>
    </item>
    <item>
      <title>fkie_cve-2026-102272</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-102272</link>
      <description>&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-102272</guid>
    </item>
    <item>
      <title>GHSA-r6x4-923q-g947 — PyJWT BOM Bypass</title>
      <link>https://db.gcve.eu/vuln/ghsa-r6x4-923q-g947</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;## Affected Package&lt;/p&gt;
&lt;p&gt;- **Package**: PyJWT (`pyjwt` on PyPI)
- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&amp;amp;source=gmail&amp;amp;ust=1781794518474000&amp;amp;sa=E
- **Affected version**: 2.13.0
- **Vulnerability class**: Algorithm confusion / patch bypass&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 introduced a guard in `HMACAlgorithm.prepare_key()` (file `jwt/algorithms.py`, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.&lt;/p&gt;
&lt;p&gt;The guard uses `bytes.lstrip()` before calling `startswith(b&amp;#34;{&amp;#34;)`:&lt;/p&gt;
&lt;p&gt;```python
stripped = key_bytes.lstrip() # strips ASCII whitespace only
if stripped.startswith(b&amp;#34;{&amp;#34;): # JWK detection
 ...
 raise InvalidKeyError(&amp;#34;The specified key is an asymmetric key...&amp;#34;)
```&lt;/p&gt;
&lt;p&gt;`bytes.lstrip()` with no argument removes only bytes in the ASCII whitespace set (`\x20 \t \n \r \x0b \x0c`). A UTF-8 BOM prefix (`\xef\xbb\xbf`) is not stripped, so `stripped.startswith(b&amp;#34;{&amp;#34;)` returns `False` for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## PoC Sketch (pseudocode — not a weaponized payload)&lt;/p&gt;
&lt;p&gt;```python
# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)
# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.
# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.
# 3. Attacker submits the forged token to a verifier that:
# -…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; PyPI: PyJWT&lt;/p&gt;
&lt;p&gt;## Affected Package&lt;/p&gt;
&lt;p&gt;- **Package**: PyJWT (`pyjwt` on PyPI)
- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&amp;amp;source=gmail&amp;amp;ust=1781794518474000&amp;amp;sa=E
- **Affected version**: 2.13.0
- **Vulnerability class**: Algorithm confusion / patch bypass&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## Root Cause&lt;/p&gt;
&lt;p&gt;PyJWT 2.13.0 introduced a guard in `HMACAlgorithm.prepare_key()` (file `jwt/algorithms.py`, approximately line 344) to prevent RSA public key material from being used as an HMAC secret — the root cause of CVE-2026-48526.&lt;/p&gt;
&lt;p&gt;The guard uses `bytes.lstrip()` before calling `startswith(b&amp;#34;{&amp;#34;)`:&lt;/p&gt;
&lt;p&gt;```python
stripped = key_bytes.lstrip() # strips ASCII whitespace only
if stripped.startswith(b&amp;#34;{&amp;#34;): # JWK detection
 ...
 raise InvalidKeyError(&amp;#34;The specified key is an asymmetric key...&amp;#34;)
```&lt;/p&gt;
&lt;p&gt;`bytes.lstrip()` with no argument removes only bytes in the ASCII whitespace set (`\x20 \t \n \r \x0b \x0c`). A UTF-8 BOM prefix (`\xef\xbb\xbf`) is not stripped, so `stripped.startswith(b&amp;#34;{&amp;#34;)` returns `False` for any BOM-prefixed JWK JSON. The JWK detection block is never entered, and the RSA public key bytes are silently accepted as the HMAC-SHA256 secret.&lt;/p&gt;
&lt;p&gt;---&lt;/p&gt;
&lt;p&gt;## PoC Sketch (pseudocode — not a weaponized payload)&lt;/p&gt;
&lt;p&gt;```python
# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)
# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.
# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.
# 3. Attacker submits the forged token to a verifier that:
# -…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-r6x4-923q-g947</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-102272</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-102272</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;PyJWT is a Python implementation of JSON Web Token standards. From 2.13.0 until 2.14.0, HMACAlgorithm.prepare_key in jwt/algorithms.py is affected because raw-JWK detector does not normalize accepted Unicode byte-order marks before checking for JSON. This occurs when a public JWK is prefixed with a UTF-8 BOM and used in a mixed-algorithm verification path. As a result, public JWK bypasses asymmetric-key detection and becomes the HMAC secret. Consequently, an attacker who knows the public key can forge authenticated tokens. This issue is fixed in version 2.14.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-102272</guid>
    </item>
  </channel>
</rss>
