What’s trending in AI on 22 October 2026: While most of the security world was patching PHP this week, a quieter attack hit the plumbing that connects businesses to AI models. On 21 October, a poisoned release of LiteLLM, the open-source AI gateway that millions of developers use to route requests to OpenAI, Anthropic, Google and other providers, went live on PyPI and Docker Hub with a credential stealer and a remote backdoor built in. The same evening, hosting platform Railway disclosed that an intruder may have read customer environment variables, the place where most apps keep their API keys, and said it believes the attack is part of a campaign aimed at AI inference providers. A day earlier, Wiz described attackers phishing Google Cloud accounts to run up huge Gemini bills on victims’ credit. Below: what happened, how to tell if you are exposed, and a ranked order for rotating keys.

1. What LiteLLM is, and why a poisoned release matters

LiteLLM, maintained by BerriAI, is a translation layer for AI. Developers call it once, in a single format, and it forwards the request to whichever model provider they choose. Many teams also run it as a proxy server: a central gateway that holds the company’s provider API keys, tracks spending per team and enforces rate limits. Socket puts its popularity at roughly 23 million downloads a week, and many agent frameworks and AI tools pull it in as a dependency, so plenty of businesses run it without ever having chosen it.

That central position is exactly what makes it valuable to an attacker. A LiteLLM proxy is, by design, a box full of keys to every AI provider an organization pays for. Compromise the gateway and you do not need to break into OpenAI or Anthropic; you inherit the customer’s access to them, and the customer’s bill. We have called the AI control plane the new crown jewel; this week proved it.

2. What happened on 21 October, hour by hour

StepSecurity reconstructed the timeline. The groundwork started a week earlier: the exfiltration domain litellm.dev and a GitHub account used as a “dead drop” were both created on 13 October. On the morning of 21 October, the attacker pushed ten commits to a lookalike repository named Berri-AI/litellm (note the hyphen), then kicked off LiteLLM’s real release workflow. Infected Docker images were built just after 11:00 UTC, the poisoned 1.107.0 package reached PyPI at about 11:40, and the floating Docker tags that many deployments follow by default were pointed at the infected image at 11:48.

The response was fast by any standard. Socket says its malware alerts fired about seven minutes after the PyPI upload. Researcher Lidor Machluf reported the compromise in LiteLLM’s GitHub issue tracker at 12:06, the package was gone from PyPI by 13:23, and BerriAI confirmed the infected Docker images were removed at 14:32. Still, anything that installed or pulled in that window, including automated builds and containers restarted on a latest tag, may have run the payload.

How did the attacker get release rights? LiteLLM’s director of security, Oliver Jensen, told The Hacker News the malicious actions came through three engineers’ GitHub accounts, apparently using stolen GitHub CLI OAuth tokens. One account triggered the release run and another approved it, which defeated the two-person check that was supposed to stop this. “All tokens which were involved in this attack have been revoked,” Jensen said, though the company has not yet determined how the tokens were stolen. The Hacker News notes a similar LiteLLM compromise in March, tied to the TeamPCP campaign.

3. What the malware does once it is inside

The cleverest part is how it starts. The infected wheels drop a tiny file called cook.pth into the Python environment. Python automatically processes .pth files at startup, so the payload runs every time any Python program starts in that environment, whether or not it ever imports LiteLLM. A second file, sitecustomize.py, launches a detached background process on Linux and macOS that checks a GitHub-hosted pointer every hour, downloads Python code from whatever server the pointer names and executes it. On Windows the loader fails, but the stealer still runs.

The stealer, which researchers call “privcollect”, runs 16 collection modules. Its list reads like an inventory of a developer laptop: credential files for Claude Code and Claude Desktop, Cursor, Windsurf, GitHub Copilot, Codex, Gemini CLI, Hugging Face, Ollama, Amazon Q and many more; AWS, Azure, Google Cloud and Kubernetes credentials; SSH, GPG and TLS private keys; npm, PyPI and other registry tokens; CI and infrastructure secrets; browser passwords and cookies; and the environment variables of every process it can read. If the machine is a LiteLLM proxy with a database configured, it also dumps the stored provider credentials and model configuration, which means the upstream API keys for every AI service the company uses. The haul is encrypted and posted to the attacker’s lookalike domain.

4. Railway: the host where the keys live

Hours later, Railway, a popular platform for deploying apps and APIs, published its own disclosure. It detected anomalous activity in the systems that store customer environment variables. An unauthorized party may have accessed the encrypted variables and, for some of them, the decrypted contents. Railway says the impact appears limited to a subset of users, that it will email affected customers directly, and that it believes the attack belongs to a series of recent intrusions against platform companies whose ultimate goal is to compromise AI inference providers.

Railway notified upstream providers so they could revoke exposed keys proactively, paused deployments, and according to The Hacker News rotated its own bucket credentials and invalidated Railway API tokens. Its advice to every customer, affected or not, is to roll all environment variables, including API keys and private registry credentials, and to review service logs for unusual activity. The damage was not hypothetical: security researcher Taylor Monahan reported that cryptocurrency wallets whose private keys were stored on Railway were drained, with the first theft at least two hours before the public notice.

There is no public evidence that the Railway intrusion and the LiteLLM release are the work of the same actor, and we are not suggesting they are. What links them is the target. Both went after the secrets that let software talk to paid AI services, in the places those secrets naturally collect. That fits a pattern we have tracked for weeks, from the Fireworks AI secrets breach to the OpenCode console breach and the market for stolen AI keys.

5. Google Cloud: when stolen access becomes a five- or six-figure bill

Wiz’s incident response team showed the end game on 20 October. Attackers bought Google Search ads for terms such as “google cloud” and “gcp” that led to a fake Google sign-in page, which captured passwords and MFA codes in real time. Within minutes they used the over-privileged accounts to enable the Gemini API in old, little-used projects, create service accounts and keys, and delete the organization policy that restricted IAM membership to company domains. Then they added outside Gmail accounts as billing administrators, linked their own projects to the victim’s billing account and demoted the real billing admins to read-only so they could not cut the link.

The point was compute. Victims were charged tens to hundreds of thousands of dollars in unauthorized Gemini usage within 24 to 48 hours, and because the work ran in attacker-owned projects, they could not even see what the prompts were. Security researchers call this LLMjacking: someone else uses your AI account and you pay. That is why AI keys are now worth stealing at scale, and why a gateway or hosting breach can become a finance problem within a day.

Incident	Disclosed	Where the attacker got in	What was at risk	First action
LiteLLM 1.107.0	21 Oct 2026	Release pipeline, via three engineers’ GitHub accounts	AI tool tokens, proxy provider keys, cloud and SSH keys, browser data	Find any install or image pull, rebuild, rotate everything the host could reach
Railway	21 Oct 2026	Systems storing customer environment variables	API keys, database and registry credentials, wallet keys	Roll all environment variables and review logs
Google Cloud LLMjacking (Wiz)	20 Oct 2026	Search-ad phishing of cloud admins, MFA codes relayed	Billing account, Gemini API access, org policies	Audit IAM and billing admins, set spend alerts and caps

6. Are you exposed? Where LiteLLM hides

Many businesses will not know offhand whether they run LiteLLM, because it often arrives as a dependency of something else. The table below lists the usual places to look and what a hit means. Socket adds an important warning: do not investigate by running Python or pip in the suspect environment, because starting Python is what triggers the payload. Use your package lock files, build logs, container registries and endpoint tools instead.

Where to look	What to search for	If you find it
Lock files and requirements (pip, Poetry, uv)	litellm==1.107.0, or an unpinned litellm resolved on 21 Oct	Treat every machine that installed it as compromised
CI/CD build logs	Builds on 21 Oct that pulled LiteLLM or an AI framework that depends on it	Rotate the CI system’s secrets as well as the app’s
Container registries and running containers	LiteLLM v1.107.0 images, or latest, main-latest, main-stable pulled during the window	Redeploy from a pinned 1.106.2 digest; purge cached and mirrored copies
Developer laptops	cook.pth, cook.py or an unexpected sitecustomize.py in site-packages	Rotate AI tool tokens, cloud keys, SSH keys and browser-stored passwords
DNS, proxy and firewall logs	Traffic to litellm.dev, the GitHub dead-drop path, or any /codepy request	A /codepy request means attacker code ran; widen the investigation

Cleaning up properly takes more than pip uninstall. StepSecurity’s guidance is to stop the background loader process first, delete the three payload files and the marker files, pin litellm==1.106.2, and replace any container built from an infected image rather than trying to clean it in place. On proxy servers, rotate every stored provider key plus LiteLLM’s master key and salt key. Then block the lookalike domain at DNS or your egress firewall so a missed machine cannot phone home.

7. The rotation ladder: which keys to change first

Here is a ranked ladder. When you suspect a stealer or a leaked secrets store, you rarely have time to rotate everything at once, so start at the top, where one stolen key does the most damage or costs the most money, and work down. Do the rotation from a clean machine, never from the one you suspect.

1. Cloud admin and billing access. Why first: it can create new keys, remove guardrails and attach someone else’s projects to your bill, as Wiz’s cases show.
2. AI provider API keys held by gateways and proxies. Why next: they turn directly into spend. Rotate the LiteLLM master and salt keys at the same time.
3. Source control and CI/CD tokens. Why: this is how LiteLLM itself was hit. Revoke CLI, OAuth and personal access tokens and deploy keys.
4. Package registry publishing tokens (npm, PyPI, Docker). Why: a stolen publishing token lets an attacker turn your product into the next poisoned release.
5. Hosting platform environment variables and database passwords. Why: they unlock production data. On Railway, roll all of them, as the company advises.
6. AI coding tool sign-ins on developer machines. Why: tools such as Claude Code, Cursor, Copilot and Codex keep long-lived tokens that the stealer explicitly targeted. Sign out everywhere and sign back in.
7. SSH, GPG and TLS private keys. Why: they grant quiet, durable server access and code-signing ability.
8. Browser-saved passwords and active sessions. Why: stolen cookies can bypass MFA. Force sign-outs on key apps.
9. Crypto wallet keys stored on any affected system. Why: theft is instant and irreversible.

Item 9 sits last only because most businesses have nothing there; if you do, it jumps to the top. After rotating, set spend alerts and hard budget caps on every AI provider and cloud account. A cap will not stop a breach, but it limits how big the bill can get while you find out.

8. What this changes for AI projects

First, AI middleware deserves the same scrutiny as payment software. Gateways, proxies, agent frameworks and coding assistants now hold keys that convert straight into money and data. Pin their versions by hash or digest, stop following floating latest tags in production, and add a short delay before new releases of high-risk packages reach your builds. A one-day cooling-off period would have kept automated systems clear of this release entirely.

Second, two-person release approval is only as strong as the tokens behind it. LiteLLM had a requester and an approver; the attacker simply held both. Short-lived tokens, hardware-backed sign-in for anyone who can publish, and release rules that only accept reviewed commits from the real repository are the controls that would have mattered.

Third, treat AI spend as a security signal. Sudden jumps in model usage are often the first visible sign of stolen keys, and the people who see them first sit in finance, not security. Connect the two. This is the same lesson as our briefing on attacks against AI stacks and Microsoft’s warning in its Digital Defense Report that attackers now move within a day. With this morning’s PHP2Shell patch rush still under way, teams are stretched, so keep the ladder short and ordered.

9. The bottom line

The AI boom has created a new kind of valuable secret: the key that lets software buy intelligence by the token. This week attackers went after those keys at three layers at once, the open-source gateway that stores them, the hosting platform that injects them into apps and the cloud account that pays for them. The fixes are not exotic. Know where LiteLLM and similar tools run, pin what you deploy, rotate in order of impact, and cap what an AI account can spend. If you used LiteLLM on 21 October or host on Railway, start at the top of the ladder today.

Frequently asked questions

Which LiteLLM version is compromised?

LiteLLM 1.107.0, published to PyPI and Docker on 21 October 2026. All seven platform wheels carry the payload, and the v1.107.0 Docker images were infected, as were the latest, main-latest and main-stable tags during the exposure window. Researchers point to 1.106.2 as the version to pin, by hash or digest.

Is uninstalling LiteLLM 1.107.0 enough?

No. The payload files run whenever Python starts and a background loader keeps running after removal. Stop the loader, delete cook.pth, cook.py and sitecustomize.py, rebuild containers from a clean image and rotate every credential the machine could reach, working from a clean device.

What data does the LiteLLM malware steal?

Its stealer collects AI tool credentials such as Claude Code, Cursor, Copilot, Codex and Gemini CLI tokens, cloud credentials, SSH and other private keys, registry and CI secrets, browser passwords and cookies, and environment variables. On LiteLLM proxy servers it also dumps stored upstream provider API keys.

How was LiteLLM compromised?

LiteLLM says the malicious actions came through three engineers’ GitHub accounts, apparently using stolen GitHub CLI OAuth tokens. One account started the release workflow and another approved it. The tokens have been revoked, and how they were stolen is still under investigation.

What should Railway customers do after the October 2026 breach?

Railway advises all customers to roll every environment variable stored on the platform, including API keys and private registry credentials, and to review service logs for unusual activity. Anyone who stored crypto wallet keys there should treat them as compromised and move funds.

What is LLMjacking?

LLMjacking is the theft of someone else’s access to AI models so that the victim pays for the compute. In cases Wiz investigated, phished Google Cloud accounts were used to run Gemini workloads that cost victims tens to hundreds of thousands of dollars within 24 to 48 hours.

---

Sources

• StepSecurity: litellm 1.107.0 compromised, backdoored PyPI wheels and credential stealer (21 Oct 2026)
• Socket: LiteLLM compromise analysis (21 Oct 2026)
• The Hacker News: LiteLLM compromised in supply chain attack delivering credential stealer and backdoor (21 Oct 2026)
• Railway: Security disclosure, Wednesday 21 October (21 Oct 2026)
• The Hacker News: Railway says intruder may have accessed customer secrets (22 Oct 2026)
• Wiz CIRT: From phishing to LLMjacking (20 Oct 2026)