From 86add8656251bc30bab0af4a9e64a64864726741 Mon Sep 17 00:00:00 2001
From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com>
Date: Mon, 15 Jun 2026 14:53:05 -0400
Subject: [PATCH] chore: bump pyjwt from 2.12.0 to 2.13.0 in /libs/langchain_v1
(#38168)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Bumps [pyjwt](https://github.com/jpadilla/pyjwt) from 2.12.0 to 2.13.0.
Sourced from pyjwt's
releases. This release bundles five security fixes plus three additional
hardening / spec-compliance changes. We recommend all users upgrade. Most fixes are invisible to correctly-configured callers. A few
behavioral changes you may encounter: Full changelog: https://github.com/jpadilla/pyjwt/compare/2.12.1...2.13.0 Full Changelog: https://github.com/jpadilla/pyjwt/compare/2.12.0...2.12.1 Sourced from pyjwt's
changelog. Security FixedRelease notes
2.13.0
PyJWT 2.13.0 — Security Release
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
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.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.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
dev, docs, and
tests package extras to dependency groups, by @kurtmckee in #1152.Upgrade notes
"" 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.2.12.1
What's Changed
@jpadilla in jpadilla/pyjwt#1151Changelog
v2.13.0
<https://github.com/jpadilla/pyjwt/compare/2.12.1...2.13.0>__
- 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>`__.
- 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
dev, docs, and
tests package extras to dependency groups by @kurtmckee in
[#1152](https://github.com/jpadilla/pyjwt/issues/1152)
<https://github.com/jpadilla/pyjwt/pull/1152>__v2.12.1
<https://github.com/jpadilla/pyjwt/compare/2.12.0...2.12.1>__
</tr></table>
... (truncated)
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)a4e1a3d
Add typing_extensions dependency for Python < 3.11 (#1151)