Security: litellm transitive dependency — mitigation plan and protection against bad future releases

[AdrianLayer7]

Following BerriAI/litellm#24512 (malicious litellm_init.pth in litellm==1.82.8 on PyPI), semantic-router users inherit litellm transitively. This is a supply-chain risk: a compromised or malicious litellm wheel can affect anyone who installs or updates dependencies without pinning.

We need a clear commitment from this project, not speculation:

1. What will semantic-router do to protect users? (e.g. pin or cap litellm, split optional extras, document safe versions, CI checks on wheels.)
2. Are downstream installs vulnerable to future litellm updates if requirements stay loose? If yes, state it explicitly and recommend pins or policy.

Without that, teams may remove semantic-router to avoid uncontrolled transitive updates. Please publish a short security response (README or advisory) and, if applicable, a release that locks or constrains the dependency.

Thank you.

[jamescalam]

We've restricted to litellm>=1.83.7 (see CVE-2026-42208) — the impacted range appears to extend beyond what was originally raised in the upstream litellm issue, so we took the conservative floor. To answer your questions @AdrianLayer7:

1. Fix shipped in semantic-router>=0.1.15, which pins litellm>=1.83.7. Impacted versions 0.1.8 through 0.1.14 have been yanked from PyPI with the warning:

CVE-2026-42208: unbounded litellm pin can resolve to a compromised wheel (litellm==1.82.8) that exfiltrates credentials on Python startup. Upgrade to semantic-router>=0.1.15.

A GitHub Security Advisory has been published: GHSA-98x5-vq43-vc5p.

2. We plan to remove the litellm dependency entirely in a future release. In the meantime, while 1.84.1 and 1.85.1 have no further reported issues, both are recent releases — if you want to be conservative, pinning litellm>=1.83.7,<1.84 in your own project is reasonable.