Affected: Homebrew: bbot

## 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

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

The loopback-only lab performs:

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

Observed statuses for raw-token revocation were `200 -> logout -> 401` for th…

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.

Affected: PyPI: PyJWT

## 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

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

The loopback-only lab performs:

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

Observed statuses for raw-token revocation were `200 -> logout -> 401` for th…

Affected: Ubuntu:Pro:16.04:LTS: pyjwt, Ubuntu:Pro:18.04:LTS: pyjwt, Ubuntu:Pro:20.04:LTS: pyjwt, Ubuntu:22.04:LTS: pyjwt, Ubuntu:24.04:LTS: pyjwt, Ubuntu:26.04:LTS: pyjwt

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.