Bump pyjwt from 2.12.0 to 2.13.0 in /chat-connector

[dependabot]

Bumps pyjwt from 2.12.0 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

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)
• See full diff 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)

---

Summary by cubic

Upgrade PyJWT from 2.12.0 to 2.13.0 in chat-connector to include recent security fixes and stricter JWT verification. This hardens token validation and blocks algorithm confusion and unsafe JWKS URL schemes.

• Migration
  • Set a non-empty HMAC secret (e.g., JWT_SECRET); empty keys now raise InvalidKeyError.
  • With PyJWK/PyJWKClient, ensure the token header alg matches the JWK’s algorithm; mismatches now fail.
  • Use only http/https JWKS URLs; file://, ftp://, and data: are rejected.

^{Written for commit 5a00a84. Summary will update on new commits. Review in cubic}

Greptile Summary

This is an automated dependency bump of PyJWT from 2.12.0 to 2.13.0 in chat-connector/requirements.txt. Version 2.13.0 is a security release patching five CVEs (algorithm-confusion via HMAC/JWK, algorithm allow-list bypass via PyJWK, DoS via detached-payload decode, SSRF via non-HTTPS PyJWKClient URIs, and cache eviction on fetch error).

• The only JWT usage in this repo is jwt.encode() with RS256 and an RSA private key in lineworks.py; there is no JWT decoding, no HMAC secret, no PyJWKClient, and no b64=false token handling — making all five patched vulnerabilities irrelevant to this codebase.
• None of the breaking behavioral changes in 2.13.0 (empty-HMAC key rejection, PyJWK alg-match enforcement, non-HTTPS URI rejection, per-call enforce_minimum_key_length) affect the existing code paths.

Confidence Score: 5/5

Safe to merge — the codebase only calls jwt.encode() with RS256 and none of the patched vulnerabilities or breaking changes touch that code path.

The change is a single-line version bump to a security-fix release. The only JWT call in the codebase is an RS256 encode in lineworks.py; the five patched CVEs all target decoding paths (HMAC algorithm confusion, PyJWK allow-list bypass, detached-payload DoS, PyJWKClient SSRF, cache eviction), and none of the breaking behavioral changes apply here.

No files require special attention.

Important Files Changed

Filename	Overview
chat-connector/requirements.txt	Single-line bump of PyJWT from 2.12.0 to 2.13.0; no compatibility issues with the codebase's RS256-only encode-only JWT usage.

Sequence Diagram

sequenceDiagram
    participant LW as lineworks.py
    participant PyJWT as PyJWT 2.13.0
    participant LWAuth as LINE WORKS Auth

    LW->>PyJWT: "jwt.encode(claims, private_key, algorithm="RS256")"
    PyJWT-->>LW: signed JWT string
    LW->>LWAuth: "POST /oauth2/v2.0/token (assertion=JWT)"
    LWAuth-->>LW: access_token

Loading

_{Reviews (1): Last reviewed commit: "Bump pyjwt from 2.12.0 to 2.13.0 in /cha..." | Re-trigger Greptile}

[cubic-dev-ai]

No issues found across 1 file

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}