{
  "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": "bbot",
        "purl": "pkg:brew/bbot"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.4_6"
            }
          ],
          "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-bbot-CVE-2026-102272",
  "modified": "2026-09-30T09:57:14Z",
  "published": "2026-09-30T09:57:14Z",
  "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"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.0",
        "upstream_fixed_in": "2.14.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "cycode",
        "purl": "pkg:brew/cycode"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.15.2_2"
            },
            {
              "fixed": "3.24.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.15.0",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.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-cycode-CVE-2026-102272",
  "modified": "2026-09-30T09:19:39Z",
  "published": "2026-09-30T09:19:39Z",
  "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"
  ]
}

{
  "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"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.0",
        "upstream_fixed_in": "2.14.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "fastmcp",
        "purl": "pkg:brew/fastmcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.3.1_1"
            },
            {
              "fixed": "4.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.15.0",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.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-fastmcp-CVE-2026-102272",
  "modified": "2026-09-30T10:16:48Z",
  "published": "2026-09-30T10:16:48Z",
  "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"
  ]
}

{
  "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": "forbidden",
        "purl": "pkg:brew/forbidden"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.4_7"
            }
          ],
          "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-forbidden-CVE-2026-102272",
  "modified": "2026-09-30T08:52:24Z",
  "published": "2026-09-30T08:52:24Z",
  "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"
  ]
}

{
  "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": "gimme-aws-creds",
        "purl": "pkg:brew/gimme-aws-creds"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.2_13"
            }
          ],
          "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-gimme-aws-creds-CVE-2026-102272",
  "modified": "2026-09-30T09:16:05Z",
  "published": "2026-09-30T09:16:05Z",
  "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"
  ]
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.14.0",
        "upstream_fixed_in": "2.14.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "gptme",
        "purl": "pkg:brew/gptme"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.31.0_11"
            },
            {
              "fixed": "0.34.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.14.0",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.14.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-gptme-CVE-2026-102272",
  "modified": "2026-09-30T09:13:04Z",
  "published": "2026-09-30T09:13:04Z",
  "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"
  ]
}

{
  "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": "hermes-agent",
        "purl": "pkg:brew/hermes-agent"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.7.1"
            }
          ],
          "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-hermes-agent-CVE-2026-102272",
  "modified": "2026-09-30T09:52:06Z",
  "published": "2026-09-30T09:52:06Z",
  "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"
  ]
}

{
  "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": "howdoi",
        "purl": "pkg:brew/howdoi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.20_22"
            }
          ],
          "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-howdoi-CVE-2026-102272",
  "modified": "2026-09-30T10:47:34Z",
  "published": "2026-09-30T10:47:34Z",
  "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"
  ]
}

{
  "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": "kimi-cli",
        "purl": "pkg:brew/kimi-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.44.0_1"
            }
          ],
          "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-kimi-cli-CVE-2026-102272",
  "modified": "2026-09-30T10:50:51Z",
  "published": "2026-09-30T10:50:51Z",
  "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"
  ]
}