[HOTFIX] Bump litellm to 1.83.10 from PyPI to clear CVE-2026-42208 by pk-zipstack · Pull Request #1976 · Zipstack/unstract

pk-zipstack · 2026-05-20T07:05:27Z

Hotfix for cloud v0.159.3 → OSS v0.163.4
Following the Hotfix Deployment Guide. This is Scenario 2 (OSS-only changes). After merge, please cut a new GitHub release (e.g. v0.163.5) targeting the v0.163.4-hotfix branch, then back-merge to main per Step 9.

Summary

Bumps litellm from 1.82.3 (Zipstack GitHub fork) to 1.83.10 from PyPI, clearing CVE-2026-42208 (SQL injection in litellm proxy auth — affects 1.81.16–1.83.6) as reported by a customer scanner.
We do not use litellm.proxy, but scanners flag the installed package regardless. 1.83.10 is the exact version recommended in the upstream advisory (v1.83.10-stable) and the smallest jump that clears the CVE range while keeping python-dotenv==1.0.1 compatible across the workspace.
Reverses the temporary GitHub-fork sourcing from [FIX] Switch litellm to Zipstack fork after PyPI quarantine #1873 now that the PyPI quarantine is over.
Bumps tiktoken 0.9 → 0.12 (required by litellm's pin) — only constraint that needed to move.

Cohere embed timeout patch

unstract/sdk1/src/unstract/sdk1/patches/litellm_cohere_timeout.py (added in #1848) is version-guarded to one exact litellm release. Before bumping the guard:

Diffed upstream litellm/llms/cohere/embed/handler.py at v1.82.3, v1.83.10-stable, and v1.83.14-stable via gh api — byte-identical across all three.
Confirmed the bug is still present at 1.83.10 (client.post() doesn't forward timeout in either embedding() or async_embedding()).
Confirmed [Bug]: "litellm.Timeout: Connection timed out after None seconds. " BerriAI/litellm#14635 is still OPEN upstream.
6/6 patch unit tests (tests/patches/test_litellm_cohere_timeout.py) pass on 1.83.10 — the suite asserts client.post() receives the timeout kwarg, so green = patch is binding and behaving against the new module.

Guard bumped 1.82.3 → 1.83.10; patch keeps doing real work.

Other cleanup from #1873

Removed git apt-install from worker-unified and the three tool Dockerfiles (no git-sourced deps remain in any uv.lock).
Bumped tool versions: structure 0.0.100 → 0.0.101, classifier 0.0.79 → 0.0.80, text_extractor 0.0.75 → 0.0.76 (with matching updates in public_tools.json and backend/sample.env).

Note on root `uv.lock` churn

The v0.163.4 root uv.lock had a pre-existing corruption (banks v2.4.1 entry pointing at banks-2.2.0 wheel) that blocked incremental resolution. Regenerated from scratch, which produces a large but mechanical diff. All other uv.lock files updated incrementally.

Test plan

uv run pytest unstract/sdk1/tests/patches/test_litellm_cohere_timeout.py → 6 passed, confirms patch is active (_SKIP_PATCH=False) and timeout is forwarded correctly on 1.83.10
uv lock clean across root, backend, prompt-service, platform-service, workers, sdk1, filesystem, tool-registry — all now source = { registry = "https://pypi.org/simple" } for litellm
Verified no litellm.proxy imports anywhere in the codebase
CI on hotfix base: docker image builds for worker-unified + 3 tool containers
Staging: smoke test prompt-studio extraction end-to-end on a representative document
Staging: AWS Bedrock Cohere embeddings (regression check for the patch)

🤖 Generated with Claude Code

Hotfix for cloud v0.159.3 (OSS v0.163.4). Customer scanner flagged litellm 1.82.3 for CVE-2026-42208 (SQL injection in litellm proxy auth path, affects 1.81.16-1.83.6). We do not use litellm.proxy, but vulnerability scanners flag the installed package regardless of which code path is reachable. Bump to 1.83.10 — the exact version recommended by the upstream advisory (v1.83.10-stable) and the smallest jump that clears the CVE range while keeping python-dotenv==1.0.1 compatible (1.83.14 would force bumping python-dotenv across 7+ pyproject.toml files). Only tiktoken needed to move 0.9 -> 0.12 to satisfy litellm's pin. Switch source back to PyPI now that the PyPI quarantine is over, reversing the temporary fork in #1873. Cohere embed timeout patch: verified that litellm/llms/cohere/embed/handler.py is byte-identical between v1.82.3, v1.83.10-stable, and v1.83.14-stable (the timeout-not-forwarded bug fixed in #1848 is still present upstream — BerriAI/litellm#14635 remains OPEN). Version guard bumped 1.82.3 -> 1.83.10; 6/6 patch tests pass on the new version, confirming the monkey-patch still binds correctly. Other cleanup from #1873: - Drop git apt-install from worker-unified and tool Dockerfiles (no git-sourced deps remain in any uv.lock) - Bump tool versions: structure 0.0.100 -> 0.0.101, classifier 0.0.79 -> 0.0.80, text_extractor 0.0.75 -> 0.0.76 Note on root uv.lock churn: the v0.163.4 root uv.lock had a pre-existing corruption (banks v2.4.1 entry pointing at banks-2.2.0 wheel) that blocked incremental resolution. Regenerated from scratch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

coderabbitai · 2026-05-20T07:05:35Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3652baf3-1321-4b23-9aaf-6f9fa81ee038

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/litellm-cve-pypi-hotfix

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.}

sonarqubecloud · 2026-05-20T07:06:35Z

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

greptile-apps · 2026-05-20T07:08:38Z

Greptile Summary

This hotfix bumps litellm from the Zipstack GitHub fork at 1.82.3 to PyPI 1.83.10, clearing CVE-2026-42208 (SQL injection in litellm proxy auth). The change is well-scoped and consistent across all lock files and Dockerfiles.

pyproject.toml replaces the git-source override with a strict PyPI pin (litellm==1.83.10) and bumps tiktoken from ~0.9.0 to ~0.12.0 to satisfy the new dependency graph.
The litellm_cohere_timeout.py monkey-patch has its version guard updated from 1.82.3 to 1.83.10; the PR documents that the upstream Cohere timeout bug is still present in this release and all six patch unit tests pass against it.
git is removed from the apt-get install lists in the worker and three tool Dockerfiles (no longer needed since no git-sourced deps remain), and tool image versions are bumped consistently across properties.json, public_tools.json, and sample.env.

Confidence Score: 4/5

Safe to merge. All lock files and Dockerfiles are updated consistently, the patch guard aligns with the pinned version, and 6/6 patch tests pass.

The dependency swap from a git fork to PyPI is clean and consistent across every workspace lock file. The Cohere timeout patch guard is tied to an exact version that matches the pin in pyproject.toml, so it will always fire correctly in this release. The one thing worth watching is that the guard is exact-equality only — a future litellm bump for another CVE will silently disable the timeout fix unless the guard is updated at the same time.

The version guard constant in unstract/sdk1/src/unstract/sdk1/patches/litellm_cohere_timeout.py needs to be updated whenever litellm is next bumped.

Important Files Changed

Filename	Overview
unstract/sdk1/pyproject.toml	Replaces git-sourced litellm with exact PyPI pin 1.83.10 and bumps tiktoken constraint to ~0.12.0; removes the uv.sources override cleanly.
unstract/sdk1/src/unstract/sdk1/patches/litellm_cohere_timeout.py	Version guard bumped to 1.83.10 with updated docstring; patch body unchanged. Exact-equality guard will emit a warning and skip the fix silently if litellm is ever upgraded without updating this constant.
docker/dockerfiles/worker-unified.Dockerfile	Removes git from apt-get dependencies; no other changes.
tools/classifier/Dockerfile	Removes git from apt-get install; consistent with no longer having any git-sourced Python dependencies.
uv.lock	Regenerated from scratch due to a pre-existing banks entry corruption; litellm switches from git source to PyPI 1.83.10 wheel. Large mechanical diff with no hand-edited entries.
unstract/tool-registry/tool_registry_config/public_tools.json	Bumps classifier to 0.0.80 and text_extractor to 0.0.76; structure tool is not listed in this file and does not need an entry here.
backend/sample.env	Structure tool image bumped to 0.0.101 consistently with properties.json.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[litellm_cohere_timeout.py imported] --> B{Version check
_litellm_version == 1.83.10?}
    B -->|Match| C[Apply monkey-patch
cohere_handler.async_embedding
cohere_handler.embedding
bedrock_embed.cohere_embedding]
    B -->|No match| D[_SKIP_PATCH = True
logger.warning emitted
No patch applied]
    C --> E[Bedrock Cohere
embedding calls
forward timeout correctly]
    D --> F[Bedrock Cohere
client.post receives
timeout=None - error]
    G[pyproject.toml
litellm==1.83.10 exact pin] -->|resolves to| H[PyPI 1.83.10
installed]
    H --> B

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
unstract/sdk1/src/unstract/sdk1/patches/litellm_cohere_timeout.py:30-32
**Silent skip when litellm is next bumped**

The version guard uses strict equality (`Version(_litellm_version) != Version(_PATCHED_LITELLM_VERSION)`), so any future litellm upgrade (e.g. for another CVE) will silently disable the Cohere timeout fix — Bedrock Cohere embeddings will start failing with "Connection timed out after None seconds" again. The only signal is a `logger.warning`, which may not surface in production alerting.

Since the PR description confirms the bug exists in every litellm release from 1.82.3 through at least 1.83.14, consider using a range check (e.g. `Version(_litellm_version) > Version("1.83.14")`) or adding a CI assertion that `_SKIP_PATCH is False` so the omission can't quietly slip into a release.

_{Reviews (1): Last reviewed commit: "[HOTFIX] Bump litellm to 1.83.10 from Py..." | Re-trigger Greptile}

* [HOTFIX] Use importlib.util.find_spec for pluggable worker discovery (#1918) * [FIX] Use importlib.util.find_spec for pluggable worker discovery _verify_pluggable_worker_exists() previously checked for the literal file `pluggable_worker/<name>/worker.py` on disk, which breaks when the plugin has been compiled to a .so (Nuitka, Cython, or any C extension) — the module is perfectly importable but the pre-check rejects it because only the .py extension is considered. Replace the filesystem check with importlib.util.find_spec(), which is Python's standard way to ask "is this module resolvable by the import system?". It honors every registered finder — source .py, compiled .so, bytecode .pyc, namespace packages, zipimports — so the function now matches what its docstring claims: verifying the module can be loaded, not that a specific file extension is present. Behavior is preserved for existing deployments: - Images with no `pluggable_worker/<name>/` subpackage → find_spec raises ModuleNotFoundError (ImportError subclass) → returns False. - Images with source .py → find_spec resolves the .py → returns True. - Images with compiled .so → find_spec resolves the .so → returns True. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [FIX] Handle ValueError from find_spec in pluggable worker verification Greptile-flagged edge case: importlib.util.find_spec() can raise ValueError (not just ImportError) when sys.modules has a partially initialised module entry with __spec__ = None from a prior failed import. Broaden the except to catch both. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [FIX] Resolve api-deployment worker directory from enum import path worker.py:452 did worker_type.value.replace("-", "_") to derive the on-disk dir name. All WorkerType enum values already use underscores, so the replace was a no-op; for API_DEPLOYMENT whose dir is "api-deployment" (hyphen), it resolved to "api_deployment" and the os.path.exists() check failed. Boot then logged a spurious "❌ Worker directory not found: /app/api_deployment" at ERROR level. The task registration path (builder + celery autodiscover via to_import_path) is unaffected, so this was purely log noise — but noise at ERROR level that masks real failures in log scans. Fix: derive the directory from the authoritative to_import_path() which already handles the hyphen case (api_deployment -> api-deployment). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [HOTFIX] Add IAM Role / Instance Profile auth mode to AWS Bedrock adapter (#1944) * [FEAT] Allow Bedrock to fall through to boto3's default credential chain Match the S3/MinIO connector pattern: when AWS access keys are left blank on the Bedrock LLM and embedding adapter forms, drop them from the kwargs dict so boto3's default credential chain handles authentication. This unlocks IAM role / instance profile / IRSA / AWS Profile scenarios on hosts that already have ambient AWS credentials (e.g. EKS workers with IRSA, EC2 with an instance profile). - llm1/static/bedrock.json: clarify access-key descriptions to mention IRSA and instance profile (already non-required at v0.163.2 base). - embedding1/static/bedrock.json: drop aws_access_key_id and aws_secret_access_key from top-level required; same description fix; expose aws_profile_name for parity with the LLM form. - base1.py: AWSBedrockLLMParameters and AWSBedrockEmbeddingParameters now strip empty access-key values from the validated kwargs before returning, so empty strings don't override boto3's default chain. AWSBedrockEmbeddingParameters fields gain explicit None defaults and an aws_profile_name field. Backward-compatible: existing adapters with access keys filled in continue to work unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [FEAT] Add Authentication Type selector to Bedrock adapter form Add an explicit `auth_type` selector with two options, making the auth choice clear to users: - "Access Keys" (default): existing flow, keys required - "IAM Role / Instance Profile (on-prem AWS only)": no fields; relies on boto3's default credential chain (IRSA on EKS, task role on ECS, instance profile on EC2). Description on the selector explicitly notes this option is only for AWS-hosted Unstract deployments. The form-only auth_type field is stripped before LiteLLM validation in both AWSBedrockLLMParameters.validate() and AWSBedrockEmbeddingParameters. validate(). Empty access keys continue to be stripped so boto3 falls through to the default chain even when the access_keys arm is selected without values (matches the S3/MinIO connector pattern). Backward-compatible: legacy adapters without auth_type behave as "Access Keys" mode (the default), and existing keys are forwarded unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [REVIEW] Address Bedrock auth_type review feedback Fixes the P0/P1 issues raised by greptile-apps and jaseemjaskp on PR #1944. Behaviour fixes: - Stale-key leak in IAM Role mode: switching an existing adapter from Access Keys to IAM Role would carry truthy stored access keys through the strip-empty-only loop, so boto3 silently authenticated with the old long-lived credentials instead of falling through to the host's IRSA / instance-profile identity. Both LLM and embedding paths were affected. - Silent acceptance of unknown auth_type: a typo (e.g. "access_key") or a malformed payload from a non-UI client passed through the dict comprehension untouched, with no enum guard. - Cross-field validation gap: explicit Access Keys mode with blank or whitespace-only values silently fell through to the default credential chain instead of surfacing the misconfiguration. Implementation: - Add a module-level _resolve_bedrock_aws_credentials helper used by both AWSBedrockLLMParameters.validate() and AWSBedrock EmbeddingParameters.validate(), so the auth-type contract is expressed once. - Validates auth_type against an allowlist (None | "access_keys" | "iam_role"); raises ValueError on anything else. - iam_role: unconditionally drops aws_access_key_id and aws_secret_access_key. - access_keys (explicit): requires non-blank values; raises ValueError if either is empty or whitespace-only. - Legacy (auth_type absent): retains the lenient strip behaviour so pre-PR adapter configurations continue to deserialise unchanged. - Restore aws_region_name as required (no `= None` default) on AWSBedrockEmbeddingParameters; only credentials may legitimately be absent. - Drop the orphan aws_profile_name field from embedding1/static/bedrock.json: it was added for parity with the LLM form but lives outside the auth_type oneOf and contradicts the selector's "no further input" semantics. The LLM form already had aws_profile_name pre-PR and is left alone for backwards compatibility. Tests: - New tests/test_bedrock_adapter.py covers 15 cases across LLM and embedding adapters: legacy-no-auth-type, explicit access_keys with valid/blank/whitespace keys, iam_role with stale/no keys, unknown auth_type rejection, cross-field validation, and preservation of unrelated params (model_id, aws_profile_name, region, thinking). Skipped (P2 nice-to-have): - Comment-scope clarification, MinIO reference rewording, validate-mutates-caller'\''s-dict, and the LLM form description nit about aws_profile_name visibility. These don'\''t change behaviour and can be addressed in a follow-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> * [HOTFIX] Bump litellm to 1.83.10 from PyPI to clear CVE-2026-42208 (#1976) Hotfix for cloud v0.159.3 (OSS v0.163.4). Customer scanner flagged litellm 1.82.3 for CVE-2026-42208 (SQL injection in litellm proxy auth path, affects 1.81.16-1.83.6). We do not use litellm.proxy, but vulnerability scanners flag the installed package regardless of which code path is reachable. Bump to 1.83.10 — the exact version recommended by the upstream advisory (v1.83.10-stable) and the smallest jump that clears the CVE range while keeping python-dotenv==1.0.1 compatible (1.83.14 would force bumping python-dotenv across 7+ pyproject.toml files). Only tiktoken needed to move 0.9 -> 0.12 to satisfy litellm's pin. Switch source back to PyPI now that the PyPI quarantine is over, reversing the temporary fork in #1873. Cohere embed timeout patch: verified that litellm/llms/cohere/embed/handler.py is byte-identical between v1.82.3, v1.83.10-stable, and v1.83.14-stable (the timeout-not-forwarded bug fixed in #1848 is still present upstream — BerriAI/litellm#14635 remains OPEN). Version guard bumped 1.82.3 -> 1.83.10; 6/6 patch tests pass on the new version, confirming the monkey-patch still binds correctly. Other cleanup from #1873: - Drop git apt-install from worker-unified and tool Dockerfiles (no git-sourced deps remain in any uv.lock) - Bump tool versions: structure 0.0.100 -> 0.0.101, classifier 0.0.79 -> 0.0.80, text_extractor 0.0.75 -> 0.0.76 Note on root uv.lock churn: the v0.163.4 root uv.lock had a pre-existing corruption (banks v2.4.1 entry pointing at banks-2.2.0 wheel) that blocked incremental resolution. Regenerated from scratch. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * [FIX] Align cohere patch docstring with version-guard semantics Reviewer flagged that the docstring claimed the patch is "confirmed in every release between 1.82.3 and 1.83.14-stable", but the guard at _PATCHED_LITELLM_VERSION activates only on the exact pinned version. A future maintainer reading the old text could reasonably expect bumping to e.g. 1.83.11 to keep the fix active; in reality it silently turns off. Rewritten to reference _PATCHED_LITELLM_VERSION as the single source of truth and to drop the rot-prone "as of 2026-05-20" calendar date. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Chandrasekharan M <117059509+chandrasekharan-zipstack@users.noreply.github.com> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>

greptile-apps Bot reviewed May 20, 2026

View reviewed changes

Comment thread unstract/sdk1/src/unstract/sdk1/patches/litellm_cohere_timeout.py

pk-zipstack self-assigned this May 20, 2026

pk-zipstack requested a review from vishnuszipstack May 20, 2026 07:09

pk-zipstack assigned chandrasekharan-zipstack May 20, 2026

pk-zipstack requested a review from jaseemjaskp May 20, 2026 07:09

pk-zipstack unassigned chandrasekharan-zipstack May 20, 2026

pk-zipstack requested review from Deepak-Kesavan and chandrasekharan-zipstack May 20, 2026 07:09

chandrasekharan-zipstack approved these changes May 20, 2026

View reviewed changes

Deepak-Kesavan requested a review from harini-venkataraman May 20, 2026 09:51

Deepak-Kesavan reviewed May 20, 2026

View reviewed changes

Comment thread backend/sample.env

Deepak-Kesavan approved these changes May 20, 2026

View reviewed changes

chandrasekharan-zipstack merged commit 2dab564 into v0.163.4-hotfix May 20, 2026
6 checks passed

chandrasekharan-zipstack deleted the fix/litellm-cve-pypi-hotfix branch May 20, 2026 10:55

This was referenced May 21, 2026

ReverseMerge: V0.163.4 hotfix #1979

Closed

ReverseMerge: V0.163.4 hotfix #1980

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[HOTFIX] Bump litellm to 1.83.10 from PyPI to clear CVE-2026-42208#1976

[HOTFIX] Bump litellm to 1.83.10 from PyPI to clear CVE-2026-42208#1976
chandrasekharan-zipstack merged 1 commit into
v0.163.4-hotfixfrom
fix/litellm-cve-pypi-hotfix

pk-zipstack commented May 20, 2026

Uh oh!

coderabbitai Bot commented May 20, 2026

Review skipped

Uh oh!

sonarqubecloud Bot commented May 20, 2026

Uh oh!

greptile-apps Bot commented May 20, 2026

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Flowchart

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

pk-zipstack commented May 20, 2026

Summary

Cohere embed timeout patch

Other cleanup from #1873

Note on root uv.lock churn

Test plan

Uh oh!

coderabbitai Bot commented May 20, 2026

Review skipped

Uh oh!

sonarqubecloud Bot commented May 20, 2026

Quality Gate passed

Uh oh!

greptile-apps Bot commented May 20, 2026

Greptile Summary

Confidence Score: 4/5

Important Files Changed

Flowchart

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Note on root `uv.lock` churn