LiteLLM reports credential-stealing code in 1.82.7 and 1.82.8

• LiteLLM says PyPI releases 1.82.7 and 1.82.8 were compromised with a malicious litellm_init.pth file that runs on Python startup and can steal SSH keys, environment variables, and cloud credentials, with exfiltration reportedly sent to models.litellm.cloud according to the disclosure issue.
• The maintainers say PyPI quarantined the bad packages, and users of those versions should remove the .pth file and rotate credentials because the incident report treats all exposed secrets as compromised.
• The operational risk is larger than a direct pip install: the HN discussion notes LiteLLM is often a transitive dependency in AI tooling, and one commenter described it as being pulled in by a Cursor MCP plugin.
• The mitigation conversation has already shifted to package-age controls and autonomous install flows, with the fresh thread highlighting seven-day release-age gating and the risk of agents that can run installs on their own.

The core disclosure says versions 1.82.7 and 1.82.8 on PyPI included a malicious litellm_init.pth file with a published SHA256 hash, and that the payload "executes automatically on Python startup" disclosure issue. That matters because .pth execution turns a normal dependency install into code execution before an application even imports LiteLLM.

According to the core summary, the reported target data included "SSH keys, env vars, cloud creds," making this a broad workstation and CI secret exposure event rather than a narrowly scoped library bug. The maintainers attributed the attack to TeamPCP via a compromised maintainer account from the earlier Trivy incident, though that attribution is still reported through the incident thread rather than an independent public forensic writeup disclosure issue.

The immediate response is also unusually blunt. The maintainer issue says the package was quarantined on PyPI and urges users to check versions, delete the .pth file, and rotate all credentials. OpenHands said its production environments were unaffected but that it was still investigating developer exposure, adding that open source contributors who "bypassed the lockfile" during dependency installs should check whether they were affected OpenHands exposure note.

The most useful engineering takeaway from the follow-on discussion is that this was not treated as just another Python package incident. The core thread summary frames package supply-chain risk as part of the AI tooling stack itself, especially where model gateways, MCP servers, plugins, and local coding environments pull in fast-moving dependencies.

That shows up in two practical ways. First, the discussion summary says LiteLLM is often installed transitively; one commenter wrote that it was "pulled in by a Cursor MCP plugin," which is exactly the kind of dependency chain many teams will not audit line by line. Second, the fresh thread says commenters pushed release-age controls across npm, pnpm, uv, and bun, with one suggestion to "set min release age to 7 days."

The agent angle is the sharper warning. In the same discussion, a commenter wrote, "A compromised package is bad. An agent that autonomously runs pip install with that package is a different problem" discussion summary. That captures why this incident lands squarely in AI operations: the risk is not only what developers install directly, but what semi-autonomous tooling is allowed to fetch and execute inside dev boxes, ephemeral sandboxes, and CI jobs.