Tell HN: Litellm 1.82.7 and 1.82.8 on PyPI are compromised

Original Article ↗ Hacker News Discussion ↗

A popular Python library for unifying access to multiple LLM providers, LiteLLM, had its recent PyPI releases (1.82.7 and 1.82.8) compromised after attackers obtained CI credentials via the Trivy supply-chain attack, inserting malware that could run on install or import and exfiltrate developer secrets. Commenters note that many downstream tools and projects depend on LiteLLM, amplifying the blast radius and highlighting how fragile current dependency and CI practices are. The incident fuels calls for stricter version pinning, better isolation and sandboxing of tooling, more conservative update policies, and more robust publishing workflows for critical open‑source packages.

Nature of the compromise

  • PyPI releases litellm 1.82.7 and 1.82.8 were malicious.
  • 1.82.7 hid a payload in litellm/proxy/proxy_server.py that ran on import.
  • 1.82.8 added a litellm_init.pth file so arbitrary code ran at Python startup; simply installing it was enough.
  • The malware spawned Python processes, searched for credentials (e.g., ~/.git-credentials, crypto wallet info), encrypted and exfiltrated data to attacker-controlled URLs.

Attack chain and actors

  • Maintainers say the initial compromise came via a malicious Trivy scanner in CI/CD, which exfiltrated CircleCI secrets.
  • Stolen tokens reportedly included PyPI publish credentials and a GitHub personal access token.
  • Attacker then uploaded compromised versions to PyPI and appears to have taken over a maintainer’s GitHub account, defacing repos and closing issues.
  • The same attacker group is linked in the thread to earlier Trivy compromises; timeline writeups and “TeamPCP” references are shared.

Impact and ecosystem blast radius

  • LiteLLM is widely used as an LLM gateway and as a direct dependency (DSPy, CrewAI, browser-use, nanobot, others).
  • Many projects had unpinned litellm in requirements.txt / pyproject.toml, increasing exposure.
  • Users report systems freezing or being fork-bombed after indirect installs via other tools.
  • Official Docker images pinned to older versions are repeatedly described as unaffected.

Mitigations and detection

  • PyPI quarantined the project, then removed 1.82.7 and 1.82.8.
  • Maintainers say all tokens/accounts have been rotated, publishing is paused, and an external incident-response team is engaged.
  • Suggested local checks include searching for litellm_init.pth and installed litellm 1.82.7/1.82.8 across environments.
  • Advice: build deployable artifacts instead of live pip/uv run; pin versions and hashes; use lockfiles and “exclude newer than X days” features; mirror dependencies; rotate any possibly exposed credentials.

Debate on wrappers and dependency hygiene

  • Some argue LiteLLM-like wrappers are not worth the extra supply-chain risk given most providers expose OpenAI-compatible APIs.
  • Others note such gateways add real value (API unification, fallbacks, guardrails, key management, spend tracking), which is why they’re so widely embedded.
  • There is broad criticism of large, messy dependency trees and of LiteLLM’s code quality; several users say they’re switching to alternatives or writing minimal shims.

Broader supply-chain and tooling concerns

  • Strong calls for:
    • Better isolation (VMs, containers, sandboxes, OS-level controls) for dev tools and CI scanners.
    • Static analysis and malware scanning of new dependencies.
    • More conservative update policies (delays, age thresholds).
    • Stronger CI credential scoping and trusted publishing via OIDC.
  • GitHub’s weak spam controls are criticized; the flooded issue thread with low-effort “thanks” comments is seen as deliberate discussion suppression.
  • Many expect such AI-tooling supply-chain attacks to become routine rather than exceptional.