LiteLLM 1.107.0 malware and Railway leak: keys to rotate

Image: Unsplash.

Event dates: October 20 and 21, 2026, with two earlier starts: eMudhra's keys were reported on October 17, and TeamUpdraft found its intrusion over October 17 and 18. First reports: the LiteLLM compromise was reported in GitHub issue #47826 at 12:06 UTC on October 21, then by Wiz and The Hacker News the same day; Railway's disclosure went up on its blog that evening (UTC) and was picked up by CyberSecurityNews a few hours later.

LiteLLM is a proxy that sits between your apps and the model providers, which means its database holds the thing an attacker wants most: your provider keys. On October 21 someone got a poisoned build of it published under the project's own name. The stealer inside goes looking for exactly those keys, and if the proxy's database URL is set, it dumps the tables where LiteLLM stores them.

The same evening Railway, a hosting platform, said someone may have read customers' environment variables, and that it sees its incident as part of a run of attacks on platform companies aimed at AI inference providers. Put those two together and the job for this week is mostly key rotation. The patches below matter too, but they're the usual drill.

The patch table

Checked against each vendor's own advisory on October 22, 2026. The first three rows are the ones that touch AI keys and tenants directly.

LiteLLM 1.107.0: what to check and rotate

Screenshot: "LiteLLM release v1.107.0 Compromised", LiteLLM. Captured October 22, 2026.

How it got out is the part worth reading twice. LiteLLM's write-up says the attacker held GitHub CLI tokens belonging to three of its developers, used an organization owner's token to switch off branch protection, and pointed the release workflow at a lookalike repository, Berri-AI/litellm instead of BerriAI/litellm. The tokens most likely came from LiteLLM's own internal deployment, which was exposed to the internet and had an account nobody expected. The company says it has seen Claude Code embed a user's GitHub CLI token in a response body, and where response bodies are logged, those tokens end up in LiteLLM's logs. It hasn't confirmed how the attacker got into that deployment; its current guess is a recently patched vulnerability.

So there are two questions, and the second one applies even if you never touched 1.107.0.

Were you exposed? You were if an unpinned pip install ran in the PyPI window, or a container started from one of the four Docker tags in the Docker window (exact times are in the table). Run pip show litellm, and search for litellm-1.107.0.dist-info, cook.pth and sitecustomize.py. Finding one confirms it. Not finding one proves nothing, because containers and temp cleanup wipe the traces.

If you were, don't start with pip install: any Python start in that environment runs the payload again, pip included. From the shell, delete cook.pth, cook.py and sitecustomize.py plus their __pycache__ copies, kill the detached Python process holding /tmp/remote_code_loader.lock, then reinstall pinned to litellm==1.106.2 (rebuilding the image or venv from scratch is better). LiteLLM's rule is blunt: if 1.107.0 ever ran on a host with internet access, assume the theft worked. Rotate:

• every provider key stored in the proxy database, plus the LiteLLM master key and all virtual keys
• the DATABASE_URL password
• the instance or task IAM role, then check CloudTrail for GetCallerIdentity calls from it around install time
• any secret that sat in the environment of any process on that host

The original report, from Upwind's research team, adds that the stealer also collects credentials and configs for AI coding tools (Claude, Codex, Cursor and others). A second stage checks in every hour; it's dormant for now, but the operator "can re-arm it with a single commit." That's why a quick reinstall on top of an infected venv isn't enough.

Even if you weren't, look at your own gateway's logging. If your LiteLLM proxy stores full response bodies and your developers use coding agents through it, those logs may hold tokens. That's the same path LiteLLM believes was used against it. Turn body logging off or scrub it, and keep the admin UI off the public internet. LiteLLM also told enterprise customers about a separate vulnerability fix under embargo until October 27, so plan an upgrade window for next week.

Users on the issue have started asking for more than a fix. "After two compromises this year, being able to audit the release pipeline matters a lot to downstream users," wrote brammittendorff. We agree. This is LiteLLM's second poisoned release this year, after the March incident, and pinning an exact version (or a Docker digest) is now the minimum for anything that holds your provider keys.

Railway: roll every variable

Screenshot: "Security Disclosure: Wednesday October 21st", Railway blog. Captured October 22, 2026.

Railway found unusual activity in the systems that store customer environment variables. Someone may have read the encrypted values and, for some, the decrypted contents. Railway hasn't named the other platform companies in the series it describes, and its first look suggests only some accounts were hit, but the advice covers everyone: roll every variable, API key and private registry credential, and review logs. Railway says it will email affected customers directly. It also paused deployments, so check its status page before you plan a redeploy that depends on a new key.

One thing changes the order of work for AI teams. Railway asked upstream inference providers to revoke keys proactively, so some of your keys may already be dead. That's good, but don't stop at "the key stopped working": Railway's OpenAI guide has you revoke the key, group usage by API key to spot requests you didn't make, then redeploy with a new one. Do the same at every provider whose key lived in Railway.

https://www.reddit.com/r/devops/comments/1xc6bbp/

One r/devops poster put it plainly: "Railway's security incident is more serious than a normal outage. Customer environment variables may have been exposed."

Microsoft 365 and ConnectWise

On October 21 Microsoft tied the ConnectWise Cloud Backup compromise to Storm-0940, a China state-aligned group that used ARTEX, an open-source attack framework that can run on any AI model, to try to sign in to more than 2,250 Microsoft 365 tenants. If a ConnectWise or SkyKick app was ever consented in your tenant, even one you no longer use, disable it rather than deleting it, and look for app secrets added since October 13. Microsoft's post has the full mitigation list, and our ConnectWise breach checklist walks through the app IDs and the Entra steps.

Notes on the rest

Screenshot: "Security advisory: Critical remote code execution vulnerabilities, update now", php.net. Captured October 22, 2026.

PHP comes first if you host anything PHP yourself. The project says it has a working exploit against mod_php that fires before any application code runs, and CERT-EU warned the same day that proofs of concept had begun to circulate. Linux distributions got the patches in advance, so on a server you run, the fix is usually a package update from your vendor.

WordPress sites on UpdraftPlus Premium deserve a look even if you never used UpdraftCentral, TeamUpdraft says. The attackers created admin accounts and installed plugins through stolen connection keys, and the update that revokes those keys doesn't remove what they left behind. TeamUpdraft also thinks the attackers used AI to speed things up.

eMudhra's problem is weak private keys: anyone holding one of them could impersonate any website, Talos says. Chrome, Mozilla and Apple have blocked the six TLS certificates, and Microsoft the two code-signing ones. Talos expects more patches across other software as vendors catch up.

Screenshot: "Stable Channel Update for Desktop", Chrome Releases. Captured October 22, 2026.

Chrome 156 is a big one, with 353 security fixes in total. Two of the critical bugs were found with AI help: one is credited to a researcher at Anthropic "assisted by Claude," another to OpenAI Codex Security. The defenders' tools are getting faster too.

How to use this list

For a small team, we'd work it in this order. Today: answer the LiteLLM and Railway questions, because a stolen provider key keeps working until you revoke it, and nothing warns you it's gone. Also today: PHP, self-managed GitLab and Expressway, since none of them needs a login to exploit. This week: Chrome, Node.js, Snort-based firewalls and the WordPress check. Write down which keys you rotated and when; if a provider bill spikes next month, that log is what you'll need. Our API token leak playbook covers the first day after a key gets out.

What we could not confirm: how the attacker got into LiteLLM's internal deployment (LiteLLM hasn't confirmed it), which Railway accounts were affected or who the other targeted platforms are, and where SBI's exposed records came from. Nothing we read links the LiteLLM and Railway incidents to each other.

Related Reading

• LiteLLM supply chain attack (March 2026): what to check and rotate
• LiteLLM on CISA's exploited list: patch and audit steps
• AI supply chain security checklist
• OpenCode security breach: what to do with your API keys
• AI incident response plan template