LiteLLM got hijacked again: the AI gateway used to route traffic to dozens of LLM providers shipped a credential stealer with remote access built in
On October 21, 2026, a malicious version of LiteLLM (version 1.107.0) was published to PyPI. LiteLLM is one of the most popular open source gateways for routing requests to LLM providers, which means it usually sits right to an organization’s most valuable AI and cloud credentials.
The malware combines two threats in one package: an infostealer that harvests secrets from the machine, and a remote access trojan (RAT) that lets the attacker connect remotely and control the affected machine.
The malicious code was injected only into the “wheel” package, so reviewing the repository and the “clean source” would not have revealed anything wrong. The malware also contacts the URL litellm[.]dev, which is an attacker bought domain that could easily be seen as a legitimate domain instead.
This is the second time LiteLLM has been hijacked this year. In March, versions 1.82.7 and 1.82.8 were compromised in the TeamPCP campaign. This time the attacker used different tooling and infrastructure. PyPI has since quarantined the malicious release.
Anyone who installed or upgraded to litellm 1.107.0 from PyPI, on any operating system (macOS, Linux or Windows)
The malware runs every time Python starts on an infected machine, even if the project never uses LiteLLM. Simply having the package installed is enough.
Once running, it can steal LLM provider API keys, cloud credentials, environment variables, and the credentials stored in a LiteLLM proxy’s own database. The stolen data is sent to a lookalike domain built to blend in with legitimate LiteLLM traffic.
The RAT component checks in with the attacker regularly, so a compromised machine can receive new malicious code at any time.
Check every environment, container and CI pipeline for litellm 1.107.0, and pin LiteLLM to the safe version 1.106.0.
Treat any machine that installed 1.107.0 as fully compromised. Isolate it from the network before cleaning it up.
Rotate every secret that machine could reach: LLM provider API keys, cloud credentials, database passwords, SSH keys and CI tokens.
If you run a LiteLLM proxy, rotate the provider keys stored in its database as well.
The malware is heavily obfuscated with multi-stage layers of command execution, the first two files that run inside the WHL file are “cook.py” and “sitecustomize.py”. “sitecustomize.py” contains a RAT behavior and isn’t obfuscated at all, while “cook.py” contains a base64 encoded script inside.
The malware contains a configuration to check every 1 hour the configuration from the remote server. Additionally, it reads the remote C2 server from a GitHub URL, and parses the IP address of the C2 from it – then starts the connection.
The malware executes code it receives from the get_running_loop function
All of the malicious C2 RAT logic sits inside the “sitecustomize.py” file.
The infostealer logic sits under “cook.py” after deobfuscation, where it targets mostly configurations, cookies, API keys and cloud data. Crypto-stealer behavior is absent from this malware, showing that the threat actors aim to steal personal and organizational data rather than being directly financially motivated.
Reading Google Chrome profile data
Directly accessing user passwords from the browser data
Reading command line history from both Mac, Linux and Windows, including Python history and others:
Targeting cloud platform keys such as AWS and Azure
Targeting GitHub credentials
Targeting AI tools such as Claude Code, GitHub Copilot, Cursor
The malware sends the stolen information to litellm[.]dev – which isn’t is an attacker bought domain, not a LiteLLM server.
Threat actors compromised LiteLLM once again, this time in a way that avoids detection by pushing the malicious code directly inside the wheel file, where many scanners and detection tools might miss it.
While this might look like “yet another PyPI malware”, hiding inside the wheel file is one of the new ways attackers use to stay hidden and bypass common detections, like in npm, whenever a new protection is added – such as blocking preinstall hooks, threat actors will go out of their ways to find new techniques to reach their goals and execute code without being detected.
If you’re yet to pin versions or add a time-based installation delay, this should be yet another wake up call to take the time and do so before it is too late. Once these passwords and credentials are out, remediation will take longer than it takes threat actors to get what they want.
Malicious dependency vetting
litellm 1.107.0 is included in the OX Security malware database.
OX customers using VibeSec who try to install the malicious version will be blocked by the platform and pointed to a safe version.
OX customers pushing code with the malicious version as a dependency will also be blocked by the OX platform pipeline scan .
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAvxRBQMVXDXVskKS47haU
PZZ9wdcZInzptCsemXSx/8GMLGdCvOk3oX57m8QYZpdiUfhoT+zSMzfo22UteQWp
2tumv3HXXMMYgXEy8NXLjt78v1ciZQAj3CTOihhpvnRJiSfkD7DWG2348awGLxbS
XULT7tLejuyR6oDMz9mTT6faytJTWZFg+W88JJNJ4m8TBXfjzgsqXU+/AWvEcKMF
1KpBwikJqC4mwXm3pXaNQbp/AFJnmb6jzs0D2xPEabx6/deqqnHTzvQj3U4nbSHL
QTub1blDqjAVe5elVg8d5X75volMNZ/LoCE14JuVql878yM3BZ/OSqLPhqq6cB6n
wJJkrgFCPZ0LGrh3Wpoiqweh47eKnZ0cIyRV8lrB3vWD6fsvewjUAbWYl8YxfalZ
LBBLGTClDR4nuFYSV27c/7O58sgbEnjm5PD64S5oa2fZwfXyMv4GfgRT9J8JJ08w
LYhY84j7kcMRLZaIWLjFWgDRNOVznmSGJqfMBC+rBjHtT+NAlGJQDRhu3ufOdWi/
5iCqZ2H4iyy2kfRfmeHJJvAhLqUip0RNRtFLF8igYorIMLPbPon/t853IV14CDpd
opXR2WQ3Ipvr6nlR6ZxwVvMERW7mBCsObJuSuSEjJSoPmXKOMqIKvuqdHE4FTOiF
j8VSOdZz6ncfk+oJtzh0cZ8CAwEAAQ==
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
