Railway says attackers may have decrypted customer secrets in a hunt for AI API keys

What Railway disclosed

Railway, the cloud platform developers use to deploy apps and databases, said on 21 October 2026 that an attacker may have read the secrets its customers store on the service. In a security disclosure signed by Jacob Cooper, the company said it had "detected anomalous activity involving systems that store customer environment variables" earlier that morning, and that its investigation so far indicates "an unauthorized third party may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents."

Environment variables are where apps on platforms like Railway keep their configuration, and in practice that means passwords and keys: database credentials, cloud access keys, payment API keys, GitHub tokens and, increasingly, keys for AI model providers. Railway's post says plainly that they "may contain secrets such as API keys or database and registry credentials."

The company says its initial analysis suggests the impact "may be limited to a subset of users", but it is telling every customer to act as if they were affected. It recommends that users "immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials", and review the logs of those services for unusual activity. It says it will email affected customers directly once it confirms which accounts were hit.

Why AI API keys are the prize

The most striking line in the disclosure is about motive. Railway says: "We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers." It adds that it has "notified these upstream providers to revoke all keys proactively." The post does not name the providers, the other platform companies or the attacker.

Inference providers are the companies that sell access to AI models by the token, such as OpenAI, Anthropic, xAI and model routers like OpenRouter. A stolen key for one of them is directly worth money: whoever holds it can run large volumes of model calls and send the bill to the victim. Railway's own guidance for OpenRouter users spells this out, warning that a leaked key "spends your prepaid credits directly" and can route requests to any model on the service, "which shows up as models you never use."

A hosting platform is an efficient place to look for such keys. Thousands of small AI products, chatbots and agent back ends run on services like Railway, and each one needs a provider key in its environment to work. Getting into the system that stores those variables could yield a large batch of working keys at once, rather than one leaked key at a time.

What Railway has done so far

The disclosure came at the end of a long outage. Railway's status page shows it began investigating an issue at 07:24 UTC on 21 October. By 09:28 UTC its dashboard, API and command-line tool were unavailable and new builds were paused in all regions, and its support site was also down. Through the afternoon the company posted that builds would come back in stages, Enterprise customers first, and at 20:19 UTC it said it was "invalidating OAuth sessions as part of our mitigation", which signed some users out.

At 21:59 UTC the status page linked the security notice and said deployments remained paused, "including for Enterprise customers." Shortly afterwards Railway said it was rotating all storage bucket credentials itself, and that new credentials would appear in customers' dashboards automatically. A later update warned that audit logs would show the revocations performed by a named Railway employee, which it described as expected.

A Railway guide published on 22 October explains that two kinds of credentials were reset on customers' behalf: the access keys for every storage bucket in every environment, and the GitHub tokens Railway held for accounts and services. The old values no longer work. Railway says it did this "so the exposed credentials stopped working as early as possible", at the cost of customers having to redeploy services and reconnect GitHub.

That creates an awkward gap. As of the 02:19 UTC update on 22 October, builds were still offline, which means customers can revoke a key at its provider but cannot yet deploy the replacement to Railway. Railway acknowledges the problem on its status page and says some recommended steps "will have to wait until builds are available" while others can begin now.

What customers are told to rotate

Overnight Railway published thirteen step-by-step guides, linked from its status page. They cover database passwords for PostgreSQL, MySQL, MongoDB and Redis; cloud keys for AWS and Google Cloud; GitHub access; Stripe; and four AI providers: OpenAI, Anthropic, xAI's Grok and OpenRouter. Each one follows the same pattern: revoke or disable the exposed key at the provider, put a new one into Railway and redeploy, then review the provider's logs for activity you did not cause.

The cloud guides show why speed matters. Railway's AWS guide notes that access keys are long-lived, "so an exposed key works until you deactivate it", and tells users to search CloudTrail for calls such as RunInstances, CreateUser and CreateAccessKey in every region, since attackers often launch resources in regions victims do not watch. Its Google Cloud guide warns that service account keys do not expire by default and that short-lived tokens issued from an exposed key stay valid for up to an hour after the key is disabled.

For GitHub, Railway's guide asks users to check their security log, authorised OAuth and GitHub apps, SSH keys and personal access tokens, and to confirm that Railway did not deploy a commit they do not recognise. That last check matters because a stolen deployment token could be used to push code, not just read it.

Checking AI provider bills

The AI provider guides are the clearest sign of what Railway thinks the attackers wanted. The OpenAI guide tells users to delete exposed project or organisation keys, which takes effect immediately, to delete any exposed admin key, and to watch for spending that rose "without a matching change in your traffic." The Anthropic guide gives the same advice for the Claude Console, including admin keys that begin sk-ant-admin01, and notes that Anthropic already deactivates keys reported to it by GitHub's secret scanning.

The xAI guide recommends disabling rather than deleting a Grok key at first, because disabling is reversible and keeps the key's usage history attached for review. The OpenRouter guide suggests querying the exposed key's own usage figures before disabling it, and creating the replacement with a spend limit and an expiry date.

That last piece of advice applies well beyond this incident. Many AI providers now let customers cap spending per key or per project, and a key with a low limit and a short life does far less damage when it leaks. Developers who keep one unlimited, never-expiring key in every deployment are exactly the targets this kind of attack rewards.

A pattern of attacks on AI tooling

Railway did not say which earlier attacks it had in mind, and AI Lookout has no evidence linking its breach to any specific incident. But AI developer tooling has been hit repeatedly in recent weeks. On 17 October OpenCode reported a breach that exposed saved AI provider keys for some console users and linked it to a large-scale distillation attack. On 21 October, the same day as Railway's disclosure, LiteLLM 1.107.0 shipped a credential stealer through the popular LLM gateway's own release pipeline, targeting cloud, SSH and AI tool credentials.

Earlier in October, a compromised Tensorlake npm package ran a credential stealer on install. The common thread is that AI applications concentrate valuable secrets in a few places: gateways, coding tools and hosting platforms that hold keys for many providers at once. Attackers who once hunted cloud keys to mine cryptocurrency now have another way to turn stolen credentials into cash, by reselling or consuming model access.

What is still unknown

Much remains unclear. Railway has not said how the attacker got in, how many customers had variables decrypted, how long the access lasted, or whether any stolen keys have been used. It has not named the inference providers it contacted. It is also not yet known when builds will return; Railway's latest update promised more information by 03:00 UTC.

For now the practical advice is simple. Anyone who has stored secrets on Railway should assume they are exposed: revoke and replace AI provider keys, cloud keys, database passwords and tokens, check provider usage and audit logs from 21 October onwards, and set spending caps on the new AI keys. Railway says it will contact affected customers by email, and that its status page remains the fastest place for updates.