BREW-DVC-CVE-2026-102272 (GHSA-R6X4-923Q-G947)
Vulnerability from osv_homebrew – Published: 2026-09-30 10:24 – Updated: 2026-09-30 10:24 – Source websiteAffected Package
- Package: PyJWT (
pyjwton 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"{"):
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)
# 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:
# - accepts algorithms=["HS256", "RS256"]
# - holds the same RSA public key as raw bytes (BOM-prefixed key file)
# 4. PyJWT 2.13.0 accepts the token because the BOM causes the JWK
# detection check to be skipped — the RSA JWK bytes become a valid HMAC key.
# Result: arbitrary claims (role, sub, etc.) accepted by the verifier.
Impact
An unauthenticated network attacker who knows the target application's RSA public key — which is public by design and obtainable from a JWKS endpoint or certificate — can forge JWT tokens containing arbitrary claims and have them accepted by a PyJWT 2.13.0 verifier configured with a mixed algorithm set (algorithms=["HS256", "RS256"] or equivalent). The resulting impact
is complete authentication and authorization bypass (C:H/I:H). Attack Complexity is High (AC:H) because the attacker must obtain the RSA public key and the verifier must use a mixed-algorithm configuration; no authentication is required (PR:N). This is a patch bypass: users who upgraded to 2.13.0 specifically to remediate CVE-2026-48526 remain vulnerable.
Suggested Fix
Option A (minimal): Replace lstrip() with an explicit strip of known
BOM prefixes before the JSON detection check:
# Strip common BOM prefixes in addition to ASCII whitespace
BOM_PREFIXES = (b"\xef\xbb\xbf", b"\xff\xfe", b"\xfe\xff")
stripped = key_bytes
for bom in BOM_PREFIXES:
if stripped.startswith(bom):
stripped = stripped[len(bom):]
break
stripped = stripped.lstrip()
Option B (more robust): Use json.loads() as the detection mechanism
instead of a byte-prefix check, so encoding variants and whitespace are
handled by the JSON parser:
try:
test_obj = json.loads(key_bytes.strip())
if isinstance(test_obj, dict) and "kty" in test_obj:
raise InvalidKeyError("The specified key is an asymmetric key...")
except (ValueError, UnicodeDecodeError):
pass
Option B is preferred because it is resilient to any future encoding variant.
Maintainer update — 2026-09-09
We reproduced the reported algorithm-confusion path on PyJWT 2.13.0. When an application passes a raw public RSA JWK as the key and allows both an asymmetric and HMAC algorithm, a forged HS256 token signed with the known public JWK bytes is accepted when the JWK is represented in encodings accepted by Python's JSON decoder. The normal raw-JWK, asymmetric-only, and algorithm-bound PyJWK controls reject the token. This is an application configuration precondition, but the bypass is in PyJWT's own raw-JWK validation guard and is in scope under the PyJWT security policy.
The fix is committed as 180783930de91876bc0d601f826a1f2956057291. HMACAlgorithm.prepare_key() now checks parsed JSON objects for kty across accepted UTF-8/16/32 representations, preserves non-JWK HMAC key bytes, and conservatively rejects deeply nested JSON objects even when parsing reaches the recursion guard. Regression coverage includes BOM and BOM-less encodings, deep non-JWK keys, deep JWK objects, and unpaired-surrogate cases.
The full suite passes with 391 tests and 4 intentional cryptography-environment skips. A fresh Astra/max independent review accepted commit 180783930de91876bc0d601f826a1f2956057291. It independently confirmed encoding/BOM handling, recursion and surrogate behavior, preservation of non-object key compatibility, and the reported test results.
The fix has not been released. The advisory remains High with its existing CVSS 3.1 score of 7.4, and the patched version remains unset pending release planning.
Classification update — 2026-09-10
We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.
Maintainer update — 2026-09-11
The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "pyjwt",
"resource_purl": "pkg:pypi/pyjwt@2.13.0",
"upstream_fixed_in": "2.14.0"
},
"package": {
"ecosystem": "Homebrew",
"name": "dvc",
"purl": "pkg:brew/dvc"
},
"ranges": [
{
"events": [
{
"introduced": "3.67.1_5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/pyjwt@2.13.0",
"name": "pyjwt",
"resource": "pyjwt",
"strategy": "registry",
"subject_version": "2.13.0"
}
]
},
"details": "## Affected Package\n\n- **Package**: PyJWT (`pyjwt` on PyPI)\n- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt\u0026source=gmail\u0026ust=1781794518474000\u0026sa=E\n- **Affected version**: 2.13.0\n- **Vulnerability class**: Algorithm confusion / patch bypass\n\n---\n\n## Root Cause\n\nPyJWT 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 \u2014 the root cause of CVE-2026-48526.\n\nThe guard uses `bytes.lstrip()` before calling `startswith(b\"{\")`:\n\n```python\nstripped = key_bytes.lstrip() # strips ASCII whitespace only\nif stripped.startswith(b\"{\"): # JWK detection\n ...\n raise InvalidKeyError(\"The specified key is an asymmetric key...\")\n```\n\n`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.\n\n---\n\n## PoC Sketch (pseudocode \u2014 not a weaponized payload)\n\n```python\n# 1. Attacker obtains RSA public key JWK (e.g., from /jwks.json endpoint)\n# and prepends a UTF-8 BOM byte sequence before the JSON opening brace.\n# 2. Attacker signs a JWT using HS256, with the BOM-prefixed JWK as the secret.\n# 3. Attacker submits the forged token to a verifier that:\n# - accepts algorithms=[\"HS256\", \"RS256\"]\n# - holds the same RSA public key as raw bytes (BOM-prefixed key file)\n# 4. PyJWT 2.13.0 accepts the token because the BOM causes the JWK\n# detection check to be skipped \u2014 the RSA JWK bytes become a valid HMAC key.\n# Result: arbitrary claims (role, sub, etc.) accepted by the verifier.\n```\n\n---\n\n## Impact\n\nAn unauthenticated network attacker who knows the target application\u0027s RSA public key \u2014 which is public by design and obtainable from a JWKS endpoint or certificate \u2014 can forge JWT tokens containing arbitrary claims and have them accepted by a PyJWT 2.13.0 verifier configured with a mixed algorithm set (`algorithms=[\"HS256\", \"RS256\"]` or equivalent). The resulting impact\nis complete authentication and authorization bypass (`C:H/I:H`). Attack Complexity is High (`AC:H`) because the attacker must obtain the RSA public key and the verifier must use a mixed-algorithm configuration; no authentication is required (`PR:N`). This is a patch bypass: users who upgraded to 2.13.0 specifically to remediate CVE-2026-48526 remain vulnerable.\n\n---\n\n## Suggested Fix\n\n**Option A (minimal)**: Replace `lstrip()` with an explicit strip of known\nBOM prefixes before the JSON detection check:\n\n```python\n# Strip common BOM prefixes in addition to ASCII whitespace\nBOM_PREFIXES = (b\"\\xef\\xbb\\xbf\", b\"\\xff\\xfe\", b\"\\xfe\\xff\")\nstripped = key_bytes\nfor bom in BOM_PREFIXES:\n if stripped.startswith(bom):\n stripped = stripped[len(bom):]\n break\nstripped = stripped.lstrip()\n```\n\n**Option B (more robust)**: Use `json.loads()` as the detection mechanism\ninstead of a byte-prefix check, so encoding variants and whitespace are\nhandled by the JSON parser:\n\n```python\ntry:\n test_obj = json.loads(key_bytes.strip())\n if isinstance(test_obj, dict) and \"kty\" in test_obj:\n raise InvalidKeyError(\"The specified key is an asymmetric key...\")\nexcept (ValueError, UnicodeDecodeError):\n pass\n```\n\nOption B is preferred because it is resilient to any future encoding variant.\n\n---\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported algorithm-confusion path on PyJWT 2.13.0. When an application passes a raw public RSA JWK as the key and allows both an asymmetric and HMAC algorithm, a forged HS256 token signed with the known public JWK bytes is accepted when the JWK is represented in encodings accepted by Python\u0027s JSON decoder. The normal raw-JWK, asymmetric-only, and algorithm-bound `PyJWK` controls reject the token. This is an application configuration precondition, but the bypass is in PyJWT\u0027s own raw-JWK validation guard and is in scope under the PyJWT security policy.\n\nThe fix is committed as `180783930de91876bc0d601f826a1f2956057291`. `HMACAlgorithm.prepare_key()` now checks parsed JSON objects for `kty` across accepted UTF-8/16/32 representations, preserves non-JWK HMAC key bytes, and conservatively rejects deeply nested JSON objects even when parsing reaches the recursion guard. Regression coverage includes BOM and BOM-less encodings, deep non-JWK keys, deep JWK objects, and unpaired-surrogate cases.\n\nThe full suite passes with 391 tests and 4 intentional cryptography-environment skips. A fresh Astra/max independent review accepted commit `180783930de91876bc0d601f826a1f2956057291`. It independently confirmed encoding/BOM handling, recursion and surrogate behavior, preservation of non-object key compatibility, and the reported test results.\n\nThe fix has not been released. The advisory remains High with its existing CVSS 3.1 score of 7.4, and the patched version remains unset pending release planning.\n\n## Classification update \u2014 2026-09-10\n\nWe completed the advisory classification review. The proposed CVSS 3.1 vector is `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N` and the proposed CWE classification is CWE-347. These classifications reflect the documented impact and do not alter the affected range, fix status, or lifecycle state.\n\n## Maintainer update \u2014 2026-09-11\n\nThe verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.",
"id": "BREW-dvc-CVE-2026-102272",
"modified": "2026-09-30T10:24:56Z",
"published": "2026-09-30T10:24:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-r6x4-923q-g947"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102272"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/commit/180783930de91876bc0d601f826a1f2956057291"
},
{
"type": "PACKAGE",
"url": "https://github.com/jpadilla/pyjwt"
},
{
"type": "WEB",
"url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
}
],
"schema_version": "1.7.3",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "PyJWT BOM Bypass",
"upstream": [
"GHSA-r6x4-923q-g947",
"CVE-2026-102272"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.