Vulnerability-Lookup

URL	Tags
https://github.com/jpadilla/pyjwt/security/adviso…	x_refsource_CONFIRM
https://github.com/jpadilla/pyjwt/commit/e6f48401…	x_refsource_MISC
https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	x_refsource_MISC

Vendor	Product	Version	CPE status
jpadilla	pyjwt	Affected: < 2.14.0	guessed

BREW-SEMGREP-CVE-2026-102269 (GHSA-HXM8-2XGR-2P9M)

Vulnerability from osv_homebrew – Published: 2026-09-30 19:45 – Updated: 2026-10-04 11:26 – Source website

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/jpadilla/pyjwt/security/adviso…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-102269	ADVISORY
	https://github.com/jpadilla/pyjwt/commit/e6f48401…	WEB
	https://github.com/jpadilla/pyjwt	PACKAGE
	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.1",
        "upstream_fixed_in": "2.14.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "semgrep",
        "purl": "pkg:brew/semgrep"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.146.0"
            },
            {
              "fixed": "1.179.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.15.1",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.1"
      }
    ]
  },
  "details": "## Summary\n\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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-semgrep-CVE-2026-102269",
  "modified": "2026-10-04T11:26:37Z",
  "published": "2026-09-30T19:45:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass",
  "upstream": [
    "GHSA-hxm8-2xgr-2p9m",
    "CVE-2026-102269",
    "PYSEC-2026-4147"
  ]
}

BREW-SIGSTORE-CVE-2026-102269 (GHSA-HXM8-2XGR-2P9M)

Vulnerability from osv_homebrew – Published: 2026-09-30 09:42 – Updated: 2026-10-02 09:46 – Source website

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/jpadilla/pyjwt/security/adviso…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-102269	ADVISORY
	https://github.com/jpadilla/pyjwt/commit/e6f48401…	WEB
	https://github.com/jpadilla/pyjwt	PACKAGE
	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.1",
        "upstream_fixed_in": "2.14.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "sigstore",
        "purl": "pkg:brew/sigstore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.1"
            },
            {
              "fixed": "4.5.0_1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.15.1",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.1"
      }
    ]
  },
  "details": "## Summary\n\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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-sigstore-CVE-2026-102269",
  "modified": "2026-10-02T09:46:02Z",
  "published": "2026-09-30T09:42:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass",
  "upstream": [
    "GHSA-hxm8-2xgr-2p9m",
    "CVE-2026-102269",
    "PYSEC-2026-4147"
  ]
}

BREW-SNOWFLAKE-CLI-CVE-2… (GHSA-HXM8-2XGR-2P9M)

Vulnerability from osv_homebrew – Published: 2026-09-30 09:56 – Updated: 2026-10-02 09:51 – Source website

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/jpadilla/pyjwt/security/adviso…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-102269	ADVISORY
	https://github.com/jpadilla/pyjwt/commit/e6f48401…	WEB
	https://github.com/jpadilla/pyjwt	PACKAGE
	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	WEB

JSON

To clipboard

{
  "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\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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-snowflake-cli-CVE-2026-102269",
  "modified": "2026-10-02T09:51:40Z",
  "published": "2026-09-30T09:56:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass",
  "upstream": [
    "GHSA-hxm8-2xgr-2p9m",
    "CVE-2026-102269",
    "PYSEC-2026-4147"
  ]
}

BREW-SNYK-AGENT-SCAN-CVE… (GHSA-HXM8-2XGR-2P9M)

Vulnerability from osv_homebrew – Published: 2026-09-30 09:42 – Updated: 2026-10-02 09:43 – Source website

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/jpadilla/pyjwt/security/adviso…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-102269	ADVISORY
	https://github.com/jpadilla/pyjwt/commit/e6f48401…	WEB
	https://github.com/jpadilla/pyjwt	PACKAGE
	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.1",
        "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.1",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.1"
      }
    ]
  },
  "details": "## Summary\n\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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-snyk-agent-scan-CVE-2026-102269",
  "modified": "2026-10-02T09:43:02Z",
  "published": "2026-09-30T09:42:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass",
  "upstream": [
    "GHSA-hxm8-2xgr-2p9m",
    "CVE-2026-102269",
    "PYSEC-2026-4147"
  ]
}

BREW-STRANDS-AGENTS-SOPS… (GHSA-HXM8-2XGR-2P9M)

Vulnerability from osv_homebrew – Published: 2026-09-30 09:58 – Updated: 2026-10-02 09:53 – Source website

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/jpadilla/pyjwt/security/adviso…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-102269	ADVISORY
	https://github.com/jpadilla/pyjwt/commit/e6f48401…	WEB
	https://github.com/jpadilla/pyjwt	PACKAGE
	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.1",
        "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"
            },
            {
              "fixed": "1.1.3_2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.15.1",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.1"
      }
    ]
  },
  "details": "## Summary\n\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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-strands-agents-sops-CVE-2026-102269",
  "modified": "2026-10-02T09:53:44Z",
  "published": "2026-09-30T09:58:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass",
  "upstream": [
    "GHSA-hxm8-2xgr-2p9m",
    "CVE-2026-102269",
    "PYSEC-2026-4147"
  ]
}

BREW-SYSAIDMIN-CVE-2026-102269 (GHSA-HXM8-2XGR-2P9M)

Vulnerability from osv_homebrew – Published: 2026-10-04 12:07 – Updated: 2026-10-04 12:07 – Source website

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                    
                      CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

References

URL

Type

	https://github.com/jpadilla/pyjwt/security/adviso…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-102269	ADVISORY
	https://github.com/jpadilla/pyjwt/commit/e6f48401…	WEB
	https://github.com/jpadilla/pyjwt	PACKAGE
	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "pyjwt",
        "resource_purl": "pkg:pypi/pyjwt@2.15.1",
        "upstream_fixed_in": "2.14.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "sysaidmin",
        "purl": "pkg:brew/sysaidmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.2.5_6"
            },
            {
              "fixed": "0.2.5_20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/pyjwt@2.15.1",
        "name": "pyjwt",
        "resource": "pyjwt",
        "strategy": "registry",
        "subject_version": "2.15.1"
      }
    ]
  },
  "details": "## Summary\n\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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-sysaidmin-CVE-2026-102269",
  "modified": "2026-10-04T12:07:43Z",
  "published": "2026-10-04T12:07:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass",
  "upstream": [
    "GHSA-hxm8-2xgr-2p9m",
    "CVE-2026-102269",
    "PYSEC-2026-4147"
  ]
}

CERTFR-2026-AVI-1249

Vulnerability from certfr_avis - Published: 2026-10-02 - Updated: 2026-10-02

De multiples vulnérabilités ont été découvertes dans les produits VMware. Elles permettent à un attaquant de provoquer un problème de sécurité non spécifié par l'éditeur.

Solutions

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

Impacted products

Vendor	Product	Description
VMware	Tanzu	VMware Tanzu pour Valkey on Kubernetes versions antérieures à 3.5.1
VMware	Tanzu	VMware Tanzu pour Postgres on Kubernetes versions antérieures à 4.5.2
VMware	Spring Cloud Gateway	Spring Cloud Gateway pour Kubernetes versions antérieures à 2.2.17
VMware	Tanzu	VMware Tanzu pour Valkey versions antérieures à 8.0.11
VMware	Tanzu	VMware Tanzu pour Valkey versions 9.0.x antérieures à 9.0.6
VMware	Tanzu	VMware Tanzu pour Valkey versions 8.1.x antérieures à 8.1.10
VMware	Tanzu	VMware Tanzu pour Valkey versions 9.1.x antérieures à 9.1.2
VMware	Spring Cloud Data Flow	Spring Cloud Data Flow pour Kubernetes versions antérieures à 1.6.16

References

Title

Publication Time

Tags

Bulletin de sécurité VMware 39113	2026-10-01	vendor-advisory
Bulletin de sécurité VMware 39112	2026-10-01	vendor-advisory
Bulletin de sécurité VMware 39110	2026-10-01	vendor-advisory
Bulletin de sécurité VMware 39115	2026-10-01	vendor-advisory
Bulletin de sécurité VMware 39114	2026-10-01	vendor-advisory
Bulletin de sécurité VMware 39109	2026-10-01	vendor-advisory
Bulletin de sécurité VMware DSA-2026-31	2026-10-01	vendor-advisory
Bulletin de sécurité VMware 39111	2026-10-01	vendor-advisory

Show details on source website

JSON

To clipboard

{
  "$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
  "affected_systems": [
    {
      "description": "VMware Tanzu pour Valkey on Kubernetes versions ant\u00e9rieures \u00e0 3.5.1",
      "product": {
        "name": "Tanzu",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "VMware Tanzu pour Postgres on Kubernetes versions ant\u00e9rieures \u00e0 4.5.2",
      "product": {
        "name": "Tanzu",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "Spring Cloud Gateway pour Kubernetes versions ant\u00e9rieures \u00e0 2.2.17",
      "product": {
        "name": "Spring Cloud Gateway",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "VMware Tanzu pour Valkey versions ant\u00e9rieures \u00e0 8.0.11",
      "product": {
        "name": "Tanzu",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "VMware Tanzu pour Valkey versions 9.0.x ant\u00e9rieures \u00e0 9.0.6",
      "product": {
        "name": "Tanzu",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "VMware Tanzu pour Valkey versions 8.1.x ant\u00e9rieures \u00e0 8.1.10",
      "product": {
        "name": "Tanzu",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "VMware Tanzu pour Valkey versions 9.1.x ant\u00e9rieures \u00e0 9.1.2",
      "product": {
        "name": "Tanzu",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    },
    {
      "description": "Spring Cloud Data Flow pour Kubernetes versions ant\u00e9rieures \u00e0 1.6.16",
      "product": {
        "name": "Spring Cloud Data Flow",
        "vendor": {
          "name": "VMware",
          "scada": false
        }
      }
    }
  ],
  "affected_systems_content": "",
  "content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
  "cves": [
    {
      "name": "CVE-2026-75595",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75595"
    },
    {
      "name": "CVE-2026-53910",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53910"
    },
    {
      "name": "CVE-2026-56404",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56404"
    },
    {
      "name": "CVE-2026-58055",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58055"
    },
    {
      "name": "CVE-2025-61730",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61730"
    },
    {
      "name": "CVE-2026-54369",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54369"
    },
    {
      "name": "CVE-2025-58183",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58183"
    },
    {
      "name": "CVE-2026-11940",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11940"
    },
    {
      "name": "CVE-2026-56862",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56862"
    },
    {
      "name": "CVE-2026-53613",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53613"
    },
    {
      "name": "CVE-2026-102271",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102271"
    },
    {
      "name": "CVE-2026-42507",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42507"
    },
    {
      "name": "CVE-2026-33818",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33818"
    },
    {
      "name": "CVE-2026-39830",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39830"
    },
    {
      "name": "CVE-2026-63384",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63384"
    },
    {
      "name": "CVE-2026-34180",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-34180"
    },
    {
      "name": "CVE-2026-68763",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68763"
    },
    {
      "name": "CVE-2026-33186",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33186"
    },
    {
      "name": "CVE-2026-39826",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39826"
    },
    {
      "name": "CVE-2026-80489",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-80489"
    },
    {
      "name": "CVE-2026-42766",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42766"
    },
    {
      "name": "CVE-2026-13346",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13346"
    },
    {
      "name": "CVE-2026-56846",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56846"
    },
    {
      "name": "CVE-2026-9076",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-9076"
    },
    {
      "name": "CVE-2025-22872",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22872"
    },
    {
      "name": "CVE-2026-15310",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15310"
    },
    {
      "name": "CVE-2026-42508",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42508"
    },
    {
      "name": "CVE-2026-84445",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84445"
    },
    {
      "name": "CVE-2026-1965",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-1965"
    },
    {
      "name": "CVE-2026-34181",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-34181"
    },
    {
      "name": "CVE-2026-97687",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-97687"
    },
    {
      "name": "CVE-2026-81870",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-81870"
    },
    {
      "name": "CVE-2026-58013",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58013"
    },
    {
      "name": "CVE-2026-32288",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32288"
    },
    {
      "name": "CVE-2025-47907",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-47907"
    },
    {
      "name": "CVE-2026-59885",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59885"
    },
    {
      "name": "CVE-2026-42770",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42770"
    },
    {
      "name": "CVE-2026-91776",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-91776"
    },
    {
      "name": "CVE-2026-27138",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27138"
    },
    {
      "name": "CVE-2026-39822",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39822"
    },
    {
      "name": "CVE-2026-39833",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39833"
    },
    {
      "name": "CVE-2026-3783",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-3783"
    },
    {
      "name": "CVE-2026-13221",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13221"
    },
    {
      "name": "CVE-2026-33814",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33814"
    },
    {
      "name": "CVE-2026-27456",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27456"
    },
    {
      "name": "CVE-2026-63074",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63074"
    },
    {
      "name": "CVE-2026-68569",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68569"
    },
    {
      "name": "CVE-2026-59084",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
    },
    {
      "name": "CVE-2025-58185",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58185"
    },
    {
      "name": "CVE-2026-65183",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65183"
    },
    {
      "name": "CVE-2026-14257",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14257"
    },
    {
      "name": "CVE-2025-61731",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61731"
    },
    {
      "name": "CVE-2026-58015",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58015"
    },
    {
      "name": "CVE-2026-27137",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27137"
    },
    {
      "name": "CVE-2026-27143",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27143"
    },
    {
      "name": "CVE-2026-46600",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46600"
    },
    {
      "name": "CVE-2026-69152",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-69152"
    },
    {
      "name": "CVE-2026-45445",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45445"
    },
    {
      "name": "CVE-2026-68525",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68525"
    },
    {
      "name": "CVE-2026-18508",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18508"
    },
    {
      "name": "CVE-2026-39832",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39832"
    },
    {
      "name": "CVE-2026-39829",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39829"
    },
    {
      "name": "CVE-2026-56392",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56392"
    },
    {
      "name": "CVE-2026-65637",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65637"
    },
    {
      "name": "CVE-2025-15367",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-15367"
    },
    {
      "name": "CVE-2026-58014",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58014"
    },
    {
      "name": "CVE-2024-45341",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45341"
    },
    {
      "name": "CVE-2026-13595",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13595"
    },
    {
      "name": "CVE-2026-6357",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6357"
    },
    {
      "name": "CVE-2026-54515",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
    },
    {
      "name": "CVE-2026-63374",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63374"
    },
    {
      "name": "CVE-2026-13757",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13757"
    },
    {
      "name": "CVE-2026-15308",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15308"
    },
    {
      "name": "CVE-2026-27145",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27145"
    },
    {
      "name": "CVE-2026-68497",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68497"
    },
    {
      "name": "CVE-2026-39834",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39834"
    },
    {
      "name": "CVE-2026-63073",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63073"
    },
    {
      "name": "CVE-2022-40897",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-40897"
    },
    {
      "name": "CVE-2026-46595",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46595"
    },
    {
      "name": "CVE-2026-41992",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41992"
    },
    {
      "name": "CVE-2026-24051",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24051"
    },
    {
      "name": "CVE-2026-102265",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102265"
    },
    {
      "name": "CVE-2026-7383",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-7383"
    },
    {
      "name": "CVE-2026-39825",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39825"
    },
    {
      "name": "CVE-2026-39821",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39821"
    },
    {
      "name": "CVE-2026-27144",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27144"
    },
    {
      "name": "CVE-2026-4360",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-4360"
    },
    {
      "name": "CVE-2026-58012",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58012"
    },
    {
      "name": "CVE-2026-56865",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56865"
    },
    {
      "name": "CVE-2026-32283",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32283"
    },
    {
      "name": "CVE-2025-46686",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-46686"
    },
    {
      "name": "CVE-2025-61727",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61727"
    },
    {
      "name": "CVE-2026-11822",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11822"
    },
    {
      "name": "CVE-2025-22866",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22866"
    },
    {
      "name": "CVE-2026-59890",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59890"
    },
    {
      "name": "CVE-2026-14164",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14164"
    },
    {
      "name": "CVE-2026-14456",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14456"
    },
    {
      "name": "CVE-2026-56860",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56860"
    },
    {
      "name": "CVE-2026-6368",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6368"
    },
    {
      "name": "CVE-2026-1703",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-1703"
    },
    {
      "name": "CVE-2026-14457",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14457"
    },
    {
      "name": "CVE-2026-15534",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15534"
    },
    {
      "name": "CVE-2026-41991",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41991"
    },
    {
      "name": "CVE-2026-39883",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39883"
    },
    {
      "name": "CVE-2026-6879",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6879"
    },
    {
      "name": "CVE-2026-102269",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102269"
    },
    {
      "name": "CVE-2026-32281",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32281"
    },
    {
      "name": "CVE-2026-75596",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75596"
    },
    {
      "name": "CVE-2026-8763",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-8763"
    },
    {
      "name": "CVE-2026-27142",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27142"
    },
    {
      "name": "CVE-2026-41989",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41989"
    },
    {
      "name": "CVE-2026-42504",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42504"
    },
    {
      "name": "CVE-2026-56412",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56412"
    },
    {
      "name": "CVE-2026-69247",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
    },
    {
      "name": "CVE-2025-47906",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-47906"
    },
    {
      "name": "CVE-2026-48864",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-48864"
    },
    {
      "name": "CVE-2026-65182",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65182"
    },
    {
      "name": "CVE-2026-56858",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56858"
    },
    {
      "name": "CVE-2026-12003",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12003"
    },
    {
      "name": "CVE-2026-53615",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53615"
    },
    {
      "name": "CVE-2026-15588",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15588"
    },
    {
      "name": "CVE-2026-59903",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59903"
    },
    {
      "name": "CVE-2026-102268",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102268"
    },
    {
      "name": "CVE-2026-25589",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-25589"
    },
    {
      "name": "CVE-2025-58188",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58188"
    },
    {
      "name": "CVE-2026-102267",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102267"
    },
    {
      "name": "CVE-2025-4674",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-4674"
    },
    {
      "name": "CVE-2026-57433",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-57433"
    },
    {
      "name": "CVE-2026-39820",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39820"
    },
    {
      "name": "CVE-2026-56854",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56854"
    },
    {
      "name": "CVE-2026-84303",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84303"
    },
    {
      "name": "CVE-2025-5278",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-5278"
    },
    {
      "name": "CVE-2026-32952",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32952"
    },
    {
      "name": "CVE-2026-73180",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73180"
    },
    {
      "name": "CVE-2026-39819",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39819"
    },
    {
      "name": "CVE-2026-58010",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58010"
    },
    {
      "name": "CVE-2026-16118",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16118"
    },
    {
      "name": "CVE-2026-42769",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42769"
    },
    {
      "name": "CVE-2025-6141",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-6141"
    },
    {
      "name": "CVE-2026-19672",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19672"
    },
    {
      "name": "CVE-2024-45336",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45336"
    },
    {
      "name": "CVE-2026-25588",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-25588"
    },
    {
      "name": "CVE-2025-22868",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22868"
    },
    {
      "name": "CVE-2026-5435",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-5435"
    },
    {
      "name": "CVE-2025-61724",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61724"
    },
    {
      "name": "CVE-2026-3219",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-3219"
    },
    {
      "name": "CVE-2026-11824",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11824"
    },
    {
      "name": "CVE-2026-2303",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-2303"
    },
    {
      "name": "CVE-2025-61732",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61732"
    },
    {
      "name": "CVE-2026-101917",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101917"
    },
    {
      "name": "CVE-2025-61723",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61723"
    },
    {
      "name": "CVE-2026-5928",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-5928"
    },
    {
      "name": "CVE-2026-39831",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39831"
    },
    {
      "name": "CVE-2026-102273",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102273"
    },
    {
      "name": "CVE-2026-39828",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39828"
    },
    {
      "name": "CVE-2026-45447",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45447"
    },
    {
      "name": "CVE-2025-6170",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-6170"
    },
    {
      "name": "CVE-2026-25679",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-25679"
    },
    {
      "name": "CVE-2026-33811",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33811"
    },
    {
      "name": "CVE-2024-45337",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-45337"
    },
    {
      "name": "CVE-2025-61725",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61725"
    },
    {
      "name": "CVE-2026-63075",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63075"
    },
    {
      "name": "CVE-2026-25680",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-25680"
    },
    {
      "name": "CVE-2026-87910",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87910"
    },
    {
      "name": "CVE-2026-39835",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39835"
    },
    {
      "name": "CVE-2026-64847",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64847"
    },
    {
      "name": "CVE-2026-33815",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33815"
    },
    {
      "name": "CVE-2026-59884",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59884"
    },
    {
      "name": "CVE-2026-4539",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-4539"
    },
    {
      "name": "CVE-2026-12087",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12087"
    },
    {
      "name": "CVE-2025-15366",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-15366"
    },
    {
      "name": "CVE-2026-32289",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32289"
    },
    {
      "name": "CVE-2026-56848",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56848"
    },
    {
      "name": "CVE-2026-45446",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45446"
    },
    {
      "name": "CVE-2026-91777",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-91777"
    },
    {
      "name": "CVE-2026-58011",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58011"
    },
    {
      "name": "CVE-2026-63382",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63382"
    },
    {
      "name": "CVE-2025-22874",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22874"
    },
    {
      "name": "CVE-2026-84304",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84304"
    },
    {
      "name": "CVE-2026-56405",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56405"
    },
    {
      "name": "CVE-2026-63076",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63076"
    },
    {
      "name": "CVE-2026-32280",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32280"
    },
    {
      "name": "CVE-2025-47912",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-47912"
    },
    {
      "name": "CVE-2026-58016",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58016"
    },
    {
      "name": "CVE-2026-63383",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63383"
    },
    {
      "name": "CVE-2024-2236",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-2236"
    },
    {
      "name": "CVE-2026-6653",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6653"
    },
    {
      "name": "CVE-2026-56859",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56859"
    },
    {
      "name": "CVE-2025-61728",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61728"
    },
    {
      "name": "CVE-2026-66422",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-66422"
    },
    {
      "name": "CVE-2025-58186",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58186"
    },
    {
      "name": "CVE-2026-18798",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18798"
    },
    {
      "name": "CVE-2026-56853",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56853"
    },
    {
      "name": "CVE-2026-34183",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-34183"
    },
    {
      "name": "CVE-2025-8869",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-8869"
    },
    {
      "name": "CVE-2025-58187",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58187"
    },
    {
      "name": "CVE-2026-77117",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77117"
    },
    {
      "name": "CVE-2026-13506",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13506"
    },
    {
      "name": "CVE-2026-42505",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42505"
    },
    {
      "name": "CVE-2026-49844",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
    },
    {
      "name": "CVE-2025-4673",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-4673"
    },
    {
      "name": "CVE-2026-102266",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102266"
    },
    {
      "name": "CVE-2026-54370",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54370"
    },
    {
      "name": "CVE-2025-22871",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22871"
    },
    {
      "name": "CVE-2026-29181",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-29181"
    },
    {
      "name": "CVE-2026-39836",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39836"
    },
    {
      "name": "CVE-2026-6791",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6791"
    },
    {
      "name": "CVE-2026-56408",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56408"
    },
    {
      "name": "CVE-2026-6477",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6477"
    },
    {
      "name": "CVE-2026-42767",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42767"
    },
    {
      "name": "CVE-2026-97689",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-97689"
    },
    {
      "name": "CVE-2026-50219",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-50219"
    },
    {
      "name": "CVE-2026-102270",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102270"
    },
    {
      "name": "CVE-2026-6238",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6238"
    },
    {
      "name": "CVE-2026-0864",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-0864"
    },
    {
      "name": "CVE-2026-63379",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63379"
    },
    {
      "name": "CVE-2026-56403",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56403"
    },
    {
      "name": "CVE-2026-17084",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-17084"
    },
    {
      "name": "CVE-2026-39882",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39882"
    },
    {
      "name": "CVE-2025-58181",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58181"
    },
    {
      "name": "CVE-2026-59886",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59886"
    },
    {
      "name": "CVE-2025-47914",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-47914"
    },
    {
      "name": "CVE-2026-66299",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-66299"
    },
    {
      "name": "CVE-2026-11979",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11979"
    },
    {
      "name": "CVE-2025-22869",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22869"
    },
    {
      "name": "CVE-2026-63385",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63385"
    },
    {
      "name": "CVE-2025-58189",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-58189"
    },
    {
      "name": "CVE-2026-63387",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63387"
    },
    {
      "name": "CVE-2026-27140",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27140"
    },
    {
      "name": "CVE-2026-39817",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39817"
    },
    {
      "name": "CVE-2026-65905",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65905"
    },
    {
      "name": "CVE-2026-42499",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42499"
    },
    {
      "name": "CVE-2026-42764",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42764"
    },
    {
      "name": "CVE-2026-82049",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-82049"
    },
    {
      "name": "CVE-2025-22870",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22870"
    },
    {
      "name": "CVE-2026-75803",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75803"
    },
    {
      "name": "CVE-2026-8643",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-8643"
    },
    {
      "name": "CVE-2026-19487",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19487"
    },
    {
      "name": "CVE-2026-41889",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41889"
    },
    {
      "name": "CVE-2026-27139",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-27139"
    },
    {
      "name": "CVE-2026-42501",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42501"
    },
    {
      "name": "CVE-2026-101918",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101918"
    },
    {
      "name": "CVE-2026-42250",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42250"
    },
    {
      "name": "CVE-2026-65927",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65927"
    },
    {
      "name": "CVE-2026-46598",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46598"
    },
    {
      "name": "CVE-2025-48924",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-48924"
    },
    {
      "name": "CVE-2026-33810",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33810"
    },
    {
      "name": "CVE-2026-42768",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42768"
    },
    {
      "name": "CVE-2026-15806",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15806"
    },
    {
      "name": "CVE-2026-57432",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-57432"
    },
    {
      "name": "CVE-2026-32282",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32282"
    },
    {
      "name": "CVE-2026-63381",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63381"
    },
    {
      "name": "CVE-2026-11972",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11972"
    },
    {
      "name": "CVE-2026-58043",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58043"
    },
    {
      "name": "CVE-2025-68121",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-68121"
    },
    {
      "name": "CVE-2026-12912",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12912"
    },
    {
      "name": "CVE-2026-18477",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18477"
    },
    {
      "name": "CVE-2025-11065",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-11065"
    },
    {
      "name": "CVE-2026-46597",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46597"
    },
    {
      "name": "CVE-2026-102274",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102274"
    },
    {
      "name": "CVE-2025-61726",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61726"
    },
    {
      "name": "CVE-2026-5704",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-5704"
    },
    {
      "name": "CVE-2026-34182",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-34182"
    },
    {
      "name": "CVE-2026-18503",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18503"
    },
    {
      "name": "CVE-2026-19542",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19542"
    },
    {
      "name": "CVE-2026-63388",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63388"
    },
    {
      "name": "CVE-2026-9547",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-9547"
    },
    {
      "name": "CVE-2026-19032",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19032"
    },
    {
      "name": "CVE-2026-33816",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33816"
    },
    {
      "name": "CVE-2026-56132",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56132"
    },
    {
      "name": "CVE-2026-54874",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54874"
    },
    {
      "name": "CVE-2026-18938",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18938"
    },
    {
      "name": "CVE-2026-54272",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54272"
    },
    {
      "name": "CVE-2026-69192",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-69192"
    },
    {
      "name": "CVE-2026-97688",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-97688"
    },
    {
      "name": "CVE-2026-54371",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54371"
    },
    {
      "name": "CVE-2023-5752",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-5752"
    },
    {
      "name": "CVE-2026-39827",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39827"
    },
    {
      "name": "CVE-2026-102272",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-102272"
    },
    {
      "name": "CVE-2025-22873",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22873"
    },
    {
      "name": "CVE-2025-47273",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-47273"
    },
    {
      "name": "CVE-2026-8286",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-8286"
    },
    {
      "name": "CVE-2026-39823",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39823"
    },
    {
      "name": "CVE-2025-61729",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-61729"
    },
    {
      "name": "CVE-2026-83557",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-83557"
    },
    {
      "name": "CVE-2024-6345",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-6345"
    },
    {
      "name": "CVE-2026-63072",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63072"
    },
    {
      "name": "CVE-2026-77310",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77310"
    },
    {
      "name": "CVE-2026-103001",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-103001"
    },
    {
      "name": "CVE-2026-59889",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59889"
    },
    {
      "name": "CVE-2026-56864",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56864"
    }
  ],
  "initial_release_date": "2026-10-02T00:00:00",
  "last_revision_date": "2026-10-02T00:00:00",
  "links": [],
  "reference": "CERTFR-2026-AVI-1249",
  "revisions": [
    {
      "description": "Version initiale",
      "revision_date": "2026-10-02T00:00:00.000000"
    }
  ],
  "risks": [
    {
      "description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
    }
  ],
  "summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits VMware. Elles permettent \u00e0 un attaquant de provoquer un probl\u00e8me de s\u00e9curit\u00e9 non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur.",
  "title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits VMware",
  "vendor_advisories": [
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39113",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39113"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39112",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39112"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39110",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39110"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39115",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39115"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39114",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39114"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39109",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39109"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware DSA-2026-31",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39108"
    },
    {
      "published_at": "2026-10-01",
      "title": "Bulletin de s\u00e9curit\u00e9 VMware 39111",
      "url": "https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/39111"
    }
  ]
}

FKIE_CVE-2026-102269

Vulnerability from fkie_nvd - Published: 2026-09-28 21:17 - Updated: 2026-09-30 19:38

Severity

4.8 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Summary

PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0.

References

	URL	Tags
	security-advisories@github.com	https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8
	security-advisories@github.com	https://github.com/jpadilla/pyjwt/releases/tag/2.14.0
	security-advisories@github.com	https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "pyjwt",
          "vendor": "jpadilla",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 2.14.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "PyJWT is a Python implementation of JSON Web Token standards. Prior to 2.14.0, PyJWT signature segment is affected because signature segment decoding accepts characters outside the canonical Base64URL representation. This occurs when non-Base64URL characters are appended to a valid compact JWS signature segment. As a result, base64url_decode produces the same signature bytes for different serialized segments. Consequently, raw-token revocation checks can fail to recognize an equivalent modified token. This issue is fixed in version 2.14.0."
    }
  ],
  "id": "CVE-2026-102269",
  "lastModified": "2026-09-30T19:38:27.293",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "HIGH",
          "attackVector": "NETWORK",
          "availabilityImpact": "NONE",
          "baseScore": 4.8,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "LOW",
          "integrityImpact": "LOW",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.2,
        "impactScore": 2.5,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-102269",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-09-29T13:48:45.838410Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-09-28T21:17:14.773",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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-hxm8-2xgr-2p9m"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Awaiting Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-180"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    }
  ]
}

GHSA-HXM8-2XGR-2P9M

Vulnerability from github – Published: 2026-09-29 23:17 – Updated: 2026-09-29 23:17

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Details

Summary

PyJWT 2.13.0 accepts compact JWS signature segments containing characters that are not in the Base64URL alphabet. Appending !!!! to a valid signature does not change the decoded signature bytes or authenticated claims, but it changes the serialized token and its SHA-256 hash. An application that indexes logout or revocation state by the raw token therefore rejects the logged-out token and accepts its no-key alternate serialization.

This report separates two issues: permissive compact-JWS decoding is the library behavior, while using raw serialized JWT text as a security identity is a dangerous application composition. A jti-indexed control blocks both representations.

Affected Version

Confirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the signature segment and requires no signing key.

End-to-End Reproduction

.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py

The loopback-only lab performs:

Issue a valid HS256 admin token.
Access /protected successfully.
Log out the canonical token and store SHA256(raw_token).
Confirm canonical replay returns HTTP 401.
Append !!!! to only the signature segment.
Confirm the mutated token has the same verified claims and signature bytes, a different raw hash, and receives HTTP 200.
Repeat with jti-indexed revocation and confirm both forms return HTTP 401.

Observed statuses for raw-token revocation were 200 -> logout -> 401 for the canonical token and 200 for the alternate serialization. The jti control returned 401 for both replays after logout.

Security Boundaries and Severity

This is not signature forgery: the attacker starts with a valid token and cannot alter its claims. Impact requires a consumer to bind revocation, replay state, rate limits, or cache identity to the raw compact string. Under that composition, an authenticated user can bypass logout or token-specific revocation without the signing key. Medium is suggested for triage because the security impact is real but application-dependent.

Recommended Fix

Reject signature segments containing characters outside [A-Za-z0-9_-].
Reject padding and other non-canonical Base64URL encodings for compact JWS.
Add regression tests proving malformed signature encodings fail before or during verification.
Document that applications must use a semantic identifier such as jti, not the raw serialized token, for revocation and replay state.

Maintainer update — 2026-09-09

We reproduced the reported behavior on the verified master commit 8915570: appending !!!! to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags 2.4.0, 2.8.0, 2.10.1, 2.12.1, and 2.13.0.

The security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as jti for token identity.

The report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.

Maintainer update — 2026-09-09

The fix has been rebased onto the current master as e6f48401001609a8f99e71fcaf355fb895d508a8 and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as !!!! is rejected before verification. Valid detached b64=false handling remains supported.

Verification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and git diff --check passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.

The advisory remains medium severity and unpublished.

Classification update — 2026-09-10

We completed the advisory classification review. The proposed CVSS 3.1 vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.

These metadata changes do not alter the affected range, fix status, or lifecycle state.

Maintainer update — 2026-09-11

The verified fix for this advisory is included in PyJWT 2.14.0, released on 2026-09-11 and available on PyPI. PyJWT 2.14.0 is the first release containing the fix. This advisory is now published with 2.14.0 recorded as the patched version.

Severity

4.8 (Medium)


                  
                    CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.13.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "PyJWT"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.14.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102269"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-180"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-29T23:17:55Z",
    "nvd_published_at": "2026-09-28T21:17:14Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nPyJWT 2.13.0 accepts compact JWS signature segments containing characters that\nare not in the Base64URL alphabet. Appending `!!!!` to a valid signature does\nnot change the decoded signature bytes or authenticated claims, but it changes\nthe serialized token and its SHA-256 hash. An application that indexes logout\nor revocation state by the raw token therefore rejects the logged-out token and\naccepts its no-key alternate serialization.\n\nThis report separates two issues: permissive compact-JWS decoding is the\nlibrary behavior, while using raw serialized JWT text as a security identity is\na dangerous application composition. A `jti`-indexed control blocks both\nrepresentations.\n\n## Affected Version\n\nConfirmed with PyJWT 2.13.0 on CPython 3.13. The mutation changes only the\nsignature segment and requires no signing key.\n\n## End-to-End Reproduction\n\n```bash\n.venv-research/bin/python 06-practical-testing/revocation-bypass-lab.py\n```\n\nThe loopback-only lab performs:\n\n1. Issue a valid HS256 admin token.\n2. Access `/protected` successfully.\n3. Log out the canonical token and store `SHA256(raw_token)`.\n4. Confirm canonical replay returns HTTP 401.\n5. Append `!!!!` to only the signature segment.\n6. Confirm the mutated token has the same verified claims and signature bytes,\n   a different raw hash, and receives HTTP 200.\n7. Repeat with `jti`-indexed revocation and confirm both forms return HTTP 401.\n\nObserved statuses for raw-token revocation were `200 -\u003e logout -\u003e 401` for the\ncanonical token and `200` for the alternate serialization. The `jti` control\nreturned `401` for both replays after logout.\n\n## Security Boundaries and Severity\n\nThis is not signature forgery: the attacker starts with a valid token and\ncannot alter its claims. Impact requires a consumer to bind revocation, replay\nstate, rate limits, or cache identity to the raw compact string. Under that\ncomposition, an authenticated user can bypass logout or token-specific\nrevocation without the signing key. Medium is suggested for triage because the\nsecurity impact is real but application-dependent.\n\n## Recommended Fix\n\n- Reject signature segments containing characters outside `[A-Za-z0-9_-]`.\n- Reject padding and other non-canonical Base64URL encodings for compact JWS.\n- Add regression tests proving malformed signature encodings fail before or\n  during verification.\n- Document that applications must use a semantic identifier such as `jti`, not\n  the raw serialized token, for revocation and replay state.\n\n## Maintainer update \u2014 2026-09-09\n\nWe reproduced the reported behavior on the verified `master` commit `8915570`: appending `!!!!` to a valid compact-JWS signature segment is accepted, produces the same decoded signature bytes and claims, and changes the serialized token hash. Existing JWS verification controls pass. The behavior is present in the tested release range represented by tags `2.4.0`, `2.8.0`, `2.10.1`, `2.12.1`, and `2.13.0`.\n\nThe security impact is conditional on an application using the raw serialized token as the identity for logout, revocation, replay, rate-limit, or cache state. Under that composition, an attacker who already holds a valid token can use an alternate serialization after the canonical string is revoked. This is not signature forgery or claim alteration; applications should use a semantic identifier such as `jti` for token identity.\n\nThe report is ready to be accepted as a draft for continued remediation. A narrow fix assessment recommends rejecting non-canonical Base64URL characters and padding in compact-JWS segments. No fix commit or release is claimed yet.\n\n### Maintainer update \u2014 2026-09-09\n\nThe fix has been rebased onto the current `master` as `e6f48401001609a8f99e71fcaf355fb895d508a8` and is ready to be pushed. Compact-JWS header, payload, and signature segments are now required to use the unpadded Base64URL alphabet and canonical re-encoding; a signature segment containing non-canonical characters such as `!!!!` is rejected before verification. Valid detached `b64=false` handling remains supported.\n\nVerification on the rebased fix commit passed 372 tests with 4 intentional cryptography-environment skips; Ruff formatting/lint and `git diff --check` passed. The compressed-payload regression fixture was updated to valid canonical compact-JWS encoding. No release containing the fix has been published yet, so the patched version remains unset pending release planning.\n\nThe advisory remains medium severity and unpublished.\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:L/I:L/A:N` and the proposed CWE classification is CWE-180. The issue permits alternate non-canonical serializations of an already valid signed token to bypass applications that identify tokens by their raw serialization; it does not forge signatures or alter claims. CWE-180 captures validation/canonicalization ordering.\n\nThese metadata changes 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": "GHSA-hxm8-2xgr-2p9m",
  "modified": "2026-09-29T23:17:55Z",
  "published": "2026-09-29T23:17:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102269"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jpadilla/pyjwt/commit/e6f48401001609a8f99e71fcaf355fb895d508a8"
    },
    {
      "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:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PyJWT: Non-canonical signature segments enable raw-token revocation bypass"
}

MSRC_CVE-2026-102269

Vulnerability from csaf_microsoft - Published: 2026-09-30 01:03 - Updated: 2026-09-30 01:03

Summary

PyJWT: Non-canonical signature segments enable raw-token revocation bypass

Scope

1 vulnerability in this advisory, including CVE-2026-102269.

CVE-2026-102269

4.8 (Medium)


                
                  CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N

Known affected: 1 product

Open the full advisory

CVE-2026-102269 (GCVE-0-2026-102269)

Tags

Sightings

Nomenclature

Related by attack behaviour

Action not permitted

CVE-2026-102269 (GCVE-0-2026-102269)

BREW-SEMGREP-CVE-2026-102269 (GHSA-HXM8-2XGR-2P9M)

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

BREW-SIGSTORE-CVE-2026-102269 (GHSA-HXM8-2XGR-2P9M)

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

BREW-SNOWFLAKE-CLI-CVE-2… (GHSA-HXM8-2XGR-2P9M)

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

BREW-SNYK-AGENT-SCAN-CVE… (GHSA-HXM8-2XGR-2P9M)

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

BREW-STRANDS-AGENTS-SOPS… (GHSA-HXM8-2XGR-2P9M)

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

BREW-SYSAIDMIN-CVE-2026-102269 (GHSA-HXM8-2XGR-2P9M)

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

CERTFR-2026-AVI-1249

Solutions

FKIE_CVE-2026-102269

GHSA-HXM8-2XGR-2P9M

Summary

Affected Version

End-to-End Reproduction

Security Boundaries and Severity

Recommended Fix

Maintainer update — 2026-09-09

Maintainer update — 2026-09-09

Classification update — 2026-09-10

Maintainer update — 2026-09-11

MSRC_CVE-2026-102269

Tags

Sightings

Nomenclature

Related by attack behaviour