chore(deps): bump pyjwt from 2.10.1 to 2.13.0

[dependabot]

Bumps pyjwt from 2.10.1 to 2.13.0.

Release notes

Sourced from pyjwt's releases.

2.13.0

PyJWT 2.13.0 — Security Release

This release bundles five security fixes plus three additional hardening / spec-compliance changes. We recommend all users upgrade.

Security

• GHSA-xgmm-8j9v-c9wx — JWK JSON accepted as HMAC secret (algorithm confusion). HMACAlgorithm.prepare_key previously rejected PEM- and SSH-formatted asymmetric keys but did not catch a JWK passed as a raw JSON string. In a verifier configured with both symmetric and asymmetric algorithms in algorithms=[…] and a raw-JSON JWK as the key, an attacker could forge HS256 tokens using the JWK text as the HMAC secret. The guard has been extended to reject any JWK-shaped JSON. Reported by @​aradona91.

• GHSA-jq35-7prp-9v3f — Algorithm allow-list bypass with PyJWK / PyJWKClient. When verifying with a PyJWK, the caller's algorithms=[…] allow-list was checked against the token header alg as a string only; actual verification used the algorithm bound to the PyJWK. An attacker who controlled a registered JWKS key could sign with one algorithm and advertise another on the header. PyJWT now requires the token header alg to match the PyJWK's algorithm before verification. Reported by @​sushi-gif.

• GHSA-w7vc-732c-9m39 — DoS via base64 decode of unused payload segment when b64=false. For detached-payload JWS (b64=false), the compact-form payload segment was base64-decoded before being discarded in favor of the caller-supplied detached_payload. An attacker could inflate the unused segment to force CPU + memory cost without holding a valid signature. The segment is now required to be empty per RFC 7515 Appendix F, and is no longer decoded. Reported by @​thesmartshadow.

• GHSA-993g-76c3-p5m4 — PyJWKClient accepts non-HTTP(S) URIs. PyJWKClient.fetch_data passed its URI to urllib.request.urlopen, which by default also handles file://, ftp://, and data: schemes. An application that fed an attacker-influenced URI into PyJWKClient could be coerced into reading local files or reaching other unintended schemes. PyJWKClient now rejects any URI whose scheme isn't http or https. Reported by @​KEIJOT.

• GHSA-fhv5-28vv-h8m8 — PyJWKClient cache wiped on fetch error. A finally-block put(jwk_set=None) cleared the JWK Set cache whenever a fetch raised, turning a transient JWKS-endpoint outage into application-wide auth failure. The cache write was moved into the success path; transient errors no longer evict valid cached keys. Reported by @​eddieran.

Fixed

• Reject empty HMAC keys outright in HMACAlgorithm.prepare_key with InvalidKeyError instead of accepting them with only a warning. Defends against the os.getenv("JWT_SECRET", "") footgun. Thanks to @​SnailSploit and @​spartan8806 for the reports.
• Forward per-call options (including enforce_minimum_key_length) from PyJWT.decode through to PyJWS._verify_signature. The option was previously silently dropped between the two layers, so it only took effect when set on the PyJWT instance. Thanks to @​WLUB for the report.
• RFC 7797 §3 compliance for b64=false: the encoder now auto-adds "b64" to crit, and the decoder rejects tokens that set b64=false without listing it in crit. Thanks to @​MachineLearning-Nerd for the report.

Changed

• Migrate the dev, docs, and tests package extras to dependency groups, by @​kurtmckee in #1152.

Upgrade notes

Most fixes are invisible to correctly-configured callers. A few behavioral changes you may encounter:

• Empty HMAC keys now raise. If your app passed "" or b"" as a secret (often via a missing env var, e.g. os.getenv("JWT_SECRET", "")), encode/decode will now raise InvalidKeyError. This is the intended behavior — fix the configuration.
• PyJWK decoding now requires the token's alg to match the JWK's algorithm. Previously a mismatch was silently honored if the header alg appeared in the allow-list. Tokens that relied on this mismatch will now fail with InvalidAlgorithmError.
• PyJWKClient now rejects non-HTTP(S) URIs at construction time. Tests or dev environments that fetched JWKS from file:// URIs need to switch to a local HTTP server or load the JWKS by other means (e.g. construct PyJWKSet.from_dict(...) directly).
• b64=false tokens are now strictly RFC 7515 / 7797 compliant. Tokens with a non-empty compact-form payload segment, or that omit "b64" from crit, will be rejected. PyJWT-produced tokens always satisfy both invariants, so round-trips through PyJWT are unaffected.
• enforce_minimum_key_length set per-call now takes effect. Callers who passed options={"enforce_minimum_key_length": True} to jwt.decode() previously got no enforcement; they will now get InvalidKeyError on undersized keys, as documented.

Full changelog: jpadilla/pyjwt@2.12.1...2.13.0

2.12.1

What's Changed

• Add typing_extensions dependency for Python < 3.11 by @​jpadilla in jpadilla/pyjwt#1151

Full Changelog: jpadilla/pyjwt@2.12.0...2.12.1

2.12.0

Security

• Validate the crit (Critical) Header Parameter defined in RFC 7515 §4.1.11. by @​dmbs335 in GHSA-752w-5fwx-jx9f

... (truncated)

Changelog

Sourced from pyjwt's changelog.

v2.13.0 <https://github.com/jpadilla/pyjwt/compare/2.12.1...2.13.0>__

Security

- Reject JWK JSON documents passed as raw HMAC secrets in
  ``HMACAlgorithm.prepare_key`` to close an algorithm-confusion gap that
  the existing PEM/SSH guard did not cover. Reported by @aradona91 in
  `GHSA-xgmm-8j9v-c9wx <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-xgmm-8j9v-c9wx>`__.
- Bind the JWT header ``alg`` to ``PyJWK.algorithm_name`` during
  verification so the caller's ``algorithms=[...]`` allow-list cannot be
  bypassed when decoding with a ``PyJWK`` / ``PyJWKClient`` key. Reported
  by @sushi-gif in `GHSA-jq35-7prp-9v3f <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-jq35-7prp-9v3f>`__.
- Reject non-``http(s)`` URI schemes in ``PyJWKClient`` so attacker-
  influenced URIs cannot read local files or reach unintended schemes via
  urllib's default ``file://`` / ``ftp://`` / ``data:`` handlers. Reported
  by @KEIJOT in `GHSA-993g-76c3-p5m4 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-993g-76c3-p5m4>`__.
- Preserve the cached JWK Set on fetch errors in ``PyJWKClient.fetch_data``.
  The previous ``finally``-block ``put(None)`` pattern cleared the cache
  on any transient outage, turning one bad JWKS request into application-
  wide auth failure. Reported by @eddieran in `GHSA-fhv5-28vv-h8m8 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-fhv5-28vv-h8m8>`__.
- Skip the unconditional base64 decode of the compact-form payload segment
  when ``b64=false`` is set in the protected header, and require that
  segment to be empty (RFC 7515 Appendix F detached form). Closes an
  unauthenticated DoS amplifier. Reported by @thesmartshadow in
  `GHSA-w7vc-732c-9m39 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-w7vc-732c-9m39>`__.
Fixed

- Reject empty HMAC keys outright in ``HMACAlgorithm.prepare_key`` with
  ``InvalidKeyError`` instead of accepting them with only a warning.
  Thanks to @SnailSploit and @spartan8806 for independently flagging the
  footgun.
- Forward per-call ``options`` (including ``enforce_minimum_key_length``)
  from ``PyJWT.decode`` through to ``PyJWS._verify_signature`` so the
  option actually takes effect when set at the call site rather than only
  on the ``PyJWT`` instance. Thanks to @WLUB for the report.
- RFC 7797 §3 compliance for ``b64=false``: the encoder now auto-adds
  ``&quot;b64&quot;`` to the ``crit`` header parameter, and the decoder rejects
  tokens that set ``b64=false`` without listing it in ``crit``. Thanks to
  @MachineLearning-Nerd for the report.
Changed



Migrate the dev, docs, and tests package extras to dependency groups by @​kurtmckee in [#1152](https://github.com/jpadilla/pyjwt/issues/1152) &lt;https://github.com/jpadilla/pyjwt/pull/1152&gt;__

v2.12.1 &lt;https://github.com/jpadilla/pyjwt/compare/2.12.0...2.12.1&gt;__
</tr></table>

... (truncated)

Commits

• 7144e45 Apply ruff format
• d2f4bec Restore cast() calls with cross-version type: ignore for prepare_key
• 22f478c Remove redundant casts in RSAAlgorithm.prepare_key and `ECAlgorithm.prepare...
• 95791b1 Bundle security fixes and hardening into 2.13.0
• dcc27a9 [pre-commit.ci] pre-commit autoupdate (#1155)
• 9d08a9a [pre-commit.ci] pre-commit autoupdate (#1146)
• b87c100 Bump codecov/codecov-action from 5 to 6 (#1154)
• 40e3147 Migrate development extras to dependency groups (#1152)
• a4e1a3d Add typing_extensions dependency for Python < 3.11 (#1151)
• bd9700c Use PyJWK algorithm when encoding without explicit algorithm (#1148)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  You can disable automated security fix PRs for this repo from the Security Alerts page.

[claude]

Beyond the inline finding (which I independently reproduced against the pinned 2.13.0 wheel — InsecureKeyLengthWarning fires on both encode and decode for the 30- and 20-byte demo keys and escalates under filterwarnings = ["error"]), I checked the other 2.13.0 behavioral changes against this repo: no PyJWK/PyJWKClient or b64=false/detached-payload usage anywhere in the SDK, and all remaining HS256 call sites (tests/client/auth/extensions/test_client_credentials.py, the caller-supplied keys in src/mcp/client/auth/extensions/client_credentials.py) use ≥32-byte secrets — so the short demo keys are the only affected sites.

Extended reasoning...

This Dependabot PR bumps pyjwt 2.10.1 → 2.13.0 in uv.lock only. The bump itself is a desirable security release, but I empirically verified with the pinned 2.13.0 wheel that its new InsecureKeyLengthWarning fires for the sub-32-byte demo HS256 secrets in docs_src/identity_assertion/ and examples/stories/identity_assertion/, and the repo's filterwarnings = ["error"] (with no jwt-scoped ignore) escalates it to test failures — so merging as-is breaks tests/docs_src/test_identity_assertion.py and the identity_assertion story tests. The inline comment covers that; my note records the additional 2.13.0 behavior changes I checked and ruled out (PyJWK alg binding, PyJWKClient URI schemes, b64=false strictness, empty-key rejection — none are used or all sites use adequate keys) so a later pass need not re-derive them. Not approving because the finding is CI-breaking and requires a companion change (lengthen the demo secrets or add a scoped filter) before merge.

[claude]

🔴 pyjwt 2.13.0 adds jwt.warnings.InsecureKeyLengthWarning (a UserWarning subclass) on jwt.encode()/jwt.decode() when an HMAC key is shorter than 32 bytes for HS256 — and this repo's filterwarnings = ["error"] turns it into hard test failures for the sub-32-byte demo secrets in docs_src/identity_assertion/tutorial001.py/tutorial002.py (30-byte key) and examples/stories/identity_assertion/idp.py (20-byte key), breaking tests/docs_src/test_identity_assertion.py and tests/examples/test_stories.py. Lengthen the demo secrets to ≥32 bytes (better docs hygiene anyway) or add a scoped filterwarnings ignore in the same change before merging.

Extended reasoning...

What the bug is

pyjwt 2.13.0 (new since the 2.10.1 this lock file previously pinned) emits jwt.warnings.InsecureKeyLengthWarning — a UserWarning subclass — from both jwt.encode() and jwt.decode() whenever an HMAC key is shorter than the RFC 7518 §3.2 minimum for the hash (32 bytes for HS256). This behavior did not exist in 2.10.1; it was verified empirically against both wheels: 2.10.1 is silent with the same short keys, while 2.13.0 warns.

This repo runs pytest with filterwarnings = ["error"] (pyproject.toml:251-265). The ignore list only covers pywin32 and three MCPDeprecationWarning patterns — nothing scoped to jwt warnings — so the new warning becomes a hard test error.

The code paths that trigger it

Three sites use sub-32-byte HS256 secrets:

1. docs_src/identity_assertion/tutorial001.py:12 — IDP_SIGNING_KEY = "the-enterprise-idp-signing-key" (30 bytes), used by jwt.encode(..., algorithm="HS256") at line 46.
2. docs_src/identity_assertion/tutorial002.py:24 — same 30-byte key, used by jwt.decode() at line 55 inside exchange_identity_assertion().
3. examples/stories/identity_assertion/idp.py:17 — IDP_SIGNING_KEY = "demo-idp-signing-key" (20 bytes), encoded at idp.py:40 and decoded at examples/stories/identity_assertion/server.py:61.

Tests exercising them:

• tests/docs_src/test_identity_assertion.py — e.g. line 81 calls tutorial001.idp_issue_id_jag() (30-byte encode → warning → error), and line 83 calls jwt.decode() directly with the same key; every test driving tutorial002.provider.exchange_identity_assertion() with a valid assertion hits the decode-side warning too.
• tests/examples/test_stories.py — runs every story's main() in-process under pytest, so the identity_assertion story's 20-byte encode/decode runs under the error filter.

Why nothing prevents it

No conftest.py, pytestmark, pytest.warns, or catch_warnings suppresses this warning anywhere in the identity-assertion tests or demo code. The tests that do use HS256 with long keys (e.g. tests/client/auth/extensions/test_client_credentials.py uses 'a-string-secret-at-least-256-bits-long', 38 bytes) are unaffected — which conveniently demonstrates the fix.

Step-by-step proof

1. Install pyjwt 2.13.0 (the exact wheel pinned by this PR's uv.lock change).
2. Run python -W error::UserWarning -c "import jwt; jwt.encode({'sub': 'x'}, 'the-enterprise-idp-signing-key', algorithm='HS256')".
3. Result: InsecureKeyLengthWarning: The HMAC key is 30 bytes long, which is below the minimum recommended length of 32 bytes for SHA256. See RFC 7518 Section 3.2. raised as an error. The same command against pyjwt 2.10.1 completes silently.
4. Under pytest, filterwarnings = ["error"] applies the same escalation, so tests/docs_src/test_identity_assertion.py::test_the_id_jag_is_a_typed_jwt_carrying_the_claims_the_page_lists fails at the idp_issue_id_jag() call, and the identity_assertion entries in tests/examples/test_stories.py fail at the idp.py:40 encode.
5. Four independent verifiers reproduced this against the actual pinned 2.13.0 wheel from PyPI; all confirmed both the encode and decode paths raise.

Impact and fix

The bump itself is a desirable security release (it bundles five security fixes) and should land — but merging this Dependabot PR as-is (it touches only uv.lock) turns CI red across the docs_src and stories test suites. The fix is small: lengthen the two demo secrets to ≥32 bytes (e.g. "the-enterprise-idp-signing-key-0" / "demo-idp-signing-key-padded-out-32b"), which is better example hygiene anyway since users copy tutorial code verbatim and would otherwise see this warning at runtime. Alternatively, add a scoped ignore::jwt.warnings.InsecureKeyLengthWarning entry to filterwarnings in pyproject.toml — though fixing the keys is preferable to silencing a legitimate security warning in demo code.