- OX Security reports that LiteLLM 1.107.0, published to PyPI on October 21, 2026, contains an infostealer and a remote access trojan.
- The code runs whenever Python starts on an infected machine, so the package does not need to be used to do harm.
- OX advises pinning LiteLLM to 1.106.0, isolating affected machines and rotating every secret they could reach.
The gateway is where the keys live
An AI gateway has one job: it sits between a company's software and its AI providers. To do that job, it holds the keys to those providers. That makes it a very efficient place to attack.
OX Security reports that a tampered build of LiteLLM, numbered 1.107.0, appeared on PyPI on October 21, 2026. PyPI is the public index from which Python developers download packages. LiteLLM is one of the most popular open source tools for routing requests to AI providers, OX says. A tool like that usually runs close to a company's most valuable AI and cloud credentials.
The lesson here is that an AI gateway like LiteLLM concentrates secrets in one tool. Attackers do not need to break into the AI provider. They only need to reach the tool that holds the keys.
What the malware does
OX says the package combines two threats. One is an infostealer, which collects secrets from the machine. The other is a remote access trojan, or RAT, which lets the attacker connect and control the computer.
The stealer targets configurations, cookies, API keys and cloud data, according to OX. It reads passwords directly from browser data. It also reads command-line history on Mac, Linux and Windows. It goes after AWS and Azure keys. It also targets AI coding tools: Claude Code, GitHub Copilot and Cursor.
OX notes that the malware has no crypto-stealing behavior. Its researchers read that as a sign the attackers want personal and organizational data rather than quick payments.
The stolen data goes to litellm[.]dev. OX says this is a domain the attacker bought, not a LiteLLM server. The name is built to look like normal LiteLLM traffic.
Why reviewing the code would not have caught it
OX says the malicious code was placed only in the wheel, the pre-built file that pip installs. Reviewing the repository and its clean source would have shown nothing wrong. A team that audited the source would have approved what it saw and still installed something different.
Two files run first inside the wheel. The file sitecustomize.py holds the RAT logic and is not obfuscated. The file cook.py holds the stealer, hidden in a base64-encoded script. OX describes the whole package as heavily obfuscated, with several layers of command execution.
Starting Python on an infected machine is enough to trigger the code, OX reports. The project does not have to import or use LiteLLM. Installation alone is sufficient.
The attacker also keeps control. The malware reads the address of its control server from a GitHub URL, then connects. It checks the remote configuration every hour. A compromised machine can therefore receive new malicious code at any time.
A second hijack in one year
OX says LiteLLM has now been hijacked twice in 2026. The project was hit before: OX points to two March releases, 1.82.7 and 1.82.8, that were compromised in what it calls the TeamPCP campaign. The new attack, OX says, relied on different tools and servers from the March one. PyPI has quarantined the malicious release.
The OX post does not say how many machines installed 1.107.0, how the attacker gained access to publish, or how long the release was live. Those are the questions an incident team will want answered.
What to ask your team this week
OX's first step is a sweep of every environment, container and CI pipeline for version 1.107.0. Its second is to fix LiteLLM at 1.106.0, the version it names as safe. Pinning means fixing the exact version so an automatic upgrade cannot pull in a new one. OX also recommends a time-based installation delay for new releases.
OX says any machine that installed 1.107.0 should be treated as fully compromised and cut off from the network before cleanup. Then replace every secret it could reach: AI provider keys, cloud logins, database passwords, SSH keys and CI tokens. Teams that run a LiteLLM proxy should also replace the provider keys held in the proxy's own database.
OX sells security products and says its platform blocks this version for customers. The advice above does not depend on any product.
Leaders can ask four plain questions. Do we know every place LiteLLM runs? Do our builds pin versions? How fast can we rotate every AI key? Do developer laptops hold cloud and AI-tool credentials that one bad package could read?
A gateway is only as trustworthy as the last file installed into it. Check the file that runs, not only the code that was reviewed.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: OX Security.
