## Impact 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...
Full CISO analysis pending enrichment.
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| LiteLLM | pip | >= 0.1.8, < 0.1.15 | 0.1.15 |
Do you use LiteLLM? You're affected.
How severe is it?
What should I do?
Patch available
Update LiteLLM to version 0.1.15
Which compliance frameworks are affected?
Compliance analysis pending. Sign in for full compliance mapping when available.
Frequently Asked Questions
What is GHSA-98x5-vq43-vc5p?
## Impact 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: - Process environment variables - AWS / GCP / Azure credentials - SSH keys, Kubernetes configs, shell history - Database credentials and CI/CD secrets - Cryptocurrency wallets 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](https://github.com/BerriAI/litellm/issues/24512) and [CVE-2026-42208](https://www.cve.org/CVERecord?id=CVE-2026-42208). ## Patches Fixed in **semantic-router 0.1.15**, which raises the floor to `litellm>=1.83.7`. ## Workarounds If developers cannot upgrade immediately: - Pin `litellm>=1.83.7,!=1.82.8` explicitly in their own project. - Audit `site-packages/` for `litellm_init.pth` and delete if present. - Rotate any credentials reachable from environments where an affected install ran. ## Credit Upstream report and triage by the litellm maintainers — see issue [#24512](https://github.com/BerriAI/litellm/issues/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 GHSA-98x5-vq43-vc5p actively exploited?
No confirmed active exploitation of GHSA-98x5-vq43-vc5p has been reported, but organizations should still patch proactively.
How to fix GHSA-98x5-vq43-vc5p?
Update to patched version: LiteLLM 0.1.15.
What is the CVSS score for GHSA-98x5-vq43-vc5p?
No CVSS score has been assigned yet.
What are the technical details?
Original Advisory
## Impact 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: - Process environment variables - AWS / GCP / Azure credentials - SSH keys, Kubernetes configs, shell history - Database credentials and CI/CD secrets - Cryptocurrency wallets 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](https://github.com/BerriAI/litellm/issues/24512) and [CVE-2026-42208](https://www.cve.org/CVERecord?id=CVE-2026-42208). ## Patches Fixed in **semantic-router 0.1.15**, which raises the floor to `litellm>=1.83.7`. ## Workarounds If developers cannot upgrade immediately: - Pin `litellm>=1.83.7,!=1.82.8` explicitly in their own project. - Audit `site-packages/` for `litellm_init.pth` and delete if present. - Rotate any credentials reachable from environments where an affected install ran. ## Credit Upstream report and triage by the litellm maintainers — see issue [#24512](https://github.com/BerriAI/litellm/issues/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.
Weaknesses (CWE)
CWE-506 — Embedded Malicious Code: The product contains code that appears to be malicious in nature.
- [Implementation, Operation] Remove the malicious code and start an effort to ensure that no more malicious code exists. This may require a detailed review of all code, as it is possible to hide a serious attack in only one or two lines of code. These lines may be located almost anywhere in an application and may have been intentionally obfuscated by the attacker.
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2026-42208 9.8 LiteLLM: SQL injection exposes LLM API credentials
Same package: litellm CVE-2026-54352 9.6 Budibase: zip symlink bypass exposes all server secrets
Same package: litellm CVE-2026-35030 9.1 LiteLLM: auth bypass via JWT cache key collision
Same package: litellm CVE-2026-40217 8.8 LiteLLM: RCE via bytecode rewriting in guardrails API
Same package: litellm CVE-2024-6825 8.8 LiteLLM: RCE via post_call_rules callback injection
Same package: litellm