Popular AI Python Tool LiteLLM Hit by Supply-Chain Attack, Exposing Secrets in Minutes

Two booby-trapped releases of a widely used Python package briefly turned the AI developer toolchain into a secret-siphoning machine, and it happened fast.

Attackers uploaded malicious versions ofLiteLLMto the Python Package Index (PyPI), the default app store for Python libraries, and racked up roughly47,000 downloads in about 46 minutesbefore the packages were pulled. Security researchers say the code was designed to quietly harvest credentials, exactly the kind that can unlock cloud accounts, CI/CD pipelines, and Kubernetes clusters.

The last version currently considered clean isLiteLLM 1.82.6. Anyone who installed1.82.7or1.82.8should treat it as a full security incident, not a routine rollback.

What happened: two poisoned LiteLLM versions spread at PyPI speed

The compromised releases wereLiteLLM 1.82.7and1.82.8, posted to PyPI and later removed. The scary part isn’t just that they existed, it’s how quickly a single “pip install -U” can pull a bad update into a developer laptop or an automated build system.

LiteLLM is popular because it acts as a gateway: one API that lets apps talk to multiple large language model providers. That also means it often sits in the middle of internal tools and production-adjacent workflows, right where access tokens and deployment keys tend to live.

Researchers attributed the campaign to a group referred to asTeamPCP, which has been linked to other recent compromises. (Attribution in cyber incidents can be murky, but the tactics match a familiar playbook: hijack trust, then scale.)

Researchers say the malware was built to steal credentials, not crash systems

Security firm Endor Labs described the malicious code as a three-stage infostealer.

First came collection: anything that looked like a secret,SSH keys, passwords, cloud credentials,Kubernetes access tokens, and even crypto wallet recovery phrases, was targeted. The goal wasn’t immediate sabotage. It was reusable access.

Second was exfiltration. The data was bundled and sent out as encrypted archives to attacker-controlled infrastructure, traffic that can blend into normal developer activity, where machines constantly reach out to download dependencies, call APIs, and push artifacts.

Third was persistence. The malware attempted to install a backdoor disguised as a system service called“System Telemetry Service”, a name that looks innocuous enough to slip past a quick glance in a process list.

One technical twist made it even harder to spot: in1.82.8, researchers said a.pthfile could trigger the payload whenever Python starts, meaning the malicious code might run even if LiteLLM isn’t actively being used.

A security tool in the pipeline may have opened the door

The reported chain of events points to a classic software supply-chain failure: compromise the build process, then publish “official” releases using legitimate credentials.

According to the write-up, LiteLLM’s pipeline usedTrivy(a common open-source vulnerability scanner) without pinning to a fixed version. In setups like that, a compromised dependency can infect the very tooling used to build, test, and publish software.

At some point, researchers say, a compromised run in the pipeline exposed a secret key that allowed attackers to publish packages under LiteLLM’s name on PyPI. Once an attacker can publish as the project, they don’t need to trick users with lookalike packages, the real package becomes the trap.

The attackers also reportedly registered domains meant to receive stolen data, including one designed to resemble a legitimate LiteLLM domain:models.litellm.cloud. That kind of mimicry can defeat simplistic “allowlist” assumptions if teams don’t tightly validate outbound network destinations.

Why this can hit entire companies, not just individual developers

LiteLLM isn’t a niche library. The article cites public download numbers ofmore than 3 million downloads per dayand roughly95 million over the past 30 days. Even if only two versions were malicious, the blast radius can be huge because updates propagate automatically across modern engineering systems.

In many organizations, Python runs everywhere: CI/CD runners, data jobs, Docker images, shared notebooks, and internal services. If a compromised version lands in a build image that gets rebuilt and redeployed repeatedly, one bad update can replicate across an environment in hours.

The stolen items are exactly what attackers need to move laterally, cloud tokens, Kubernetes secrets, and.envfiles that often contain API keys for paid AI services. That can translate into data exposure, infrastructure compromise, and real money burned on unauthorized usage.

Some reports mentioned as many as500,000exfiltration events or infected devices, though that figure has not been independently confirmed. Even if the true number is far lower, the episode underscores a hard reality: your vendors, contractors, or upstream dependencies may have pulled the bad versions even if you didn’t.

What to do now: roll back to 1.82.6, and rotate secrets

The immediate reference point is straightforward:LiteLLM 1.82.6is the last version currently considered safe. But uninstalling or downgrading alone doesn’t “clean” a machine that may have already executed the payload.

Teams should identify any systems that installed1.82.7or1.82.8, including developer workstations and CI/CD runners, then treat them as potentially compromised. That means hunting for persistence mechanisms (including suspicious services) and reviewing logs for unusual outbound connections during the exposure window.

Most importantly, assume secrets may have been stolen. Rotate and revoke credentials that could have been accessible: cloud keys, Kubernetes tokens, SSH keys, deployment credentials, and any publishing tokens tied to build systems.

The bigger takeaway is uncomfortable but clear: PyPI, and any public dependency repository, can’t be treated as “safe by default.” This incident is likely to accelerate stricter practices in U.S. engineering orgs: pinned versions, internal mirrors, integrity checks, and tighter network monitoring on build runners. It’s not glamorous work, but it’s how you keep a routine Python update from turning into a company-wide breach.