PyPI · semantic-router
semantic-router exposed to compromised litellm wheel (CVE-2026-42208) via unbounded transitive pin
semantic-router versions 0.1.8 through 0.1.14 declare litellm>=1.61.3 with no upper bound. During the window in which litellm==1.82.8 was the latest release on PyPI, a fresh install of any affected semantic-router version could resolve to that compromised wheel.
The malicious litellm==1.82.8 wheel ships a litellm_init.pth file that executes on Python interpreter startup — no import required. It collects and exfiltrates:
Stage-two payload encrypts the collected data (AES-256 + embedded RSA pubkey) and POSTs it to https://models.litellm.cloud/.
See upstream: BerriAI/litellm#24512 and CVE-2026-42208.
Fixed in semantic-router 0.1.15, which raises the floor to litellm>=1.83.7.
If developers cannot upgrade immediately:
litellm>=1.83.7,!=1.82.8 explicitly in their own project.site-packages/ for litellm_init.pth and delete if present.Upstream report and triage by the litellm maintainers — see issue #24512.
One caveat before publishing
CVE-2026-42208 specifically names 1.82.8. Pip's resolver picks "latest matching", so the real affected blast radius for semantic-router is users who ran pip install during the window that 1.82.8 was on PyPI — not everyone who ever installed 0.1.8–0.1.14. The advisory is still correct (an affected install could have pulled the bad wheel), but consider whether a Severity: Critical / Exploitability: time-bounded note would help downstream readers understand the exposure model.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.