fix(deps): bump litellm cap to >=1.83.7 to admit CVE patches#5489
fix(deps): bump litellm cap to >=1.83.7 to admit CVE patches#5489cwest wants to merge 4 commits intogoogle:mainfrom
Conversation
The current cap of <=1.82.6 was added in 77f1c41 to exclude the supply-chain compromise of litellm 1.82.7/8. Five CVEs have since been disclosed against litellm <=1.82.6 (2 critical: GHSA-r75f- 5x8p-qvmc, GHSA-jjhc-v7c2-5hh6; 3 high: GHSA-xqmj-j6mv-4862, GHSA-69x8-hrgq-fjj8, GHSA-53mr-6c8q-9789), with fixes in 1.83.0 and 1.83.7. The new lower bound (1.83.7) still excludes the originally compromised 1.82.7/8. Tested: tests/unittests/models/test_litellm.py and tests/unittests/models/test_litellm_import.py pass (259 passed, 0 failed) against litellm 1.83.13 with the new constraint. Refs google#5488
Addresses review feedback on google#5489: restore the project's defensive exact-version pin (matching the prior <=1.82.6 pattern) in place of the open-ended <2 cap. Pinning to current latest (1.83.14) keeps every future litellm release behind a deliberate bump, which is what stopped the 1.82.7/8 supply-chain attack from reaching ADK users. Tested: tests/unittests/models/test_litellm.py and tests/unittests/models/test_litellm_import.py pass (259 passed, 0 failed) against the installed litellm 1.83.13.
Re-apply the project's exact-version cap pattern (the original was <=1.82.6) instead of the looser <2 I'd proposed. Pinning to the current latest release means every future litellm version needs an explicit ADK PR before it can resolve into user environments. That is how the prior <=1.82.6 cap held the line once 1.82.7/8 were known-bad. Verified: 259 litellm tests pass against installed 1.83.13. Addresses review feedback on google#5489.
3840fe7 to
d40ef4a
Compare
|
Tests are failing because this needs to be bumped as well and released: https://github.com/googleapis/python-aiplatform/blob/main/setup.py#L186 |
|
Filed the upstream bump in googleapis/python-aiplatform#6645 (drops the ADK CI here will stay red until that PR lands and a |
-- 68eaca8 by Casey West <caseywest@google.com>: fix(deps): bump litellm cap to >=1.83.7 for additional CVE remediation The current cap of <1.83.7 (set in #6617) clears CVE-2026-35030 in litellm 1.83.0 but excludes four additional CVEs patched in 1.83.7: GHSA-r75f-5x8p-qvmc, GHSA-jjhc-v7c2-5hh6, GHSA-xqmj-j6mv-4862, GHSA-69x8-hrgq-fjj8 (disclosed 2026-04-11/24). Required by google/adk-python#5489, which pins litellm>=1.83.7,<=1.83.14 in its own dependencies and currently fails to install alongside google-cloud-aiplatform[evaluation] because of this cap. Requested by @sasha-gitg in the ADK PR review. The code adaptation for litellm 1.83.x already shipped in #6599 (vertexai/_genai/_evals_common.py via get_llm_provider), so this is purely a version-pin change. Verified: nox -s lint and nox -s lint_setup_py pass; the litellm-touching tests in tests/unit/vertexai/genai/test_evals.py pass against installed litellm at both 1.83.7 (lower bound) and 1.83.14 (upper bound). COPYBARA_INTEGRATE_REVIEW=#6645 from cwest:topic/bump-litellm-cap 638e6fa PiperOrigin-RevId: 906452948
|
Refreshed the branch off main (559f0c2). The upstream blocker is resolved: googleapis/python-aiplatform#6645 merged via Copybara as 3bd0b256, and |
|
Heads up @sasha-gitg: the new commits on this branch need workflow approval ( |
Closes #5488
Summary
Bumps the
litellmconstraint from<=1.82.6to>=1.83.7,<=1.83.14in both the base project dependencies and the
[test]extras.The current cap was added in
77f1c41toexclude the March 2026 supply-chain compromise of litellm 1.82.7
and 1.82.8. Since then, five CVEs have been disclosed against
litellm
<=1.82.6(2 critical, 3 high), with patches in 1.83.0and 1.83.7. The new lower bound (1.83.7) is strictly above the
originally compromised versions, so the original concern is still
respected.
The upper bound is pinned to the current latest release on PyPI
(1.83.14) per reviewer request, mirroring the project's prior
exact-version cap pattern. New litellm releases will require an
explicit ADK PR to admit, the same way
<=1.82.6did.Full CVE list and rationale in the linked issue (#5488).
Diff
Two identical edits, one in project deps (line 126) and one in
[test]extras (line 145):Testing plan
google-adk(editable) against the updatedconstraint; pip resolved litellm to 1.83.13 (latest stable
compatible with the rest of the lockfile, inside the new
[1.83.7, 1.83.14]window).tests/unittests/models/test_litellm.pyandtests/unittests/models/test_litellm_import.py; all 259tests pass. Output below.
pyproject.tomlis parseable as TOML.Upstream litellm test output
Heads up: litellm hard-pins python-dotenv
While verifying, we discovered that litellm 1.83.7 (and every
subsequent version through 1.83.14) hard-pins
python-dotenv==1.0.1as an unconditional core dependency. Bycontrast, litellm 1.82.6 declared
python-dotenv>=0.2.0(loose).This does not affect adk-python itself -- ADK declares
python-dotenv>=1,<2, which admits1.0.1cleanly. But anydownstream project that has tightened
python-dotenv(e.g.>=1.2.x) will hit a resolver conflict after this bump and mayneed to either relax its python-dotenv constraint or apply a
package-manager override. This is a litellm anti-pattern, not an
ADK problem; included here so reviewers know to expect downstream
issues of that shape.
Out of scope
langgraphhas a similar dep cap (<0.4.8) and onemedium-severity CVE
(GHSA-g48c-2wqr-h844),
but bumping past 0.4.x requires porting ADK's use of the removed
graph.graphAPI (per#1687). That is
real engineering work, not a dep cap bump, and is left as a
separate effort.