Affected: Homebrew: bbot

## Affected Package

- **Package**: PyJWT (`pyjwt` on PyPI) - **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&source=gmail&ust=1781794518474000&sa=E - **Affected version**: 2.13.0 - **Vulnerability class**: Algorithm confusion / patch bypass

---

## Root Cause

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.

The guard uses `bytes.lstrip()` before calling `startswith(b"{")`:

```python stripped = key_bytes.lstrip() # strips ASCII whitespace only if stripped.startswith(b"{"): # JWK detection ... raise InvalidKeyError("The specified key is an asymmetric key...") ```

`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"{")` 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.

---

## PoC Sketch (pseudocode — not a weaponized payload)

```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: # -…

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.

Affected: PyPI: PyJWT

## Affected Package

- **Package**: PyJWT (`pyjwt` on PyPI) - **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&source=gmail&ust=1781794518474000&sa=E - **Affected version**: 2.13.0 - **Vulnerability class**: Algorithm confusion / patch bypass

---

## Root Cause

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.

The guard uses `bytes.lstrip()` before calling `startswith(b"{")`:

```python stripped = key_bytes.lstrip() # strips ASCII whitespace only if stripped.startswith(b"{"): # JWK detection ... raise InvalidKeyError("The specified key is an asymmetric key...") ```

`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"{")` 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.

---

## PoC Sketch (pseudocode — not a weaponized payload)

```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: # -…

Affected: 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

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.