Description
pyproject.toml currently pins litellm>=1.75.5,<=1.82.6 in both
the base project dependencies (line 126) and the [test] extras
(line 145). The accompanying comment notes that the upper bound was
added to defend against a March 2026 supply-chain compromise of
litellm 1.82.7 / 1.82.8 (commit
77f1c41).
That defensive pin made sense at the time but is now misaligned with
five subsequently disclosed CVEs in litellm <= 1.82.6. The fixes
are in litellm 1.83.0 (three) and 1.83.7 (two). Currently every
adk-python install transitively pins to a vulnerable version, and
downstream users (e.g. dependabot on every project that depends on
adk-python) cannot fix the alerts without overriding adk-python's
constraint.
Active CVEs against litellm <= 1.82.6
All five target litellm's optional proxy server component, so
runtime exposure depends on whether installs include
litellm[proxy]. The cap is still wrong from a supply-chain
hygiene standpoint regardless: every dependabot-enabled downstream
will see five open advisories until adk-python releases a
non-vulnerable resolution.
Proposed fix
Replace both occurrences of:
"litellm>=1.75.5,<=1.82.6", # ... supply chain attack ...
with:
"litellm>=1.83.7,<2", # For LiteLlm class. Lower bound is the first release with patches for 5 CVEs disclosed 2026-04-11/24; supersedes earlier supply-chain pin against 1.82.7/8.
Rationale:
- 1.83.7 is the first version that patches all five CVEs.
- Lower bound 1.83.7 is strictly above 1.82.7 and 1.82.8, so the
original supply-chain concern is still respected.
- Per PyPI metadata, litellm 1.83.7 reports
"vulnerabilities": []
and was uploaded 2026-04-13. Latest stable today is 1.83.13
(2026-04-24), also clean.
- Upper bound
<2 matches existing project conventions
(mcp>=1.24,<2, anyio>=4.9,<5).
A PR implementing this is filed concurrently with this issue.
Heads up for downstream consumers: litellm hard-pins python-dotenv
While verifying the bump, we discovered that litellm 1.83.7 (and
every subsequent version through 1.83.13) hard-pins
python-dotenv==1.0.1 as an unconditional core dependency. By
contrast, 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 admits 1.0.1 cleanly. But any
downstream project that has tightened python-dotenv (e.g.
>=1.2.x) will hit a resolver conflict after this bump and may
need to either:
- Relax its own python-dotenv constraint, or
- Apply a
[tool.uv] override-dependencies (uv) or equivalent
override in pip/poetry.
This is a litellm anti-pattern, not an ADK problem, and worth a
separate upstream discussion at BerriAI/litellm. Mentioning it
here so reviewers and downstream maintainers know to expect it.
Out of scope
The langgraph constraint (langgraph>=0.2.60,<0.4.8) has a
similar shape and one medium-severity CVE
(GHSA-g48c-2wqr-h844),
but bumping past 0.4.x requires porting ADK's use of the removed
graph.graph API (per
#1687). That is
real engineering work, not a dep cap bump, and is left as a
separate effort.
Description
pyproject.tomlcurrently pinslitellm>=1.75.5,<=1.82.6in boththe base project dependencies (line 126) and the
[test]extras(line 145). The accompanying comment notes that the upper bound was
added to defend against a March 2026 supply-chain compromise of
litellm 1.82.7 / 1.82.8 (commit
77f1c41).That defensive pin made sense at the time but is now misaligned with
five subsequently disclosed CVEs in
litellm <= 1.82.6. The fixesare in litellm 1.83.0 (three) and 1.83.7 (two). Currently every
adk-python install transitively pins to a vulnerable version, and
downstream users (e.g. dependabot on every project that depends on
adk-python) cannot fix the alerts without overriding adk-python's
constraint.
Active CVEs against litellm <= 1.82.6
All five target litellm's optional proxy server component, so
runtime exposure depends on whether installs include
litellm[proxy]. The cap is still wrong from a supply-chainhygiene standpoint regardless: every dependabot-enabled downstream
will see five open advisories until adk-python releases a
non-vulnerable resolution.
Proposed fix
Replace both occurrences of:
with:
Rationale:
original supply-chain concern is still respected.
"vulnerabilities": []and was uploaded 2026-04-13. Latest stable today is 1.83.13
(2026-04-24), also clean.
<2matches existing project conventions(
mcp>=1.24,<2,anyio>=4.9,<5).A PR implementing this is filed concurrently with this issue.
Heads up for downstream consumers: litellm hard-pins python-dotenv
While verifying the bump, we discovered that litellm 1.83.7 (and
every subsequent version through 1.83.13) 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:
[tool.uv] override-dependencies(uv) or equivalentoverride in pip/poetry.
This is a litellm anti-pattern, not an ADK problem, and worth a
separate upstream discussion at BerriAI/litellm. Mentioning it
here so reviewers and downstream maintainers know to expect it.
Out of scope
The
langgraphconstraint (langgraph>=0.2.60,<0.4.8) has asimilar shape and one medium-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.