build(deps): Bump pyjwt from 2.9.0 to 2.14.0

[dependabot]

Bumps pyjwt from 2.9.0 to 2.14.0.

Release notes

Sourced from pyjwt's releases.

PyJWT 2.14.0

See the 2.14.0 changelog for the complete release details and related security advisories.

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

... (truncated)

Changelog

Sourced from pyjwt's changelog.

v2.14.0 <https://github.com/jpadilla/pyjwt/compare/2.13.0...2.14.0>__

Security

- Harden HMAC key validation against public-key material supplied as JWK,
  JWKS, array, encoded, BOM-prefixed, DER, or PEM input. See
  `GHSA-r6x4-923q-g947 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-r6x4-923q-g947>`__,
  `GHSA-ffc3-869f-jxw9 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-ffc3-869f-jxw9>`__,
  `GHSA-p4g4-x82p-q773 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-p4g4-x82p-q773>`__,
  and `GHSA-w2cx-738m-mc7w <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-w2cx-738m-mc7w>`__.
- Reject automatic redirects when ``PyJWKClient`` fetches a JWKS, preventing
  redirected destinations from being treated as trusted key sources. See
  `GHSA-9v7f-9g4p-ffgj <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-9v7f-9g4p-ffgj>`__.
- Limit repeated JWKS refreshes caused by unknown key IDs while preserving
  normal key-rotation behavior. See
  `GHSA-2gx3-rcp4-g85q <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-2gx3-rcp4-g85q>`__.
- Handle deeply nested and malformed JWS/JWK input without uncaught recursion
  errors or whole-set parsing failures. See
  `GHSA-8wjv-2p76-3863 <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-8wjv-2p76-3863>`__
  and `GHSA-w6j9-cwv2-h6wq <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-w6j9-cwv2-h6wq>`__.
- Enforce compact JWS encoding rules during decoding. See
  `GHSA-hxm8-2xgr-2p9m <https://github.com/jpadilla/pyjwt/security/advisories/GHSA-hxm8-2xgr-2p9m>`__.
- Reject detached-payload arguments for attached JWS inputs. Thanks to `@xclow3n
  <https://github.com/xclow3n>`__ for reporting this behavior; fixed in commit
  `37b54877 <https://github.com/jpadilla/pyjwt/commit/37b54877bf7bea67e8149130e96929e3ec798122>`__.
Fixed

- Apply HMAC key validation consistently when keys are loaded through
  ``PyJWK`` and ``PyJWKClient``. See
  `GHSA-pxh4-856f-4h89 &lt;https://github.com/jpadilla/pyjwt/security/advisories/GHSA-pxh4-856f-4h89&gt;`__.
- Reject empty HMAC keys when represented as JWKs.
  See `GHSA-pxh4-856f-4h89 &lt;https://github.com/jpadilla/pyjwt/security/advisories/GHSA-pxh4-856f-4h89&gt;`__.
Fixed



Raise the documented PyJWTError subclass instead of leaking a
TypeError when the exp, nbf, or iat claim decodes to a
non-numeric, non-string value such as a list, dict, or null.

v2.13.0 &lt;https://github.com/jpadilla/pyjwt/compare/2.12.1...2.13.0&gt;__
Security

... (truncated)

Commits

• c6fe464 release: prepare v2.14.0
• f541302 style: apply Ruff formatting
• 801cd12 fix: reject public JWK container HMAC keys
• af8181c fix: reject empty HMAC keys from JWKs
• ba4853a Throttle repeated PyJWKClient refreshes
• 2798504 fix: reject DER public keys as HMAC secrets
• 8b4e233 fix: reject loader-accepted PEM variants
• 1f8180a fix: format JWS tests
• cff1ac5 Fix redirect handler return annotation
• 0a795b8 Reject redirects in PyJWKClient fetches
• 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)