Railway and Heroku both got breached through shared infrastructure. Here's the actual pattern, not a sales pitch.

Two platforms that run a lot of other people’s applications have published real, confirmed security incidents in the last few years: Railway in October 2026, and Heroku in April 2022. Both are documented by the companies themselves, not rumor. And both trace back to the same underlying shape of risk: a vulnerability in infrastructure the platform operates on behalf of many customers at once, which turned into access to data belonging to customers who had nothing to do with the original flaw.

This post isn’t “every platform has been breached” — that would be false, and we’re not going to claim it. It’s two real, well-documented incidents, what they actually have in common, and what a bring-your-own-server model changes about that specific pattern. We already wrote a full breakdown of the Railway incident on its own: Railway’s environment-variable breach. This post looks at the pattern across both.

What actually happened, in both cases

Railway, October 2026. Railway’s own preliminary report describes an attacker who escalated privileges inside Railway’s build infrastructure, reached its CI environment, and from there accessed systems storing customer environment variables — decrypting a subset of them. By Railway’s own count, up to 1.85% of all workspaces, roughly 100,000, had some environment variables potentially exposed. The full timeline and Railway’s own words are in our dedicated breach post.

Heroku, April 2022. A threat actor obtained a Heroku machine account’s credentials, which had been left in an archived private GitHub repository containing Heroku source code. That access reached a Heroku database storing customer GitHub integration OAuth tokens, and from there into an internal customer database, where hashed and salted customer passwords were exfiltrated. Heroku disclosed this on April 15, 2022, revoked the GitHub integration’s tokens, forced a password reset for affected users, and the GitHub integration itself stayed offline until May 25, 2022. GitHub’s own security team separately confirmed the stolen OAuth tokens were used to access private repositories across dozens of organizations, including npm’s.

The pattern underneath both

Neither of these was a customer doing something wrong, and neither was a brute-force attack on an individual account. In both cases, the entry point was a piece of infrastructure the platform operates centrally — Railway’s build/CI pipeline, Heroku’s internal source control and machine-account credentials — and the exit point was data belonging to a large number of unrelated customers, reached through that one shared system.

That’s the actual mechanism worth naming: on a multi-tenant platform, the build system, the control plane, and the compute that runs customer code all typically sit inside the same operator’s internal perimeter. A credential leak or privilege-escalation bug in any one of those systems is potentially a path into everyone’s data, because “everyone” shares the infrastructure that bug lives in.

What a BYO-server model actually changes — and what it doesn’t

We wrote this carefully in the Railway post and it applies here too: Railyard’s own control plane stores customer environment variables centrally, encrypted at rest, the same general way any platform holding customer secrets does — Railway and Heroku included. A compromise of Railyard’s control-plane database and its encryption key is the same general class of risk any central secrets store carries, regardless of where the compute lives. Owning your own server doesn’t make that database disappear.

What changes is what the decrypted, live copy of a secret touches once it leaves that store. On Railyard, variables are decrypted once, at deploy time, and delivered to a server in that specific customer’s own cloud account — not to a shared compute fleet the platform itself operates. There’s no single build pipeline or CI environment whose compromise hands an attacker a foothold in other customers’ running applications, because there isn’t a shared fleet of running applications to pivot through. Every customer’s live environment is a different machine in a different account.

That’s a narrow, specific claim: it closes one path — a bug in shared platform infrastructure becoming a route into many unrelated customers’ live secrets at once — not every path. It is not a claim that Railyard, or anyone, is immune to a breach. A company that tells you it can’t be breached is a company you should be more skeptical of, not less.

What to actually do about it, on any platform

• Rotate secrets on a schedule, not just after a disclosure. A static, long-lived API key sitting in any platform’s dashboard is a standing liability independent of any one incident.
• Scope credentials tightly. The smaller the blast radius of a single leaked key, the less a breach of any kind costs you.
• Ask what has to be compromised to reach a decrypted secret in active use — not just whether data is “encrypted at rest.” Encryption at rest is table stakes everywhere; the real question is how many shared systems sit between a bug somewhere else on the platform and your actual running secrets.
• Read the incident reports companies actually publish. Railway’s and Heroku’s disclosures here are both genuinely informative when you read what they confirmed versus what got amplified secondhand — see our Railway breach breakdown for an example of separating the two.

See the full comparisons: Railyard vs. Railway and Migrating from Heroku.

FAQ

Has every PaaS been breached? No, and we’re not claiming that. This post covers two specific, confirmed, well-documented incidents — Railway (2026) and Heroku (2022) — not every platform in the market.

Does running your own server make a breach impossible? No. A platform’s control plane still has to store your secrets somewhere before deploying them, and that store is a target on any architecture, Railyard included. What changes is whether a bug in the platform’s shared build/compute infrastructure can become a path into other customers’ live, running secrets — on a BYO-server model, there’s no shared compute fleet for that bug to pivot through.

What’s the actual common thread between Railway’s and Heroku’s incidents? In both cases, the initial access point was infrastructure the platform operates on behalf of many customers at once (Railway’s build/CI pipeline; Heroku’s internal source control and machine-account credentials), and the impact reached customers who had nothing to do with the original vulnerability.

Sources

• Security Disclosure: Wednesday October 21st — Railway’s own blog
• Preliminary Report: Oct 21st Security Incident — Railway’s own blog
• April 2022 Incident Review — Heroku’s own blog
• Incident 2413 — Heroku’s own status page
• Security alert: Attack campaign involving stolen OAuth user tokens — GitHub’s own blog
• Heroku Forces User Password Resets Following GitHub OAuth Token Theft — secondary coverage