# python-jose: RFC 7515 §4.1.11 `crit` header parameter not enforced

| | |

|--|--|

| Affected | `python-jose` (PyPI), `mpdavis/python-jose` |

| Tested version | 3.3.0 (current latest, last released 2022) |

| Bug class | Spec violation of RFC 7515 §4.1.11 (Critical Header Parameter) |

| Sister advisories | CVE-2026-32597 (PyJWT, fixed in 2.12.0), CVE-2026-35042 (fast-jwt), CVE-2025-59420 (Authlib) |

| Status as of writing | No published advisory for this library |

## Summary

`python-jose` does not implement RFC 7515 §4.1.11 critical header processing. A signed JWS that declares unknown extension parameters as critical via the `crit` header MUST be rejected per the RFC. `python-jose` accepts such tokens unconditionally if the signature is otherwise valid.

The same defect was patched in PyJWT (2.12.0) under CVE-2026-32597 and similar in Authlib (CVE-2025-59420, CVSS 7.5) and fast-jwt (CVE-2026-35042). `python-jose` remains unpatched.

## Maintenance status caveat

`python-jose` has not had a release since 3.3.0 (2022) and the GitHub advisory page shows zero published security advisories. The library is widely deployed via transitive dependencies (FastAPI dependency chains, Authlib alternatives, OAuth2 clients) and is not formally deprecated. A CVE here serves both as user notification and as input for downstream forks.

## RFC reference

> "If any of the listed extension Header Parameters are not understood and supported by the recipient, then the JWS is invalid."

> - RFC 7515 §4.1.11

## Source-code confirmation

`jose/jws.py` in the current `master` branch does not reference `crit`, RFC 7515 §4.1.11, RFC 7797, `b64`, or any extension-header-parameter handling. The `_load()` function decodes the header JSON without inspecting `crit`. The `_encode_header()` function passes through arbitrary additional headers but performs no validation.

## Reproduction

```

$ python3 orchestrator/differ.py --corpus corpus/seed.json --only crit-crit-eca

[schism] 4/5 targets up: ['nodejwt', 'pyjwt', 'pyjose', 'panva']

[BYPASS] crit-crit-eca                        sev=bypass-risk  accept=['nodejwt', 'pyjose']  reject=['pyjwt', 'panva']

```

Per-library verdict:

```

nodejwt 9.0.2  valid=True

pyjwt   2.12.0 valid=False  InvalidJWTError: Token has unsupported critical header

pyjose  3.3.0  valid=True

panva   5.10.0 valid=False  ERR_JOSE_NOT_SUPPORTED: Extension Header Parameter "foobar" is not recognized

```

Standalone reproducer:

```python

from jose import jwt

import base64, hmac, hashlib, json

secret = "schism-secret"

header = {"alg": "HS256", "typ": "JWT", "crit": ["foobar"], "foobar": True}

claims = {"sub": "alice", "iat": 1700000000, "exp": 9999999999}

def b64u(b): return base64.urlsafe_b64encode(b).rstrip(b"=").decode()

h = b64u(json.dumps(header, separators=(",", ":")).encode())

p = b64u(json.dumps(claims, separators=(",", ":")).encode())

sig = hmac.new(secret.encode(), f"{h}.{p}".encode(), hashlib.sha256).digest()

token = f"{h}.{p}.{b64u(sig)}"

result = jwt.decode(token, secret, algorithms=["HS256"])

print(result)

# → {'sub': 'alice', 'iat': 1700000000, 'exp': 9999999999}

#   token ACCEPTED despite unknown critical "foobar" extension

```

Expected behavior per RFC 7515 §4.1.11: `jwt.decode` should raise because `foobar` is not understood.

## Exploitability

Same as the sister advisories: any application that relies on `crit` to enforce a security-relevant extension cannot rely on `python-jose` to honor the directive. Specific scenarios - RFC 7797 detached payload, RFC 9449 DPoP `cnf` binding, custom application extensions - are silently bypassed.

In heterogeneous deployments where one service uses `python-jose` and another uses a strict verifier (panva, PyJWT ≥ 2.12.0), the same token bytes parse with different security guarantees at different services. This split-brain validation is the same exploitation pattern documented in CVE-2025-59420 (Authlib).

## Comparison with sister advisories

| Lib | Advisory | Fixed |

|--|--|--|

| PyJWT | CVE-2026-32597 / GHSA-752w-5fwx-jx9f | 2.12.0 |

| fast-jwt | CVE-2026-35042 | (per advisory) |

| Authlib | CVE-2025-59420 / GHSA-9ggr-2464-2j32 | CVSS 7.5 |

| **python-jose (this report)** | **none** | **unpatched** |

## Suggested remediation

In `jose/jws.py` `_verify_signature` and `_load`:

1. After parsing the JOSE header, check for a `crit` member.

2. Validate the value is a non-empty list of strings, each corresponding to a Header Parameter actually present in the header (per RFC 7515 §4.1.11 ABNF and prose).

3. Reject reserved RFC names from appearing in `crit`.

4. Reject the token if any entry is not in an explicit caller-supplied allowlist of supported extensions.

5. Expose this allowlist via the public `jwt.decode` and `jws.verify` APIs.

## Disclosure

Filed via GitHub Security Advisory at `mpdavis/python-jose`. CVE requested via MITRE.