Railway and Zeabur Breaches: When Your PaaS Holds Everyone's Secrets

CISO Platform Intelligence · Breach Teardown · Cloud & Supply Chain · Updated Oct 29, 2026

TL;DR

Railway's build infrastructure was compromised between Oct 20 and Oct 22, 2026 (UTC). The attacker reached a database of envelope-encrypted environment variables and decrypted a subset using CI credentials it had stolen. Railway says at most 1.85% of workspaces (about 100,000) may have had variables compromised.
Railway's preliminary forensics say the attacker wanted AI provider and platform API keys, reportedly for model distillation. Railway has not disclosed the initial entry vector and has not ruled out access to source code.
Zeabur had a similar incident on Oct 14–15: leaked internal credentials, reportedly stored in plaintext and not fully rotated after an August breach, exposed about 321,810 accounts and more than 3.2M environment-variable records. Zeabur is shutting down by Dec 31, 2026.

What happened (Railway timeline, UTC)

From Railway's preliminary report of Oct 22; the forensic investigation is ongoing.

When	Event
Oct 20, 13:58	On-call engineers paged for abnormal latency; an attempted privilege escalation in build infrastructure is identified and build pipelines are halted.
Oct 20, 17:03	Incident declared on the status page.
Oct 20, 19:53	Evidence that the attacker could escalate at scale across multiple parts of the system in parallel; an exploit earlier considered remediated.
Oct 21, 00:22–03:08	More access routes found; builds halted again.
Oct 21, 04:24–05:23	The attacker pulls secrets in encrypted form but cannot yet decrypt them.
Oct 21, 05:27–07:25	The attacker obtains CI credentials and decrypts artifacts containing additional API access.
Oct 21, 07:25–09:18	An unauthorized query runs against encrypted environment variables; a subset is decrypted.
Oct 21, 09:25	Railway notifies upstream vendors and asks them to revoke keys (the report's FAQ gives 09:35).
Oct 21, 20:19–22:10	User sessions invalidated; disclosure, customer guidance and rotation notices published.
Oct 22, 03:32	Railway confirms the attacker no longer has access. Pro and Enterprise builds restored by 06:29.
Oct 22, 17:00–22:49	Full API and deployments restored across all tiers.

Technical analysis

Systems touched: build infrastructure, a subset of internal systems, CI credentials, and the database of encrypted environment variables. Customer deployments kept running. Railway says the attacker did not log into individual user accounts.
How encryption was defeated: secrets were envelope-encrypted, but once the attacker held CI credentials it could decrypt part of what it had taken. Railway says the query alone does not tell it which specific keys in an affected project were exposed.
Targets: payload logs showed which API key names were targeted: AI provider keys and platform keys.
Not publicly known: the initial entry vector, the full scale of the exploits (withheld for now), the attacker's identity, and whether source code was accessed.

Why it happened

The root cause has not been published. From what Railway has disclosed: a privilege escalation in shared build infrastructure gave the attacker lateral movement; the CI environment held credentials able to decrypt customer secrets, collapsing the gap between "encrypted at rest" and "readable"; and Railway's fixes point to shared builders as a factor. It accelerated a move to single-tenant fourth-generation builders and rebuilt its tooling from validated source.

Who is affected

Railway reports about 4.8M users and more than 16M services (BleepingComputer). At most 1.85% of workspaces (about 100,000) may have had variables compromised.
Railway also asked providers to revoke every key it stored, as a precaution. Those revocations affected more than 100,000 users, so some keys broke even where nothing was compromised.
Railway is contacting impacted customers directly, plus a larger "high-risk" group (workspaces with very many environment variables or many AI vendor keys), and asking all users, especially accounts created before Oct 21, to rotate secrets.
Railway will not refund spend made with compromised keys; customers must pursue that with the AI providers.

How it affects CISOs: PaaS secrets concentration risk

A PaaS environment-variable store holds credentials for many other systems: databases, AI providers, registries, GitHub, payments. Railway's list of notified vendors included GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe. If the platform's own CI or control plane can decrypt those secrets, encryption at rest does little to limit damage when the platform is breached.

Zeabur shows how this gets worse (BleepingComputer): credentials not rotated after an August breach were reused in October; admin tokens had no expiry and had not been rotated since January 2024; admin portals were publicly accessible; attackers signed in as root on 101 GCP servers, added SSH keys to 50 servers and attached 16 customer disk copies to their own VMs. Zeabur says the October credentials likely came from the August breach but has not confirmed it. Affected customers now also face a forced migration.

Stolen credentials stay valid after the attacker is evicted from the platform. The real exposure is in your downstream services.

What to do

Immediate (24h)

List every secret stored on Railway or Zeabur. Rotate and reapply, prioritising AI provider keys, database credentials and private registry credentials.
Remove public network access to databases.
Review GitHub audit logs and installed GitHub apps; check registry audit logs (e.g. Docker Hub).
Check usage and billing at your AI providers for anomalies.

This week

Expect breakage from vendor-side revocations; confirm services are healthy after rotation.
Hunt in downstream logs for activity tied to the exposed identities; revoke credentials you no longer use.
If you were on Zeabur, plan migration before the Dec 1 pause of shared clusters and the Dec 31 shutdown.

Strategic

Move high-value secrets out of PaaS environment variables into a secrets manager you control; prefer short-lived, scoped credentials.
Require that post-incident rotation covers everything, including admin tokens (Zeabur's failure).
Add the PaaS's build and CI isolation, key custody and revocation tooling to third-party risk reviews.

Questions to ask your team and vendors

Which production credentials sit on third-party PaaS platforms, and who owns rotating each one?
Can the vendor's CI or control plane decrypt our secrets? Who holds the keys?
Are builds single-tenant? How are build workers isolated from secret stores?
After an incident, does the vendor rotate all credentials, including admin tokens, and can it show evidence?
Do our AI provider keys have spend caps and usage alerts? How fast could we rotate everything if a provider revoked our keys without notice?

Sources

Discuss: Has your organisation moved production secrets off PaaS environment variables? Which controls would have caught misuse of a rotated-too-late AI key?

How many of your production secrets live on someone else’s platform?

CISO Platform members are benchmarking how they govern PaaS secrets and third-party key custody. Join to see anonymous peer answers and share yours.

Join CISO Platform (free for security leaders) →

All Articles