Railway lost the keys its customers parked in it. Your PaaS holds your AI keys too.

01 What Railway has confirmed

Railway also notified upstream providers and asked them "to revoke all keys proactively" [ Railway 2026 ] . Read that sentence twice. A platform that asks your AI and cloud providers to kill your keys has concluded the keys are out.

Three things are still unknown. Railway has not said how many users were affected, beyond "a subset". It has not named the entry point or the attacker. And it has not said whether sealed variables, which cannot be read back from the dashboard, API or CLI, were in scope [ GitGuardian 2026 ] . Cooper told TechCrunch a post-mortem will follow [ TechCrunch 2026 ] . Until it does, the only safe reading is Railway’s own advice: every variable is exposed.

02 Three platforms in eight days

On 20 October we wrote about the OpenCode Console breach, where attackers took OpenAI, Anthropic and Google keys that users had saved in a half-retired system. That looked like one company’s bad week. Railway’s statement turns it into a pattern, and the dates line up.

Zeabur is the warning about where this ends. The Taiwanese platform says the intruder used leaked internal credentials stored in plaintext, including a shared-cluster admin token created on 10 January 2024 with no expiry [ Start With Identity 2026 ] . Zeabur confirmed root sign-ins on 101 Google Cloud servers, SSH keys added to 50 servers and 16 customer disk copies attached to virtual machines the attacker controlled. It suspects the credentials were taken in an earlier breach in August and never fully rotated. On 17 October the founder told customers the service will close. Shared-cluster services pause on 1 December and everything stops by 31 December 2026 [ BleepingComputer 2026 ] .

Zeabur has not linked its breach to the campaign Railway describes, so treat the three as related in target, unproven in actor. The target is what matters for your planning. All three platforms held secrets their customers had handed over so the code would run. TechCrunch also notes a CISA warning that China-based AI companies are running large-scale attacks on US companies to improve their own models [ TechCrunch 2026 ] . Stolen inference keys buy free model access at someone else’s expense. Platforms are where those keys sit in bulk.

03 Why your environment variables are the prize

Open the variables tab of any production service on a PaaS and count. A typical web app carries a database URL with the password inside it, an object storage key, a payment provider secret, an email API key, a GitHub token for private packages, and now one or two AI provider keys. Each came from a different dashboard. None of them knows it lives on Railway.

The platform sees all of them, for every customer, in one place. That is the design. A PaaS has to inject the plaintext value into your container at start-up, so somewhere in its estate a system can turn the encrypted copy back into the real key. An intruder who reaches that system reaches thousands of companies at once. Railway’s wording, encrypted variables with some contents decrypted, describes exactly that point of failure.

The second risk is the hop. The cloud key in your variables opens your AWS or Google Cloud account. Railway published separate guides for checking anomalous AWS, Google Cloud and GitHub access, and the AWS guide tells you to search CloudTrail for RunInstances, CreateUser, CreateAccessKey and PutBucketPolicy, and to compare Cost Explorer against the previous month [ Railway AWS guide 2026 ] . Those are the moves of an attacker turning one leaked key into a foothold that survives your rotation.

04 What to rotate first, and in what order

If you run anything on Railway, do this today. If you run on another PaaS, read it as the drill you will need when your platform sends the same email. Order matters. Changing the value in Railway does nothing if the old key still works at the provider.

• AI provider keys first. OpenAI, Anthropic, Google and any inference provider. These convert to money in minutes. Create a new key, update the variable, deploy, then revoke the old one at the provider and read the usage page back to 21 October.
• Cloud keys second. AWS, Google Cloud and Azure credentials. Create the replacement, deactivate the old key, then search the audit trail for new users, new access keys, new roles and instances in regions you do not use.
• Code and package access third. GitHub tokens, deploy keys and private registry credentials. Railway named registry credentials directly. A stolen registry token lets an attacker publish a poisoned package under your name.
• Data stores fourth. Database passwords, Redis URLs and object storage keys. Rotate the credential, then check connection logs for clients from outside Railway’s egress ranges.
• Everything else. Payment, email, SMS and webhook signing secrets. Railway API and project tokens created before the incident are already invalid, so recreate them and update the CI jobs that use them.

Rotate sealed variables too. Railway has not said they were outside the breach, and GitGuardian gives the same advice [ GitGuardian 2026 ] . Then check the copies. The same key usually sits in a developer’s local .env file, a CI secret store and a second environment. A key revoked in one place and live in three others is still live.

05 Make the next platform breach a one-hour job

Most teams discover their secrets inventory on the day they need it. They open each service, copy each variable name into a spreadsheet and try to remember which dashboard issued it. That is how a rotation that should take an hour takes a week. Zeabur shows what an unrotated credential costs the platform. The same arithmetic applies to you.

Railway did the right things fast. It paused every deployment, killed every token and told every customer to rotate. None of that brought the decrypted values back. Your exposure comes down to two numbers: how many live secrets your platforms hold, and how long your team takes to replace them all. We measure both in 14 days. You get the full inventory, what each secret opens, a tested rotation runbook and the alerts that catch the next stolen key on first use. Start with your Threat Map, from $5,000. Enterprise-grade. Not enterprise-priced.