GHSA-98x5-vq43-vc5p
semantic-router exposed to compromised litellm wheel (CVE-2026-42208) via unbounded transitive pin
Blast Radius
semantic-routerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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 and 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.8explicitly in their own project. - Audit
site-packages/forlitellm_init.pthand 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.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | semantic-router | ≥ 0.1.8&&< 0.1.15 | 0.1.15 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for semantic-router. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update semantic-router to 0.1.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-98x5-vq43-vc5p is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-98x5-vq43-vc5p is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-98x5-vq43-vc5p. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-98x5-vq43-vc5p in your dependencies?
O3 detects GHSA-98x5-vq43-vc5p across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.