On 22 October 2026, the developer platform Railway confirmed that an attacker who had been inside its systems for more than a day had finally been locked out. That same night, a different attacker was inside the website of the .NET software company Avalonia, trying to push packages to its NuGet feed. Earlier in the week, the AI coding tool OpenCode, the hosting platform Zeabur and the popular LLM gateway LiteLLM had all reported breaches of their own.
These were different companies, hit in different ways, apparently by different people. What they had in common was what the attackers wanted: API keys, above all keys for AI services.
This post sets out what is publicly known about each incident, why stolen AI API keys have become worth stealing at this scale, and what any team building with large language models should check this week.
What happened, incident by incident
Railway: build infrastructure to encrypted secrets
Railway's preliminary incident report is the most detailed account of the week. By its timeline, the attack began at 13:58 UTC on 20 October with an attempted privilege escalation in its build infrastructure. Over the next day the attacker found further routes in, obtained CI credentials, and ran an unauthorised query against the store of customers' encrypted environment variables. A subset of those variables was decrypted. Railway confirmed the attacker had no remaining access at 03:32 UTC on 22 October, and normal deployments returned across all plans later that day.
Railway estimates that about 1.85% of workspaces, roughly 100,000, had some variables potentially exposed. It revoked every Railway access token, asked upstream vendors to revoke keys found on the platform, and urged all users to rotate their secrets. Its own reading of the motive is the important line: early evidence suggested the attacker "was attempting to obtain AI provider API keys to perform distillation attacks", and favoured workspaces holding many environment variables or many AI vendor keys.
Railway has not yet published a root cause, and says it cannot rule out access to source code until its final report.
Zeabur: three million environment variables
Zeabur, another deployment platform, reported that between 14 and 16 October an attacker used an internal cloud key to read secrets across a shared cluster. According to its disclosure, as summarised by Rescana, 3,218,965 environment variable records and 321,810 accounts were affected, and the attacker "was mainly looking for API keys they could use directly, especially keys for AI services". Zeabur has since announced it will shut down at the end of 2026.
OpenCode: linked provider keys
On 17 October OpenCode told users it had suffered a breach "related to a large-scale distillation attack" that affected 1.4% of OpenCode Console users, specifically those who had linked external providers. BleepingComputer reports that the access came through a legacy system the company was decommissioning, and that users were told their saved OpenAI and Anthropic keys may have been exposed and should be replaced.
LiteLLM: a poisoned release
LiteLLM is widely used as a gateway between applications and LLM providers, which means a LiteLLM host typically holds every provider key a company has. On 21 October a malicious version, litellm==1.107.0, was published to PyPI and to four Docker tags. Per the project's incident report, the PyPI wheels were live from about 11:39 to 13:23 UTC, and the Docker images until as late as 14:20.
The attacker used stolen developer credentials to change the release workflow so it built from a lookalike repository, Berri-AI/litellm, rather than the real BerriAI/litellm, and the poisoned artifacts were signed and published through the normal pipeline. The payload steals credentials and loads remote-code tools, and because it installs Python startup hooks it runs every time Python starts in that environment, whether or not the application imports LiteLLM. Socket's analysis describes it as targeting cloud and AI credentials. The last known-good version is 1.106.2. LiteLLM has since updated its report, so check the current version before relying on the detail.
Avalonia: an admin token in public JavaScript
Avalonia's incident is the smallest and the most instructive. According to its update, a build misconfiguration had exposed an administrator token for its website's content management system inside client-side JavaScript, apparently since at least April 2026. Between 22:37 on 22 October and 01:22 on 23 October an attacker used it, and made 39 attempts to publish packages to Avalonia's NuGet feeds. All 39 were rejected, and Avalonia says no customer data, licence keys or source code were exposed.
The request patterns pointed to ARTEX, an open-source, AI-assisted penetration-testing framework, or something built on it.
ConnectWise and Storm-0940: AI agents at scale
ARTEX also appears in the week's largest report. On 21 October Microsoft Threat Intelligence attributed the compromise of ConnectWise's Cloud Backup service to Storm-0940, a China-aligned actor. Using ARTEX's AI agents and the stolen identities of several ConnectWise cloud applications, the group attempted sign-ins to more than 2,250 Microsoft 365 tenants. Because those applications were already trusted inside customer tenants, no interactive user sign-in was needed, and in some environments the attackers reached privileged cloud access in under three hours.
This one is not about AI keys. It belongs in the story because it shows the other half of the picture: the same AI tooling that makes keys valuable is now being used to steal them faster.
Why attackers want AI API keys
A cloud password is valuable because of what it unlocks. An AI API key is valuable in itself, the way a company credit card is. Anyone holding it can run models and send you the bill. Security researchers call this LLMjacking: hijacking someone else's paid access to large language models.
There are three main reasons to steal a key at this scale:
- Free compute. Frontier model calls are expensive. A key that works can be resold or used until the owner notices the invoice.
- Distillation. A distillation attack uses a strong model's outputs to train a cheaper copy. Doing that needs a very large volume of queries, which is exactly what providers' rate limits and abuse checks are designed to stop. Spreading the queries across thousands of stolen keys belonging to real, paying customers is one way around those checks. Railway and OpenCode both named distillation as the likely motive.
- Cover. Traffic on a legitimate customer's key looks like that customer. It is harder for a provider to block than a brand-new account.
The pattern explains the targets. A platform that stores environment variables for thousands of applications, or a gateway that holds every provider key a company uses, is worth far more than any single application.
What this week teaches teams building with AI
Every incident above was a classic security failure: an over-privileged build system, a shared secret store, a stolen maintainer credential, a token in a public bundle. None of them required a flaw in an AI model. That is the uncomfortable lesson. The AI parts of a system are often built quickly, and the keys that power them inherit whatever habits the team already had.
A few points stand out.
- Secrets in environment variables are only as safe as the platform holding them. Encryption at rest did not help once the attacker could reach the systems that decrypt.
- A gateway or proxy concentrates risk. Putting every provider key behind one service such as LiteLLM is good engineering. It also makes that service the single most valuable machine you run.
- Unpinned dependencies are an open door. Anyone whose build pulled
latestduring a two-hour window on 21 October may have installed malware. - A build setting can publish a secret. Any environment variable a front-end build can read should be assumed public.
- Attackers are using AI agents too. Microsoft's report describes access to privileged cloud roles in under three hours. Detection that depends on a person noticing something over the next working day is now too slow.
A checklist for your AI API keys
If you build or run anything that calls an AI provider, this is the work for this week.
- Rotate. If you used Railway, Zeabur, OpenCode, or installed LiteLLM 1.107.0 or a matching Docker image, revoke and reissue every key that could have been reached. Railway's advice is to rotate anything stored before 21 October.
- Check your usage dashboards. Look at spend and request volume on every AI provider account for the past two weeks. Unexpected models, regions or traffic at odd hours are the first sign of a stolen key in use.
- Set hard spending limits and alerts. A monthly cap and an alert at a fraction of it turn a stolen key from an open-ended bill into a bounded one.
- Give each service its own key, with the least scope. One key per application and environment means one revocation, not an outage, and makes misuse traceable.
- Pin dependencies and verify them. Pin exact versions, commit lock files, and avoid
latesttags for anything that runs in production. - Keep secrets out of the browser entirely. Calls to AI providers belong on your server. Search your built front-end assets for key prefixes before every release.
- Use short-lived credentials where you can. Workload identity or tokens that expire in minutes limit what a stolen copy is worth.
- Review third-party app permissions. For Microsoft 365 or Google Workspace, list every multi-tenant application with access, remove what you do not use, and watch for new credentials being added to the ones you keep.
None of this is new advice. What has changed is the price of ignoring it. An AI key now pays an attacker directly, and the tooling to find one has become automated. Treat your AI API keys like money, because to the people taking them, that is what they are.
Details in this post come from the companies' own disclosures and the reports linked above, as published by 24 October 2026. Several investigations are still open, and the numbers may change.