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_keypreviously 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 inalgorithms=[…]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 withPyJWK/PyJWKClient. When verifying with aPyJWK, the caller'salgorithms=[…]allow-list was checked against the token headeralgas a string only; actual verification used the algorithm bound to thePyJWK. An attacker who controlled a registered JWKS key could sign with one algorithm and advertise another on the header. PyJWT now requires the token headeralgto match thePyJWK's algorithm before verification. Reported by@sushi-gif.
GHSA-w7vc-732c-9m39— DoS via base64 decode of unused payload segment whenb64=false. For detached-payload JWS (b64=false), the compact-form payload segment was base64-decoded before being discarded in favor of the caller-supplieddetached_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—PyJWKClientaccepts non-HTTP(S) URIs.PyJWKClient.fetch_datapassed its URI tourllib.request.urlopen, which by default also handlesfile://,ftp://, anddata:schemes. An application that fed an attacker-influenced URI intoPyJWKClientcould be coerced into reading local files or reaching other unintended schemes.PyJWKClientnow rejects any URI whose scheme isn'thttporhttps. Reported by@KEIJOT.
GHSA-fhv5-28vv-h8m8—PyJWKClientcache wiped on fetch error. Afinally-blockput(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_keywithInvalidKeyErrorinstead of accepting them with only a warning. Defends against theos.getenv("JWT_SECRET", "")footgun. Thanks to@SnailSploitand@spartan8806for the reports.- Forward per-call
options(includingenforce_minimum_key_length) fromPyJWT.decodethrough toPyJWS._verify_signature. The option was previously silently dropped between the two layers, so it only took effect when set on thePyJWTinstance. Thanks to@WLUBfor the report.- RFC 7797 §3 compliance for
b64=false: the encoder now auto-adds"b64"tocrit, and the decoder rejects tokens that setb64=falsewithout listing it incrit. Thanks to@MachineLearning-Nerdfor the report.Changed
- Migrate the
dev,docs, andtestspackage extras to dependency groups, by@kurtmckeein #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
""orb""as a secret (often via a missing env var, e.g.os.getenv("JWT_SECRET", "")),encode/decodewill now raiseInvalidKeyError. This is the intended behavior — fix the configuration.PyJWKdecoding now requires the token'salgto match the JWK's algorithm. Previously a mismatch was silently honored if the headeralgappeared in the allow-list. Tokens that relied on this mismatch will now fail withInvalidAlgorithmError.PyJWKClientnow rejects non-HTTP(S) URIs at construction time. Tests or dev environments that fetched JWKS fromfile://URIs need to switch to a local HTTP server or load the JWKS by other means (e.g. constructPyJWKSet.from_dict(...)directly).b64=falsetokens are now strictly RFC 7515 / 7797 compliant. Tokens with a non-empty compact-form payload segment, or that omit"b64"fromcrit, will be rejected. PyJWT-produced tokens always satisfy both invariants, so round-trips through PyJWT are unaffected.enforce_minimum_key_lengthset per-call now takes effect. Callers who passedoptions={"enforce_minimum_key_length": True}tojwt.decode()previously got no enforcement; they will now getInvalidKeyErroron undersized keys, as documented.Full changelog: https://github.com/jpadilla/pyjwt/compare/2.12.1...2.13.0
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 ``"b64"`` 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, andtestspackage extras to dependency groups by@kurtmckeein[#1152](https://github.com/jpadilla/pyjwt/issues/1152) <https://github.com/jpadilla/pyjwt/pull/1152>__
7144e45
Apply ruff formatd2f4bec
Restore cast() calls with cross-version type:
ignore for prepare_key22f478c
Remove redundant casts in RSAAlgorithm.prepare_key and
`ECAlgorithm.prepare...95791b1
Bundle security fixes and hardening into 2.13.0dcc27a9
[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)