GHSA-98x5-vq43-vc5p: LiteLLM unpinned litellm dep

CISO Take

semantic-router versions 0.1.8 through 0.1.14 declared litellm>=1.61.3 with no upper bound, so a fresh `pip install` during the window that litellm 1.82.8 sat on PyPI could silently pull that compromised wheel instead of a legitimate release. The malicious wheel shipped a `.pth` file that executes at Python interpreter startup — no import, no user action required — harvesting cloud credentials, SSH keys, Kubernetes configs, database secrets and crypto wallets, then AES/RSA-encrypting and exfiltrating them to an attacker-controlled domain. There is no CVSS/EPSS scoring and it is not in CISA KEV, but the payload class (full credential theft plus silent exfiltration) makes actual impact severe wherever an affected install landed during the compromise window; with only 6 known downstream dependents the blast radius is narrow but not zero, and semantic-router's OpenSSF Scorecard of 6/10 and 34 other historical CVEs in the package suggest broader dependency-hygiene gaps worth reviewing. Upgrade to semantic-router 0.1.15 (which floors litellm at >=1.83.7) immediately, and separately audit any environment that ran `pip install` against affected versions for a lingering `litellm_init.pth` in site-packages, rotating every credential reachable from that environment (cloud, SSH, DB, CI/CD, wallets) as a precaution regardless of whether the file is found.

Sources: GitHub Advisory ATLAS OpenSSF CISA KEV

What is the risk?

Rated critical by the advisory, but exploitation was time-bounded rather than persistent: the malicious litellm 1.82.8 wheel was only resolvable while it was the latest matching release on PyPI, so exposure is limited to installs (or CI/CD builds, or container rebuilds) that ran during that specific window — not every historical install of semantic-router 0.1.8–0.1.14. No public exploit tooling or Nuclei template exists (none is needed; the vector is a legitimate-looking package publish), and it is not in CISA KEV or scored for EPSS since this is a supply-chain compromise rather than a remotely triggerable vulnerability. The real risk driver is CWE-506 (Embedded Malicious Code) combined with zero-interaction execution at interpreter startup — any host, CI runner, or developer machine that resolved the bad wheel should be treated as fully compromised (credentials, not just the process, are the asset at risk).

How does the attack unfold?

Unbounded dependency resolution

semantic-router 0.1.8-0.1.14's unbounded litellm>=1.61.3 constraint lets pip resolve to whatever litellm release is latest on PyPI at install time.

AML.T0010.001

Malicious wheel execution

During the window litellm 1.82.8 was latest, the resolver pulls it; its embedded .pth file auto-executes at Python interpreter startup with no import needed.

AML.T0011.001

Credential harvesting

The payload collects environment variables, cloud credentials, SSH keys, Kubernetes configs, DB credentials, CI/CD secrets, and crypto wallets from the host.

AML.T0055

Encrypted exfiltration

Harvested data is encrypted with AES-256 and an embedded RSA public key, then POSTed to the attacker-controlled models.litellm.cloud.

AML.T0025

Unbounded dependency resolution

semantic-router 0.1.8-0.1.14's unbounded litellm>=1.61.3 constraint lets pip resolve to whatever litellm release is latest on PyPI at install time.

AML.T0010.001

Malicious wheel execution

During the window litellm 1.82.8 was latest, the resolver pulls it; its embedded .pth file auto-executes at Python interpreter startup with no import needed.

AML.T0011.001

Credential harvesting

The payload collects environment variables, cloud credentials, SSH keys, Kubernetes configs, DB credentials, CI/CD secrets, and crypto wallets from the host.

AML.T0055

Encrypted exfiltration

Harvested data is encrypted with AES-256 and an embedded RSA public key, then POSTed to the attacker-controlled models.litellm.cloud.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LiteLLM	pip	—	No patch
56.4K OpenSSF 5.8 6 dependents Pushed 2d ago 49% patched ~47d to patch Full package profile →
LiteLLM	pip	>= 0.1.8, < 0.1.15	`0.1.15`
56.4K OpenSSF 5.8 6 dependents Pushed 2d ago 49% patched ~47d to patch Full package profile →

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What should I do?

1 step

1) Upgrade to semantic-router >=0.1.15, which raises the litellm floor to >=1.83.7, excluding the compromised release. 2) If immediate upgrade isn't possible, explicitly pin litellm>=1.83.7,!=1.82.8 in your own project's dependency file to override the floating range. 3) Audit site-packages/ on any host or image that ran pip install for semantic-router 0.1.8–0.1.14 during the exposure window for a litellm_init.pth file; delete it if present and treat the host as compromised. 4) Rotate every credential reachable from that environment: cloud IAM keys, SSH keys, kubeconfigs, DB credentials, CI/CD secrets, and any crypto wallets. 5) Review CI/CD build logs and container image build timestamps to determine which artifacts were built during the exposure window and rebuild/redeploy them from a clean, patched dependency tree. 6) Going forward, pin transitive dependencies (or use lockfiles with hash verification) for AI/ML packages to prevent floating ranges from silently pulling a compromised release.

How is it classified?

Supply Chain Code Execution Data Leakage Framework Inference AML.T0010.001 - AI Software AML.T0011.001 - Malicious Package AML.T0025 - Exfiltration via Cyber Means AML.T0055 - Unsecured Credentials AML.T0109 - AI Supply Chain Rug Pull

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.3 - Third-party and supplier requirements for AI system components

NIST AI RMF

MAP 1.1 / GOVERN 4.1 - Third-party/supply chain risk mapping and governance

OWASP LLM Top 10

LLM05:2025 - Supply Chain Vulnerabilities

Frequently Asked Questions

What is GHSA-98x5-vq43-vc5p?

semantic-router versions 0.1.8 through 0.1.14 declared litellm>=1.61.3 with no upper bound, so a fresh `pip install` during the window that litellm 1.82.8 sat on PyPI could silently pull that compromised wheel instead of a legitimate release. The malicious wheel shipped a `.pth` file that executes at Python interpreter startup — no import, no user action required — harvesting cloud credentials, SSH keys, Kubernetes configs, database secrets and crypto wallets, then AES/RSA-encrypting and exfiltrating them to an attacker-controlled domain. There is no CVSS/EPSS scoring and it is not in CISA KEV, but the payload class (full credential theft plus silent exfiltration) makes actual impact severe wherever an affected install landed during the compromise window; with only 6 known downstream dependents the blast radius is narrow but not zero, and semantic-router's OpenSSF Scorecard of 6/10 and 34 other historical CVEs in the package suggest broader dependency-hygiene gaps worth reviewing. Upgrade to semantic-router 0.1.15 (which floors litellm at >=1.83.7) immediately, and separately audit any environment that ran `pip install` against affected versions for a lingering `litellm_init.pth` in site-packages, rotating every credential reachable from that environment (cloud, SSH, DB, CI/CD, wallets) as a precaution regardless of whether the file is found.

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?

1) Upgrade to semantic-router >=0.1.15, which raises the litellm floor to >=1.83.7, excluding the compromised release. 2) If immediate upgrade isn't possible, explicitly pin `litellm>=1.83.7,!=1.82.8` in your own project's dependency file to override the floating range. 3) Audit `site-packages/` on any host or image that ran `pip install` for semantic-router 0.1.8–0.1.14 during the exposure window for a `litellm_init.pth` file; delete it if present and treat the host as compromised. 4) Rotate every credential reachable from that environment: cloud IAM keys, SSH keys, kubeconfigs, DB credentials, CI/CD secrets, and any crypto wallets. 5) Review CI/CD build logs and container image build timestamps to determine which artifacts were built during the exposure window and rebuild/redeploy them from a clean, patched dependency tree. 6) Going forward, pin transitive dependencies (or use lockfiles with hash verification) for AI/ML packages to prevent floating ranges from silently pulling a compromised release.

What systems are affected by GHSA-98x5-vq43-vc5p?

This vulnerability affects the following AI/ML architecture patterns: LLM routing/gateway layers, RAG pipelines, agent frameworks, CI/CD build pipelines.

What is the CVSS score for GHSA-98x5-vq43-vc5p?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

LLM routing/gateway layersRAG pipelinesagent frameworksCI/CD build pipelines

MITRE ATLAS Techniques

AML.T0010.001 AI Software

AML.T0011.001 Malicious Package

AML.T0025 Exfiltration via Cyber Means

AML.T0055 Unsecured Credentials

AML.T0109 AI Supply Chain Rug Pull

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.3

NIST AI RMF: MAP 1.1 / GOVERN 4.1

OWASP LLM Top 10: LLM05:2025

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.

Exploitation Scenario

A developer or CI pipeline runs `pip install semantic-router==0.1.12` (or any affected 0.1.8–0.1.14 version) during the window that litellm 1.82.8 is the latest matching release on PyPI. pip's resolver silently pulls litellm 1.82.8 to satisfy the unbounded `litellm>=1.61.3` constraint. The wheel installs a `litellm_init.pth` file, which Python's site module auto-executes the next time any Python interpreter starts in that environment — no explicit `import litellm` required. The payload immediately harvests environment variables, cloud provider credentials, SSH keys, Kubernetes configs, shell history, database credentials, CI/CD secrets, and any crypto wallets present, encrypts the haul with AES-256 plus an embedded RSA public key, and exfiltrates it via HTTPS POST to `models.litellm.cloud`. If this occurred inside a CI/CD runner, the attacker gains a path to every secret and deployment credential exposed to that pipeline, not just the local developer's data.

Weaknesses (CWE)

CWE-506 Embedded Malicious Code Primary

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.