Skip to content

Bump the uv group across 11 directories with 4 updates#2063

Closed
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/uv-53d041eae0
Closed

Bump the uv group across 11 directories with 4 updates#2063
dependabot[bot] wants to merge 1 commit into
mainfrom
dependabot/uv/uv-53d041eae0

Conversation

@dependabot

@dependabot dependabot Bot commented on behalf of github Jun 16, 2026

Copy link
Copy Markdown
Contributor

Bumps the uv group with 2 updates in the / directory: pyarrow and pyjwt.
Bumps the uv group with 3 updates in the /backend directory: pyarrow, pyjwt and pypdf.
Bumps the uv group with 2 updates in the /platform-service directory: pyjwt and pypdf.
Bumps the uv group with 2 updates in the /prompt-service directory: pyjwt and pypdf.
Bumps the uv group with 1 update in the /tool-sidecar directory: protobuf.
Bumps the uv group with 3 updates in the /unstract/connectors directory: pyarrow, pyjwt and pypdf.
Bumps the uv group with 1 update in the /unstract/filesystem directory: pypdf.
Bumps the uv group with 3 updates in the /unstract/sdk1 directory: protobuf, pyjwt and pypdf.
Bumps the uv group with 1 update in the /unstract/tool-registry directory: pypdf.
Bumps the uv group with 1 update in the /unstract/workflow-execution directory: pypdf.
Bumps the uv group with 3 updates in the /workers directory: pyarrow, pyjwt and pypdf.

Updates pyarrow from 18.1.0 to 23.0.1

Release notes

Sourced from pyarrow's releases.

Apache Arrow 23.0.1

Release Notes URL: https://arrow.apache.org/release/23.0.1.html

Apache Arrow 23.0.1 RC0

Release Notes: Release Candidate: 23.0.1 RC0

Apache Arrow 23.0.0

Release Notes URL: https://arrow.apache.org/release/23.0.0.html

Apache Arrow 23.0.0 RC2

Release Notes: Release Candidate: 23.0.0 RC2

Apache Arrow 22.0.0

Release Notes URL: https://arrow.apache.org/release/22.0.0.html

Apache Arrow 22.0.0 RC1

Release Notes: Release Candidate: 22.0.0 RC1

Apache Arrow 22.0.0 RC0

Release Notes: Release Candidate: 22.0.0 RC0

Apache Arrow 21.0.0

Release Notes URL: https://arrow.apache.org/release/21.0.0.html

Apache Arrow 21.0.0 RC6

Release Notes: Release Candidate: 21.0.0 RC6

Apache Arrow 21.0.0 RC5

Release Notes: Release Candidate: 21.0.0 RC5

Apache Arrow 21.0.0 RC4

Release Notes: Release Candidate: 21.0.0 RC4

Apache Arrow 21.0.0 RC3

Release Notes: Release Candidate: 21.0.0 RC3

Apache Arrow 21.0.0 RC2

Release Notes: Release Candidate: 21.0.0 RC2

Apache Arrow 20.0.0

Release Notes URL: https://arrow.apache.org/release/20.0.0.html

Apache Arrow 20.0.0 RC2

Release Notes: Release Candidate: 20.0.0 RC2

Apache Arrow 20.0.0 RC1

Release Notes: Release Candidate: 20.0.0 RC1

Apache Arrow 20.0.0 RC0

Release Notes: Release Candidate: 20.0.0 RC0

... (truncated)

Commits

Updates pyjwt from 2.12.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-p5m4PyJWKClient 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-h8m8PyJWKClient 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

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;__
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)
  • See full diff in compare view

Updates pyarrow from 18.1.0 to 23.0.1

Release notes

Sourced from pyarrow's releases.

Apache Arrow 23.0.1

Release Notes URL: https://arrow.apache.org/release/23.0.1.html

Apache Arrow 23.0.1 RC0

Release Notes: Release Candidate: 23.0.1 RC0

Apache Arrow 23.0.0

Release Notes URL: https://arrow.apache.org/release/23.0.0.html

Apache Arrow 23.0.0 RC2

Release Notes: Release Candidate: 23.0.0 RC2

Apache Arrow 22.0.0

Release Notes URL: https://arrow.apache.org/release/22.0.0.html

Apache Arrow 22.0.0 RC1

Release Notes: Release Candidate: 22.0.0 RC1

Apache Arrow 22.0.0 RC0

Release Notes: Release Candidate: 22.0.0 RC0

Apache Arrow 21.0.0

Release Notes URL: https://arrow.apache.org/release/21.0.0.html

Apache Arrow 21.0.0 RC6

Release Notes: Release Candidate: 21.0.0 RC6

Apache Arrow 21.0.0 RC5

Release Notes: Release Candidate: 21.0.0 RC5

Apache Arrow 21.0.0 RC4

Release Notes: Release Candidate: 21.0.0 RC4

Apache Arrow 21.0.0 RC3

Release Notes: Release Candidate: 21.0.0 RC3

Apache Arrow 21.0.0 RC2

Release Notes: Release Candidate: 21.0.0 RC2

Apache Arrow 20.0.0

Release Notes URL: https://arrow.apache.org/release/20.0.0.html

Apache Arrow 20.0.0 RC2

Release Notes: Release Candidate: 20.0.0 RC2

Apache Arrow 20.0.0 RC1

Release Notes: Release Candidate: 20.0.0 RC1

Apache Arrow 20.0.0 RC0

Release Notes: Release Candidate: 20.0.0 RC0

... (truncated)

Commits

Updates pyjwt from 2.11.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-p5m4PyJWKClient 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-h8m8PyJWKClient 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

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;__
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)
  • See full diff in compare view

Updates pypdf from 6.10.2 to 6.13.0

Release notes

Sourced from pypdf's releases.

Version 6.13.0, 2026-06-05

What's new

Security (SEC)

New Features (ENH)

Robustness (ROB)

Maintenance (MAINT)

Full Changelog

Version 6.12.2, 2026-05-26

What's new

Security (SEC)

Full Changelog

Version 6.12.1, 2026-05-22

What's new

Security (SEC)

Robustness (ROB)

Full Changelog

Version 6.12.0, 2026-05-21

What's new

Security (SEC)

New Features (ENH)

... (truncated)

Changelog

Sourced from pypdf's changelog.

Version 6.13.0, 2026-06-05

Security (SEC)

  • Avoid infinite loops for outlines and text extraction (#3830)

New Features (ENH)

  • Add Japanese predefined CMaps (#3800)
  • Font: Collect all character widths, not only those that can be unicode mapped (#3798)

Robustness (ROB)

  • Recover a corrupt trailing startxref pointer (closes #3238) (#3826)
  • Handle /Pages node without /Kids during flattening (#3825)
  • Accept inline image EI marker at the end of a content stream (#3827)

Maintenance (MAINT)

  • Type the always-raising deprecation helpers as NoReturn (#3819)

Full Changelog

Version 6.12.2, 2026-05-26

Security (SEC)

  • Optimize _decode_png_prediction regarding memory and speed (#3806)
  • Improve loop control in text extraction (#3805)

Full Changelog

Version 6.12.1, 2026-05-22

Security (SEC)

  • Limit input size and element count for XMP metadata (#3796)

Robustness (ROB)

  • Prevent cyclic parent hierarchies for inherited dictionaries (#3795)
  • Deal with invalid first code in LZW decoder (#3794)

Full Changelog

Version 6.12.0, 2026-05-21

Security (SEC)

  • Disallow cross-reference streams with zero-only width values (#3791)
  • Avoid excessive whitespace in layout mode text extraction (#3790)

New Features (ENH)

  • Implement SASLprep (RFC 4013) for AES-256 password normalization (#3780)
  • CID font resource from font file to encode more characters (#3652)

Performance Improvements (PI)

  • Optimize retrieval of named destinatinos in reader (#3442)

... (truncated)

Commits
  • 98afb45 REL: 6.13.0
  • 68822de SEC: Avoid infinite loops for outlines and text extraction (#3830)
  • ddd3485 ROB: Recover a corrupt trailing startxref pointer (closes #3238) (#3826)
  • 5cebe5e ROB: Handle /Pages node without /Kids during flattening (#3825)
  • be173fe ROB: Accept inline image EI marker at the end of a content stream (#3827)
  • e0d443c ROB: Handle object numbers above 2**31 in _make_crypt_filter (#3824)
  • dad0f5e ROB: Stop reading past truncated /Nums in get_label_from_nums (#3823)
  • 52545c5 ROB: Pad truncated data in bits2byte instead of reading out of bounds (#3820)
  • 56e0784 ENH: Add Japanese predefined CMaps (#3800)
  • 0d048ee MAINT: Add ABC as a base class (#3818)
  • Additional commits viewable in compare view

Updates 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-p5m4PyJWKClient 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-h8m8PyJWKClient 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

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;__
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)
  • See full diff in compare view

Updates pypdf from 6.10.2 to 6.13.0

Release notes

Sourced from pypdf's releases.

Version 6.13.0, 2026-06-05

What's new

Security (SEC)

New Features (ENH)

Robustness (ROB)

Maintenance (MAINT)

Full Changelog

Version 6.12.2, 2026-05-26

What's new

Security (SEC)

Full Changelog

Version 6.12.1, 2026-05-22

What's new

Security (SEC)

Robustness (ROB)

Full Changelog

Version 6.12.0, 2026-05-21

What's new

Security (SEC)

New Features (ENH)

... (truncated)

Changelog

Sourced from pypdf's changelog.

Version 6.13.0, 2026-06-05

Security (SEC)

  • Avoid infinite loops for outlines and text extraction (#3830)

New Features (ENH)

  • Add Japanese predefined CMaps (#3800)
  • <...

    Description has been truncated

Bumps the uv group with 2 updates in the / directory: [pyarrow](https://github.com/apache/arrow) and [pyjwt](https://github.com/jpadilla/pyjwt).
Bumps the uv group with 3 updates in the /backend directory: [pyarrow](https://github.com/apache/arrow), [pyjwt](https://github.com/jpadilla/pyjwt) and [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 2 updates in the /platform-service directory: [pyjwt](https://github.com/jpadilla/pyjwt) and [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 2 updates in the /prompt-service directory: [pyjwt](https://github.com/jpadilla/pyjwt) and [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 1 update in the /tool-sidecar directory: [protobuf](https://github.com/protocolbuffers/protobuf).
Bumps the uv group with 3 updates in the /unstract/connectors directory: [pyarrow](https://github.com/apache/arrow), [pyjwt](https://github.com/jpadilla/pyjwt) and [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 1 update in the /unstract/filesystem directory: [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 3 updates in the /unstract/sdk1 directory: [protobuf](https://github.com/protocolbuffers/protobuf), [pyjwt](https://github.com/jpadilla/pyjwt) and [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 1 update in the /unstract/tool-registry directory: [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 1 update in the /unstract/workflow-execution directory: [pypdf](https://github.com/py-pdf/pypdf).
Bumps the uv group with 3 updates in the /workers directory: [pyarrow](https://github.com/apache/arrow), [pyjwt](https://github.com/jpadilla/pyjwt) and [pypdf](https://github.com/py-pdf/pypdf).


Updates `pyarrow` from 18.1.0 to 23.0.1
- [Release notes](https://github.com/apache/arrow/releases)
- [Commits](apache/arrow@apache-arrow-18.1.0...apache-arrow-23.0.1)

Updates `pyjwt` from 2.12.1 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pyarrow` from 18.1.0 to 23.0.1
- [Release notes](https://github.com/apache/arrow/releases)
- [Commits](apache/arrow@apache-arrow-18.1.0...apache-arrow-23.0.1)

Updates `pyjwt` from 2.11.0 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `pyjwt` from 2.10.1 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `pyjwt` from 2.10.1 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `protobuf` from 5.29.4 to 5.29.6
- [Release notes](https://github.com/protocolbuffers/protobuf/releases)
- [Commits](https://github.com/protocolbuffers/protobuf/commits)

Updates `pyarrow` from 18.1.0 to 23.0.1
- [Release notes](https://github.com/apache/arrow/releases)
- [Commits](apache/arrow@apache-arrow-18.1.0...apache-arrow-23.0.1)

Updates `pyjwt` from 2.10.1 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `protobuf` from 6.32.1 to 6.33.5
- [Release notes](https://github.com/protocolbuffers/protobuf/releases)
- [Commits](https://github.com/protocolbuffers/protobuf/commits)

Updates `pyjwt` from 2.10.1 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

Updates `pyarrow` from 18.1.0 to 23.0.1
- [Release notes](https://github.com/apache/arrow/releases)
- [Commits](apache/arrow@apache-arrow-18.1.0...apache-arrow-23.0.1)

Updates `pyjwt` from 2.11.0 to 2.13.0
- [Release notes](https://github.com/jpadilla/pyjwt/releases)
- [Changelog](https://github.com/jpadilla/pyjwt/blob/master/CHANGELOG.rst)
- [Commits](jpadilla/pyjwt@2.12.1...2.13.0)

Updates `pypdf` from 6.10.2 to 6.13.0
- [Release notes](https://github.com/py-pdf/pypdf/releases)
- [Changelog](https://github.com/py-pdf/pypdf/blob/main/CHANGELOG.md)
- [Commits](py-pdf/pypdf@6.10.2...6.13.0)

---
updated-dependencies:
- dependency-name: pyarrow
  dependency-version: 23.0.1
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyarrow
  dependency-version: 23.0.1
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: protobuf
  dependency-version: 5.29.6
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyarrow
  dependency-version: 23.0.1
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: protobuf
  dependency-version: 6.33.5
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyarrow
  dependency-version: 23.0.1
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pyjwt
  dependency-version: 2.13.0
  dependency-type: indirect
  dependency-group: uv
- dependency-name: pypdf
  dependency-version: 6.13.0
  dependency-type: indirect
  dependency-group: uv
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot Bot added dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code labels Jun 16, 2026
@greptile-apps

greptile-apps Bot commented Jun 16, 2026

Copy link
Copy Markdown
Contributor

PR author is in the excluded authors list.

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@sonarqubecloud

Copy link
Copy Markdown

@dependabot @github

dependabot Bot commented on behalf of github Jun 18, 2026

Copy link
Copy Markdown
Contributor Author

Looks like these dependencies are updatable in another way, so this is no longer needed.

@dependabot dependabot Bot closed this Jun 18, 2026
@dependabot dependabot Bot deleted the dependabot/uv/uv-53d041eae0 branch June 18, 2026 13:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

dependencies Pull requests that update a dependency file python:uv Pull requests that update python:uv code

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant