Developer and cloud credentials were put at risk when attackers compromised LiteLLM’s release pipeline. Version 1.107.0 on PyPI and affected Docker tags carried malware across Windows, Linux, and macOS. The payload ran during Python startup, stole secrets and environment data, and could fetch additional code; the packages were removed.
What Happened
Attackers compromised LiteLLM’s software release pipeline on October 21 and used it to publish a malicious version through PyPI and Docker. LiteLLM is an open-source Python software development kit and AI gateway that gives applications a common interface to models from different providers. Its broad use meant a release-channel compromise could place malware directly inside developer, cloud, and AI environments.
All PyPI installation packages for version 1.107.0 were affected across Windows, Linux, and macOS. Docker images carrying the bad build were published under version 1.107.0 and several commonly used tags, including latest, main-latest, and main-stable. The PyPI packages were available from 11:39 to 13:23 UTC, while the affected Docker images were served from 11:46 to 14:20 UTC. Multiple application security companies detected the attack within six minutes of publication.
The attacker did not change LiteLLM’s visible application source. Instead, malicious files were inserted into Python’s library directory through the installation packages. Python automatically processes those startup files, allowing the payload to execute whenever Python starts. That means launching Python or pip to examine a suspected installation could also run the malware.
The payload sought credentials, secrets, and environment variables. Reported targets included cloud credentials, Kubernetes and Docker access, Git credentials, SSH and GPG keys, browser data, database connection details, and authentication files associated with AI tools and services. A second component checked a GitHub-hosted pointer every hour and could download additional Python code for execution.
LiteLLM removed the malicious releases and identified version 1.106.2 as the latest clean version before the attack. Private enterprise customers using the project’s private registry were not affected.
Why It Matters
LiteLLM often operates where sensitive systems meet. A deployment may have access to cloud identities, provider API keys, databases, developer repositories, container platforms, and AI services. Malware running at Python startup can therefore collect valuable access material before the application itself begins normal work.
The installation method also complicates response. Removing the LiteLLM package directory or installing a clean version may not remove startup files or an active loader. Investigators can unintentionally execute the payload by using the same Python environment they are trying to inspect. Affected hosts consequently require compromise handling rather than a routine package downgrade.
There was evidence that stolen material moved quickly from collection to attempted use. Researchers observed credentials being validated about four and a half hours after data left victim systems. In some environments, the attacker checked AWS access and the ability to reach AI models through Amazon Bedrock. This makes immediate credential rotation as important as host cleanup.
The incident was also LiteLLM’s second supply-chain compromise of the year, reinforcing that recovery must address the release process and credential handling rather than only remove one bad version.
What to Watch
LiteLLM described the incident as contained, but its investigation was still underway. The company had not confirmed exactly how the attacker first entered its internet-facing internal deployment and said a recently patched vulnerability was a current suspicion.
The project believed the attacker used stolen GitHub CLI OAuth tokens associated with three engineers. One account changed the release pipeline and triggered the release, another approved it, and a third deleted workflow records. Investigators should watch for further findings about how those tokens entered logs and how much release history was removed.
Organizations should also watch for delayed misuse of credentials taken from affected hosts. Rotation should cover every secret available to the environment, not only credentials already seen in suspicious activity. The external loader’s ability to retrieve more code means teams should not assume the initially analyzed stealer represents the full possible effect on an infected system.
What Defenders Should Do
Exposure identification: Find every host, container, build runner, development environment, and deployment that installed LiteLLM 1.107.0 or used the affected Docker tags during the publication window. Do not rely only on the version currently installed because systems may have been downgraded after executing the malicious package.
Safe investigation: Stop affected deployments and inspect them without launching the resident Python interpreter or pip. Running those tools inside the compromised environment may execute the startup payload. Preserve relevant package, container, process, file, and network evidence before rebuilding when feasible.
Host recovery: Isolate affected systems and rebuild them from a known-clean source. Removing only the LiteLLM package directory may leave malicious Python startup files or a detached loader behind. Version 1.106.2 was identified as the latest clean release before the incident, but installing it is not a substitute for rebuilding a host that ran the poisoned package.
Secret response: Rotate cloud keys, developer tokens, Git credentials, SSH and GPG keys, registry credentials, Kubernetes and Docker access, database connection strings, browser sessions, and AI provider credentials that were available to the affected environment. Review associated services for unusual use before and after rotation.
Pipeline controls: Review release permissions, engineer OAuth tokens, approval paths, workflow changes, and deleted automation records. Reduce the chance that credentials appear in application responses or logs, especially where an internet-facing deployment can access those records. Confirm that publishing a release requires controls that cannot all be satisfied through several compromised user accounts.
Validation: Search for the malicious startup files and loader behavior described in the incident analyses, but treat their absence as only one part of the assessment. A clean package scan does not prove that secrets were not previously collected or that additional code was not executed.
The Larger Lesson
Software supply-chain defense cannot end with reviewing source code. In this incident, the application code was not changed; the installation artifacts and release process became the delivery mechanism. Organizations need confidence in the identity, approvals, logs, and integrity behind a release, not just the public repository.
The event also shows why credentials in developer and AI infrastructure carry concentrated risk. One poisoned dependency can reach cloud access, repositories, model services, containers, and databases at once. Recovery must therefore connect endpoint rebuilding with broad identity and secret rotation.