Skip to content

[FIX] Patch transitive Python Dependabot alerts (h11, pyarrow, pyjwt, azure-core, protobuf) via uv lock#2039

Open
jaseemjaskp wants to merge 1 commit into
mainfrom
fix/dependabot-python-transitive
Open

[FIX] Patch transitive Python Dependabot alerts (h11, pyarrow, pyjwt, azure-core, protobuf) via uv lock#2039
jaseemjaskp wants to merge 1 commit into
mainfrom
fix/dependabot-python-transitive

Conversation

@jaseemjaskp

@jaseemjaskp jaseemjaskp commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

What

Patches transitive Python Dependabot alerts across 11 uv.lock files via lock-only upgrades (no pyproject.toml / pinned-dependency changes). Each bump here clears at least one alert:

Package Bump Severity Lockfiles
h11 (+ httpcore) 0.14.0 → 0.16.0 (httpcore 1.0.7 → 1.0.9) 🔴 critical (request smuggling) workflow-execution, tool-registry, filesystem
pyarrow 18.1.0 → 24.0.0 high (use-after-free) root, backend, workers, connectors
pyjwt 2.10.x/2.11.0 → 2.13.0 high (unknown crit headers) backend, workers, connectors, sdk1, platform-service, prompt-service
azure-core 1.33/1.35 → 1.41.0 high (untrusted deserialization) connectors, sdk1, platform-service, prompt-service
protobuf 5.29.4 → 5.29.6 / 6.32.1 → 6.33.6 high (JSON recursion DoS) tool-sidecar, sdk1

Why

These are the Python Dependabot alerts whose fix is reachable by a pure lock upgrade — the parent constraints already permit the patched version, so no manifest edit is needed. Kept separate from the pinned-dependency upgrades (Django, Authlib, PyMySQL) which require pyproject.toml changes and heavier testing.

How

  • uv lock --upgrade-package <pkg> per affected service, restricted to packages that actually cross the alert threshold.
  • h11 was held at 0.14.0 by httpcore; bumping httpcore to 1.0.9 (a patch) pulls h11 to the patched 0.16.0.

Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)

Low risk.

  • All 11 locks pass uv lock --check (resolutions valid & consistent — the same check a frozen Docker build runs).
  • Smoke-tested imports: h11 0.16.0 / httpcore 1.0.9 / httpx 0.28.1, and pyarrow 24.0.0 / azure-core / pyjwt 2.13.0 all load cleanly.
  • pyjwt/azure-core/protobuf are minor/patch bumps. pyarrow 18 → 24 is a major jump but it is transitive (data-layer libraries), resolved cleanly, and imports fine — worth a smoke-test in CI/Docker.

Database Migrations

None.

Env Config

None.

Relevant Docs

N/A

Related Issues or PRs

Follows the frontend Dependabot PR (#2038).

Deliberately NOT included (blocked — need a separate AWS/gRPC parent bump)

  • urllib3 → 2.x is held <2 by botocore/boto3 + cloud SDKs (minio, docker, qdrant, etc.). The relevant CVEs have no 1.26.x patch — fixes exist only in 2.x — so clearing them requires upgrading the AWS SDK stack.
  • protobuf → 5.29.6 in root/backend/workers/connectors is held <5 by grpcio/google-* libraries; only a 4.25.9 patch is reachable there, which does not cross the advisory threshold.

These two warrant a dedicated PR (coordinated parent upgrades + testing).

Dependencies Versions

h11 0.16.0 · httpcore 1.0.9 · pyarrow 24.0.0 · pyjwt 2.13.0 · azure-core 1.41.0 · protobuf 5.29.6 / 6.33.6

Notes on Testing

  • uv lock --check across all 11 locks ✓
  • Import smoke tests for h11/httpcore/httpx and pyarrow/azure-core/pyjwt ✓

Screenshots

N/A — lockfile-only.

Checklist

I have read and understood the Contribution Guidelines.

@jaseemjaskp
[FIX] Patch transitive Python Dependabot alerts via uv lock bumps
26d9c32 
Lock-only upgrades (no pyproject changes) that clear Dependabot alerts:
- h11 0.14.0 -> 0.16.0 (+ httpcore 1.0.7 -> 1.0.9) [CRITICAL: request
  smuggling] in workflow-execution, tool-registry, filesystem
- pyarrow 18.1.0 -> 24.0.0 [use-after-free] in root, backend, workers,
  connectors
- pyjwt 2.10.x/2.11.0 -> 2.13.0 [unknown crit headers] in backend,
  workers, connectors, sdk1, platform-service, prompt-service
- azure-core 1.33/1.35 -> 1.41.0 [untrusted deserialization] in
  connectors, sdk1, platform-service, prompt-service
- protobuf 5.29.4 -> 5.29.6 (tool-sidecar) and 6.32.1 -> 6.33.6 (sdk1)
  [JSON recursion DoS]

Verified: all 11 locks pass 'uv lock --check'; h11/httpcore/httpx and
pyarrow/azure-core/pyjwt import cleanly.

NOT included (capped by parents, need a separate AWS/gRPC bump PR):
- urllib3 -> 2.x is held <2 by botocore/boto3 + cloud SDKs (no 1.26.x
  patch exists for these CVEs)
- protobuf -> 5.x in root/backend/workers/connectors is held <5 by
  grpcio/google-* libraries
@greptile-apps

greptile-apps Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

No reviewable files after applying ignore patterns.

@coderabbitai

coderabbitai Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (11)
  • backend/uv.lock is excluded by !**/*.lock
  • platform-service/uv.lock is excluded by !**/*.lock
  • prompt-service/uv.lock is excluded by !**/*.lock
  • tool-sidecar/uv.lock is excluded by !**/*.lock
  • unstract/connectors/uv.lock is excluded by !**/*.lock
  • unstract/filesystem/uv.lock is excluded by !**/*.lock
  • unstract/sdk1/uv.lock is excluded by !**/*.lock
  • unstract/tool-registry/uv.lock is excluded by !**/*.lock
  • unstract/workflow-execution/uv.lock is excluded by !**/*.lock
  • uv.lock is excluded by !**/*.lock
  • workers/uv.lock is excluded by !**/*.lock

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a86ee118-6772-483e-b67c-6cee0cc37f79

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/dependabot-python-transitive

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@github-actions

github-actions Bot commented Jun 11, 2026

Copy link
Copy Markdown
Contributor

Unstract test results

Per-group results

Status Group Tier Passed Failed Errors Skipped Duration (s)
❌ unit-connectors unit 64 12 0 3 18.1
❌ unit-core unit 0 0 2 0 0.9
❌ unit-platform-service unit 9 0 1 0 1.1
✅ unit-prompt-service unit 15 0 0 0 18.4
✅ unit-rig unit 53 0 0 0 2.6
✅ unit-runner unit 11 0 0 0 4.6
✅ unit-sdk1 unit 390 0 0 0 17.6
❌ unit-tool-registry unit 0 0 1 0 1.1
⚪ unit-workers unit 0 0 0 0 13.8
TOTAL 542 12 4 3 78.3

Critical paths

⚠️ Critical paths not yet covered

  • auth-login — User can log in and obtain a session cookie. (entry: POST /api/v1/auth/login; declared coverage: no groups declared)
  • adapter-register-llm — Register and validate an LLM adapter. (entry: POST /api/v1/adapter/; declared coverage: no groups declared)
  • workflow-create-execute — Create a workflow, configure source+destination, execute, poll, fetch result. (entry: POST /api/v1/workflow/{id}/execute/; declared coverage: e2e-workflow)
  • api-deployment-run — Deploy a workflow as an API, POST a document, receive structured JSON. (entry: POST /deployment/api/{org}/{name}/; declared coverage: e2e-api-deployment)
  • prompt-studio-fetch-response — Prompt Studio: create project, add prompt, run single-pass, get response. (entry: POST /api/v1/prompt-studio/prompt-studio-tool/{id}/fetch_response/; declared coverage: e2e-prompt-studio)
  • pipeline-etl-execute — Run an ETL pipeline from source connector to destination. (entry: POST /api/v1/pipeline/{id}/execute/; declared coverage: no groups declared)
  • usage-token-tracking — Per-execution token usage is recorded and retrievable. (entry: GET /api/v1/usage/get_token_usage/; declared coverage: no groups declared)
  • workflow-execution-fan-out — Multi-file workflow execution fans out to file-processing workers and rejoins. (entry: internal: backend → rabbitmq → workers/file_processing; declared coverage: no groups declared)
  • callback-result-delivery — Async results are posted back via the callback worker. (entry: internal: workers/callback → backend /internal endpoints; declared coverage: no groups declared)
✅ Covered critical paths
  • tool-sandbox-exec — covered by unit-runner

@sonarqubecloud

sonarqubecloud Bot commented Jun 11, 2026

Copy link
Copy Markdown

Quality Gate Passed Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

@jaseemjaskp jaseemjaskp mentioned this pull request Jun 11, 2026
Open
This was referenced Jun 11, 2026
Open
Open
jaseemjaskp
jaseemjaskp commented Jun 12, 2026
View reviewed changes

@jaseemjaskp jaseemjaskp left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Review — transitive Dependabot lock bumps (#2039)

Scope: lock-only PR — 11 uv.lock files, 6 packages (h11, httpcore, pyarrow, pyjwt, azure-core, protobuf). No pyproject.toml/source/comment/type changes.

What I verified (✅):

  • uv lock --check passes on sampled locks (backend, workers, sdk1, filesystem) — the "verified" claim holds.
  • Each version bump carries regenerated sdist+wheel sha256 blocks (not just version strings); no specifier = constraint edits → a clean resolution-only bump.
  • Commit-message package/target matrix matches the diff exactly.

Repo-wide residual-version audit (every uv.lock at HEAD vs. advisory fix version):

Package CVE Fix version Residual state Verdict
h11 / httpcore CVE-2025-43859 (req smuggling) 0.16.0 / 1.0.9 all 14 locks at 0.16.0 / 1.0.9 ✅ clear
pyarrow use-after-free 24.0.0 all 4 locks that carry it at 24.0.0 ✅ clear (see note)
pyjwt CVE-2026-32597 (crit headers) 2.12.0 root uv.lock left at 2.12.1; rest 2.13.0 ✅ safe (≥2.12.0) — cosmetic skew
azure-core CVE-2026-21226 (deser RCE) 1.38.0 backend/workers left at 1.38.2; rest 1.41.0 ✅ safe (≥1.38.0) — cosmetic skew
protobuf CVE-2025-4565 (recursion DoS) 4.25.8 / 5.29.5 / 6.31.1 unstract/connectors at 4.25.6 ⚠️ still vulnerable

🔴 One real residual gap (see inline comment): unstract/connectors/uv.lock still pins protobuf 4.25.6, below the 4.25.8 fix for CVE-2025-4565. The commit's "held <5 by grpcio/google-*" rationale is accurate about the major cap but 4.25.8 is itself a 4.x release within that cap — backend & workers already resolve 4.25.8 under the same grpcio stack, so connectors should reach it too. This is a reachable-but-missed patch.

🟡 Worth a look: pyarrow jumps 18.1.0 → 24.0.0 (six major versions) as a transitive bump. uv lock --check passes so the constraint allows it, but a jump this large warrants a parquet read/write smoke test on backend/workers/connectors, and a check of whether a smaller patched release clears the CVE with less breakage surface.

Benign skews (no action needed): root pyjwt 2.12.1 and backend/workers azure-core 1.38.2 both sit above their advisory fix lines — they explain why Dependabot didn't push those locks. Standardizing them to 2.13.0 / 1.41.0 is optional tidiness, not security.

On the PR Review Toolkit agents: this PR is generated lock files only, so Silent-Failure-Hunter, Type-Design-Analyzer, Comment-Analyzer, and Code-Simplifier have no source/types/comments/logic to analyze (N/A). PR-Test-Analyzer: lock bumps have no unit coverage — CI dependency-install + a smoke run is the effective test gate. The Code-Reviewer pass is the dependency-correctness audit above.

Comment thread unstract/connectors/uv.lock
[[package]]
name = "azure-core"
version = "1.33.0"
version = "1.41.0"

@jaseemjaskp jaseemjaskp Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 Residual CVE — protobuf not patched in this lock.

This PR bumps azure-core/pyarrow/pyjwt here, but unstract/connectors/uv.lock still pins protobuf 4.25.6. CVE-2025-4565 (uncontrolled recursion → DoS in the pure-Python backend) is fixed in 4.25.8 / 5.29.5 / 6.31.1.

The commit message lists connectors' protobuf as "held <5 by grpcio/google-*" and excludes it — but 4.25.8 is a 4.x release inside that <5 cap. backend/uv.lock and workers/uv.lock already resolve protobuf 4.25.8 under the same grpcio/google stack, so connectors should be able to as well.

Suggested fix: in unstract/connectors, run uv lock --upgrade-package protobuf and confirm it lands on ≥4.25.8, then re-run uv lock --check.

Comment thread backend/uv.lock
[[package]]
name = "pyarrow"
version = "18.1.0"
version = "24.0.0"

@jaseemjaskp jaseemjaskp Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 pyarrow 18.1.0 → 24.0.0 is a six-major-version jump (same in root, workers, connectors). It's purely transitive and uv lock --check passes, so the constraint allows it — but a jump this large can carry API/behaviour changes.

  • Please run a parquet read/write smoke test on the backend/workers/connectors paths that touch pyarrow before merge.
  • Optional: check whether the pyarrow use-after-free was fixed in an earlier release (e.g. 19/20.x) that would clear the alert with a smaller blast radius.

Comment thread uv.lock
[[package]]
name = "pyarrow"
version = "18.1.0"
version = "24.0.0"

@jaseemjaskp jaseemjaskp Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ℹ️ Root lock's only change is pyarrow → 24.0.0. Note root pyjwt stays at 2.12.1 and root azure-core is 1.41.0 — both ≥ their CVE fix versions (2.12.0 / 1.38.0), so this lock is clean. No action; flagging for the audit trail.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@muhammad-ali-e muhammad-ali-e Awaiting requested review from muhammad-ali-e

@chandrasekharan-zipstack chandrasekharan-zipstack Awaiting requested review from chandrasekharan-zipstack

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@jaseemjaskp