Attackers are hunting AI keys: OpenCode, LiteLLM and Railway hit
In five days, three services that handle AI keys were hit. Whoever steals such a key gets to use AI at your expense.
What happened
In five days, three services were hit that all look after the same thing: the keys that let software use AI models from OpenAI, Anthropic and Google. Whoever gets hold of such a key gets to use AI on someone else’s bill.
It started on the night of 16 to 17 October at OpenCode, an open-source AI coding tool. Attackers broke into an older OpenCode system, and the keys of 1.4% of the users of OpenCode Console leaked: the online service where you can store your own keys for AI providers. Some saw hundreds of dollars, and in a few cases more than $1,700, in charges overnight, and Google suspended some of their projects. According to co-founder Dax Raad, the attackers kept at it for 48 hours without a break, while OpenCode ran its own AI agents around the clock to hold them off. Anthropic and Google blocked the leaked keys; OpenAI is refunding the credits that were used.
On Wednesday 21 October it was LiteLLM’s turn. It is a widely used package that lets software talk to more than a hundred AI models through a single connection; according to Security.NL it is downloaded more than 92 million times a month. From 11:39 to 13:23 UTC an infected version, 1.107.0, was online, and the official Docker images pointed to an infected build until 14:20. The attacker held the login credentials of three of the project’s developers. With them, they switched off the code’s protections, had the official build pipeline build a release from a lookalike copy of the project, and then deleted the build records that could have helped the investigation.
The same Wednesday, the hosting platform Railway reported that an intruder had reached the systems where customers store their apps’ settings. Those settings often hold keys for AI services, database passwords and other credentials. They are stored encrypted, but for some of them the intruder may have seen the readable contents. Railway paused all new deployments, asked customers to replace everything and warned the AI providers so they could revoke leaked keys themselves. Railway sees the break-in as part of a series of attacks on platform companies, ultimately aimed at AI providers.
Replace every key and password you have stored with Railway straight away.
Railway’s advice of 21 October 2026, in short
The background
Why an AI key is worth money
There are two ways to cash in on a stolen AI key. The first is resale: you offer others cheap access to expensive models, and the key’s owner pays the bill. The security firm Sysdig described this in 2024 as LLMjacking and worked out that, in the worst case, a single hijacked account could cost its owner more than $46,000 a day.
The second is distillation: you put millions of questions to a strong model and train your own model on its answers. AI companies use the same technique to make their own smaller models, but without permission it means taking what someone else has built. In February Anthropic reported that three Chinese AI labs had used some 24,000 fraudulent accounts for more than 16 million exchanges with Claude, through middlemen who resell access. OpenCode itself calls the attack on its users a large-scale distillation attack, although it has not yet shown evidence for that.
What the infected LiteLLM release did
Most software is built largely from other people’s packages. Your colleagues pull them in with a single command, and unless a fixed version is set, the next install simply brings in the latest one. Anyone who installed or updated LiteLLM in those two hours or so got the infected release.
It dropped a small file that Python runs every time it starts, even in programs that never use LiteLLM. That file went looking for just about everything a developer keeps on their machine: browser passwords, SSH keys, access to AWS, Azure and Google Cloud, and the keys of AI tools such as Claude Code, Cursor and Copilot. Where LiteLLM ran on a server as the central gateway, it also read out the database that holds the keys to every connected AI service. Then it opened a back door that could fetch new instructions every hour.
Even cleaning up is tricky. LiteLLM tells affected users not to start with a fresh install, because every time Python starts, including for the installer, the stealer runs again.
Not the first time
LiteLLM was also infected in March; according to Security.NL that attack reportedly hit 2,500 organisations worldwide. Afterwards the project took measures that look exactly right on paper: releasing from a shielded environment, signed packages and versions that cannot be changed afterwards. This time none of that helped, because the attacker used real credentials and switched the protections off. On top of that, release permissions had been widened two days earlier, on Monday, so that two engineers could ship daily fixes.
How the attacker got those credentials is still being investigated. LiteLLM suspects they were in its own log files. According to LiteLLM, Claude Code can include a user’s GitHub token in a response, so anyone who logs all their AI traffic stores those tokens too. An internal LiteLLM installation was exposed to the internet, with an unexpected user account in it.
Our analysis
Attackers go for the places where keys come together
Look at what these three have in common. OpenCode Console stored its users’ keys, LiteLLM is the hub that all AI traffic passes through at many companies, and Railway stores the settings of its customers’ apps. Break into one such place and you get the keys of many companies at once. That pays better than attacking companies one by one. Our expectation: real keys from real customers will only become more valuable as AI providers get better at spotting fake accounts.
The most instructive part is LiteLLM’s story. After March the project did everything the checklists ask for, and still its own pipeline built and signed the infected release. Signed only means a package came out of the official pipeline, not that there is no thief inside. And the keys that opened the door were probably sitting in logs of AI traffic. If you keep AI conversations so you can review them later, you also keep everything that passes through them, and those logs need guarding like a password vault.
What would have helped is far less dramatic: waiting. A company that pins its versions and only takes on new releases after a few days would have stayed out of harm’s way here. It costs nothing and fits any way of working.
What stands out
- Log files turned out to be a key safe According to LiteLLM, the GitHub tokens that started the attack were probably in the logs of its own AI traffic.
- Signed is not the same as safe LiteLLM’s official build pipeline built and signed the infected release itself.
- Waiting would have helped The infected release was on PyPI, where Python packages come from, for less than two hours. Anyone who leaves new versions for a few days was never at risk.
- The defenders were stalled by their own AI At one point the AI models OpenCode used for its investigation refused to help, because the malicious code tripped their safety filters. Access to an OpenAI programme for defenders made it easier again.
What it means for you
If you use AI through a key, that key is worth as much to an attacker as cash.
- A key sits in more places than you think It sits in your colleagues’ tools, on the platform their software runs on and possibly in the logs of your AI traffic, and every package in that software can reach it. Any of those places can leak.
- Give every tool its own key with a limit If one leaks, it costs you no more than that limit. And you know at once which tool it was.
- Know what to replace When a supplier reports a breach, you want to know within the hour which keys are stored there. That only works if someone keeps track.
Where we come in · Support
We keep track of where your keys are
With Support, senior developers keep an eye on what your colleagues build with AI: keys left readable in the code, vulnerable packages and the services everything is connected to. And we set up a shielded development environment in which AI tools can only reach the project.
Do you know which AI keys you use, and where they are?
Tell us which AI services you use. We’ll think it through with you and always reply within one working day.
