CVE-2026-102272: PyJWT PyJWT BOM Bypass Vulnerability
HIGHCVE-2026-102272 is a HIGH (CVSS 7.4) pyjwt bom bypass vulnerability (CWE-347: Improper Verification of Cryptographic Signature) affecting PyJWT libraries in the PyPI ecosystem. The issue involves pyjwt bom bypass. Remediation is available by upgrading affected packages to version 2.14.0.
CVE-2026-102272 at a Glance
Security Impact
CVSS: 7.4
The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).
How to Fix CVE-2026-102272
To remediate this vulnerability, upgrade all affected PyJWT dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
pip install PyJWT>=2.14.0
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
pip show PyJWT
How to Check if You Are Affected
To determine whether your Python environment is affected by CVE-2026-102272, inspect your installed packages using pip:
pip show PyJWT
Analyze the terminal output to locate any version of PyJWT in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.14.0), your application is affected.
Note: The pip show PyJWT command checks currently installed packages in your active Python environment.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-347: Improper Verification of Cryptographic Signature, where the product does not verify, or incorrectly verifies, the cryptographic signature for data. In PyJWT, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-102272 Affected PyJWT Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
PyJWT
|
PyPI |
≥ 2.13.0
< 2.14.0
All 1 versions
2.13.0
|
2.14.0
|
References
Frequently Asked Questions
What is CVE-2026-102272?
Which PyJWT versions are affected?
What version fixes CVE-2026-102272?
Is PyJWT affected?
What is the CVSS score of CVE-2026-102272?
What CWE is associated with CVE-2026-102272?
How can I check PyPI dependencies for CVE-2026-102272?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-r6x4-923q-g947",
"modified" : "2026-09-29T23:14:00Z",
"published" : "2026-09-29T23:14:00Z",
"aliases" : [ "CVE-2026-102272" ],
"summary" : "PyJWT BOM Bypass",
"details" : "## Affected Package\n\n- **Package**: PyJWT (`pyjwt` on PyPI)\n- **Repository**: https://www.google.com/url?q=https://github.com/jpadilla/pyjwt&source=gmail&ust=1781794518474000&sa=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 — 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 — 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 — 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'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\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 — 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'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.\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 — 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 — 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.",
"severity" : [ {
"type" : "CVSS_V3",
"score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "PyPI",
"name" : "PyJWT"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "2.13.0"
}, {
"fixed" : "2.14.0"
} ]
} ],
"versions" : [ "2.13.0" ]
} ],
"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"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-347" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-09-29T23:14:00Z",
"nvd_published_at" : "2026-09-28T21:17:15Z"
}
}