Railway breach: stolen customer AI keys ran up about $740,000 — rotate secrets stored before Oct. 21

Cloud hosting platform Railway says an attacker who broke into its build and secrets systems on October 20–21, 2026 stole customers' AI provider keys and ran up an estimated $740,000 in unauthorized AI usage. If you stored API keys, tokens or passwords as Railway environment variables before October 21, revoke and replace them at the issuing provider, then report any unexplained AI charges.

What happened, in plain English

Railway is a platform-as-a-service (PaaS): developers push code, and Railway builds and runs it. Like most such platforms, it lets customers store secrets — database passwords, cloud credentials, and API keys for AI services such as OpenAI, Anthropic, Google Gemini or AWS Bedrock — as "environment variables" that the app reads at runtime. Railway keeps those encrypted.

In its final incident report, published November 10, 2026, Railway explains that an attacker first used an as-yet-unknown flaw to partly escape the isolation of a shared build server. From there, the attacker chained several internal weaknesses: an over-trusted build credential, a misconfigured cloud identity binding, and a long-lived credential left on an internal machine that could decrypt customer variables. Within roughly 24 hours the attacker had queried the encrypted variables, filtered for names that looked like AI provider keys, and decrypted some of them.

Think of it like a valet service: the cars were locked, but a thief got into the back office, found the master key cabinet, and went specifically after the cars with full fuel tanks. Here, the "fuel" was prepaid or billed AI access. Stolen AI keys are easy to monetise — they can be resold as cheap access to expensive models, and the original key owner gets the bill. Researchers call this "LLMjacking" (hijacking someone else's large language model access).

Railway says it found no sign that customer databases were accessed or customer code repositories downloaded.

Are you affected? What to do now

Who should care: anyone who runs or has run services on Railway, and anyone whose team keeps AI provider keys on any hosted developer platform. Railway puts the upper bound for exposed environment variables at 1.85% of workspaces — about 100,000 — and says the figure counts environments, not individual variables. It also reset linked-account tokens for 1,852 users and says 353 builds' stored histories (including secrets passed to them) were read.

If you have never used Railway, there is nothing to patch, but the checklist below is still a good test of how your own AI keys are stored.

Checklist for Railway customers (based on Railway's preliminary and final reports):

• Rotate first. Revoke and re-issue every sensitive variable stored on Railway before October 21, 2026 — AI keys, cloud credentials, database passwords, payment-service keys. Do it at the issuing provider. Railway notes that filing a charge report does not revoke a key.
• Remove public network access to your Railway-hosted databases where possible.
• Check GitHub: review your account's audit log and the list of authorised apps.
• Check container registries (for example Docker Hub) audit logs for unexpected pushes or pulls.
• Review AI provider billing from October 20 onward for usage you don't recognise. Unusual model mixes, traffic from unfamiliar regions, or sudden spikes are the tell.
• Claim refunds. Railway's report lists the routes: AWS Bedrock and Google Gemini apply existing fraud refund policies (refunds have started); OpenAI and SpaceXSI review case by case — open a case with the provider and send the case ID to Railway support; Anthropic is still under discussion and Railway is covering breached-key costs in the meantime; OpenRouter does not refund, and Railway says it will cover those costs. Use Railway's charge report form for unrecognised usage.
• Re-authenticate if prompted — sessions, API/project tokens and GitHub logins were reset on October 21.

For everyone else (good hygiene, not an emergency):

• Give each AI key a spending cap and usage alerts at the provider.
• Scope cloud AI keys narrowly. In Wiz's analysis, a stolen AWS Bedrock key allowed to route requests globally was abused far more heavily than one restricted to a single region's quota.
• Keep an inventory of which third-party platforms hold your AI keys, so you can rotate within hours when one of them discloses a breach.

The expert view

Nothing in Railway's chain is exotic. A partial container escape, a credential trusted by more systems than it should be, an identity-federation (OIDC) binding that granted more than intended, and a long-lived secret sitting on a host that could call the key-management service — each is a familiar finding in a cloud review. What is notable is the target selection: the attacker went straight for variables named like AI provider keys. Railway says its forensics suggest the keys were "likely intended for resale for distillation" — using a frontier model's outputs to train a cheaper copy — but it has not established who ran the resale or attributed the attack to any group.

That pattern is not unique to Railway. Wiz's "Black October" tracker counted nine AI developer platform incidents in October 2026 alone (including Fireworks AI, Zeabur, Lightning AI, OpenCode, Warp and Northflank), with more disclosures added through November 10. Wiz found no single shared vulnerability; the common thread is attackers hunting stored environment variables that grant AI access. Wiz also notes that Fireworks, OpenCode and Warp reported signs of an "agent swarm" — automated, AI-driven tooling — in their incidents. Railway's report does not make that claim about its own breach.

Wiz's two Bedrock case studies show how industrialised the back end has become. Stolen keys were validated within 30 minutes, then lightly "pinged" for days to confirm they still worked, before bulk traffic began — about 800,000 calls in roughly 30 hours in one case, and about 1.7 million in 13 hours in the other. Wiz links the keys to two reseller operations it calls "momo" and "Xingjiabi", while stating it cannot definitively tie them to the original breaches. Google Threat Intelligence and Mandiant described the same resale economy earlier this month.

The lesson for defenders: AI keys have become the most liquid secret in a developer's environment. A leaked database password requires effort to exploit; a leaked frontier-model key turns into cash within hours, and the victim pays. That changes the cost model of secrets management — per-key spend limits, region and model restrictions, short-lived credentials and fast rotation now matter as much as encryption at rest. Railway's own fixes point the same way: per-build ephemeral virtual machines, audit-logged decryption, and least-privilege, just-in-time credentials.

Still unknown: the build-isolation flaw itself (Railway calls it unknown and has retired the affected systems); how the $740,000 estimate was calculated and over what period; whether the same actor was behind other "Black October" incidents; and whether the open refund questions with some AI providers will leave any customers out of pocket.

Related coverage on this site: Zeabur's two breaches, Fireworks AI's widened disclosure and the NEAR AI breach.

Official sources

• Railway — Incident report: October security incident (November 10, 2026)
• Railway — Preliminary report: October security incident (October 22, 2026)
• Wiz Research — "Black October" for AI Developer Platforms (October 30, 2026, updated through November 10)
• Coverage: The Hacker News — Railway says stolen customer AI keys led to $740,000 in charges
• Coverage: BleepingComputer — Railway breach leads to $740,000 in fraudulent AI charges