LiteLLM Update Stole Access Keys
A compromised LiteLLM release could exfiltrate credentials on Python startup. Why uninstalling the bad version is not enough and how to respond.
Short answer
The malicious LiteLLM 1.107.0 package could steal cloud and AI credentials merely by starting Python — uninstalling it does not revoke keys already copied. Isolate affected systems, rebuild from verified software, rotate every reachable credential, and treat AI dependency updates as governed supplier risk.
A software update is usually intended to repair faults or add features. On 21 October 2026, one widely used AI software component instead became a means of stealing passwords and digital access keys.
LiteLLM helps applications connect to different AI providers. Attackers compromised its release process and published a malicious version, numbered 1.107.0, through the official Python Package Index and software-container repositories. The affected releases were available for roughly two hours. Microsoft Security Research reported that merely starting the Python programming environment with the compromised package installed could trigger malicious code — even if an application never actively used LiteLLM.
The malicious files sought access details for cloud services, developer tools, browsers, and AI systems, and included a way to download further code. LiteLLM's later investigation traced the attack to an exposed master key that had not been revoked and to powerful developer credentials obtained through its agent platform. The company withdrew the releases. The full number of organisations affected, and whether stolen credentials were subsequently misused, remain uncertain.
What to do
For organisations that installed the affected version during the published exposure window, simply uninstalling it is not a complete response. Digital keys may already have been copied. Technical teams should isolate affected machines without starting the compromised environment again, preserve evidence, and rebuild systems using verified software. They must identify and replace every credential those systems could reach, including connections to AI providers, databases, and cloud accounts.
They should also check for suspicious activity after the original incident, review internal software mirrors and cached images, and establish whether the same credentials were shared elsewhere. A clean application screen does not prove that an attacker has lost access.
For everyone else, the case demonstrates why software purchasing and updating deserve management attention. Know which outside components an AI system relies on. Assign responsibility for urgent security notices. Limit what each component can access, and ensure exposed keys are promptly revoked rather than merely removed from a document or repository.
Sources
- LiteLLM, 21 October 2026 — original incident notice and affected versions.
- LiteLLM, 23 October 2026 — account of the attack chain.
- Microsoft Security Research, 23 October 2026 — malicious startup behaviour.
- ISO/IEC 42001 explained — International Organization for Standardization.
We document AI suppliers, connected systems, and credential scope, then build response plans for isolation, rotation, and recovery — through gap assessment and AIMS implementation.