Railway Security Incident: Why Liability Stops at $100

On 21 October 2026, the US hosting provider Railway told its customers that an unauthorised third party may have accessed their stored environment variables and decrypted some of them. Those variables hold the keys to almost everything an application needs: database credentials, payment providers, AI services, cloud accounts. Railway advises every customer to replace all variables and halted builds for many hours. The company is not offering any compensation. Its terms of service cap liability at 100 dollars or the fees of the past twelve months, whichever is higher; business interruption and loss of data are excluded entirely. Cryptoticker.io, one of my companies, is a Railway customer and received the email too. My take as an entrepreneur: anyone running software today stores their most valuable secrets with platforms that stand behind almost nothing. That is a risk to digital infrastructure, and policymakers finally need to treat it as one.

As of 22 October 2026, 13:00 UTC.

More on this topic: AI in the Founder's Working Day, with background, practice and every article in one place.

Railway Security Incident: What Happened on 21 October

Railway is a platform on which developers and companies run their applications, databases and background services without managing servers. The San Francisco company was founded in 2020, raised 100 million dollars in a funding round in January 2026 and says more than two million developers use it (Railway on its Series B). For Europe it runs a region in Amsterdam.

On the morning of 21 October, the status page first reported a platform outage. Dashboard, API and command line went down, and new builds were halted in all regions. Only in the evening did the real reason come out. A security disclosure by founder Jake Cooper says Railway detected anomalous activity on the systems that store customer environment variables. An unauthorised third party may have accessed the encrypted variables and, for some of them, obtained the decrypted contents (Railway security disclosure). Railway believes this is part of a series of attacks on platform companies aimed at AI service providers.

What Railway does not say: how the attackers got in, exactly when the access was detected and which customers are affected. The disclosure speaks of a subset, yet advises everyone to replace all variables including API keys and container registry credentials and to review their logs. On the morning of 22 October at 04:17 UTC, Railway also invalidated all of its customers' own API tokens (incident status page).

The Railway Customer Email

The email reached us on 21 October at 22:37 UTC, which is 00:37 at night in German summer time. It came from Railway Support with the subject line „Urgent: Railway Security Disclosure - Rotate Credentials“. Its content matches the blog disclosure: anomalous activity, possible access to encrypted and partly decrypted variables, a suspected attack series against AI providers. Then three instructions: revoke and reissue all variables immediately, check credentials for external registries, review logs. And a note that no new versions can be rolled out until builds are restored.

Three things stand out. First, the second instruction breaks off mid-sentence: what customers with external registry credentials are supposed to do is simply missing. Second, the email says nothing about compensation, credits or a contact for damages. Third, it arrived hours after the first consequences. The service Postiz had already shut down for all customers at 21:11 UTC because Anthropic and Stripe had reported compromised keys to it, as its founder wrote on X (post by Postiz founder Nevo David). The email itself is factual and clear in what it asks. What is missing is everything that would help a customer estimate their own damage.

Timeline of the Railway Incident

By midday on 22 October, the status page listed 42 entries. The key moments, all in UTC:

Fourteen hours and 35 minutes passed between the first status entry and the notice about the security incident. Whether Railway recognised the attack early or only understood it during the day cannot be judged from the outside. For customers it means the same either way: a full working day passed in which they neither knew their keys were at risk nor could roll out new versions. Small customers on the cheaper plans waited more than 27 hours for their builds.

Why Environment Variables on Railway Are So Valuable

Environment variables are where an application finds its secrets. The database wants a password, the payment provider a secret key, the AI service a token, the mail system a login. On platforms like Railway, you enter these values in a dashboard and they are passed to the application at start-up. That is convenient and common. It also means that whoever opens this store holds the master keys of thousands of companies at once.

Railway's own remark that the attackers were after AI providers fits a pattern that has been growing for two years. Researchers at Sysdig gave it a name in 2024: LLMjacking, the hijacking of other people's access to language models. In their cases, the cost to a victim exceeded 46,000 dollars a day, and over 100,000 dollars with more expensive models (Sysdig on LLMjacking). In its threat report of September 2026, Anthropic describes how stolen AI keys have become the actual goal for several criminal groups; they are sold through brokers to networks offering cheap access to frontier models (Anthropic threat report, September 2026).

Railway is not alone. In April 2026, Vercel reported that attackers had entered through a third-party tool and read customer environment variables that were not marked as sensitive (Vercel security bulletin). The Asian provider Zeabur was attacked in August and in October; the second time, the attacker specifically searched for AI service keys (Zeabur on the October incident). On 21 October, the same day as Railway, a poisoned version of the widely used AI library LiteLLM sat on the Python package index for almost two hours and harvested exactly such keys (Wiz on LiteLLM). Whether the same people are behind all these cases is not established. The pattern is: whoever pools the keys of many customers becomes a target.

For crypto companies there is a second layer. Many trading bots and services keep private wallet keys or exchange keys in the same variables. Security researcher Taylor Monahan counted more than 500 transactions from over 200 addresses on at least 19 blockchains from 19:36 UTC, around 371,000 dollars in total, and attributes them to keys from Railway (Taylor Monahan on X). Railway has not confirmed the link. The timing is striking: the outflows began more than two hours before the public warning.

Railway Liability: What the Terms of Service Exclude

The short answer: almost everything. Railway's terms of service, in the version dated 20 April 2026, exclude indirect and consequential damages of any kind, expressly including lost profits, business interruption, loss of data, work stoppage and loss of goodwill. Everything else is capped, in the original „THE GREATER OF (I) ONE-HUNDRED ($100) DOLLARS OR (II) THE AMOUNTS PAID AND/OR PAYABLE“, meaning 100 dollars or the fees paid in the twelve months before the claim, whichever is higher (Railway Terms of Service).

The clause contains no exception for intent, gross negligence or breach of confidentiality. The services are provided without any warranty, expressly including no promise that they will run uninterrupted or error-free. The customer even indemnifies Railway against claims connected with third parties using their account. And the customer undertakes to protect their own credentials. The terms contain no security commitment of their own for the stored secrets.

Anyone hoping this is a recent tightening is mistaken. Comparing archived versions in the Wayback Machine shows that the liability clause appears word for word in the terms of 25 September 2021 and of 14 March 2024. The April 2026 revision mainly reworked the rights to customer content and incorporated the data processing agreement. The 100 dollars are not a trick from this spring but the basis of the business for years, and hardly any customer has ever read them.

Even the large Enterprise agreement expressly removes breaches of data security from recoverable damages (Railway Enterprise Agreement, section 11). If Railway breaches its security obligations and does not fix them within 30 days, section 4 leaves the customer termination as the sole remedy. The data processing agreement promises reasonable safeguards but subjects all claims under it to the cap of the main contract (Railway Data Processing Addendum).

For comparison, this is how Railway has handled outages before: after a wave of attacks and overload in February 2026, the company announced compensation (incident report, February 2026). The security disclosure of 21 October and the status page say nothing about credits, compensation or refunds. Precisely in an incident that goes to the heart of customers' secrets, customers are left alone with the work.

Who Would Be Liable for the Railway Damage Under German Law

Under German law, Railway's clause would stand on weak ground. Liability limits in standard business terms are void if they unreasonably disadvantage the other party (Section 307 of the German Civil Code). If a clause excludes liability for gross negligence, the Federal Court of Justice treats that as an indication of such a disadvantage even between businesses (judgment of 19 September 2007, VIII ZR 141/06). A cap must also cover the damage typical for the contract, and no one may contract out of a contract's core obligations. For a host, keeping customers' secrets safe is one of exactly those obligations.

The effort customers face now would also generally be recoverable under German damages law. In 2008, the Federal Court of Justice ruled that the working time of one's own staff can be compensated if it serves to remedy the damage itself rather than merely to assess or process the claim (judgment of 9 December 2008, VI ZR 173/07, paragraph 23, full text on Lexetius). Replacing keys, re-establishing connections and reviewing logs would be such work.

The catch: German law does not apply here. Railway chose the law of the US state of Delaware, and between businesses that choice is valid under Article 3 of the EU's Rome I Regulation. The protection that German standard-terms law gives small and mid-sized companies against such clauses ends at the choice of law. Disputes go to individual arbitration in San Francisco, class actions are excluded. For a company with damage of a few thousand euros, that is effectively the end of the story.

Data protection is a little different. If an affected database holds personal data, the Railway customer is the controller. They must assess within 72 hours and notify the supervisory authority where required (Article 33 GDPR). Towards affected individuals, the customer and Railway are jointly liable for the full damage (Article 82(4) GDPR); a clause between the two does not bind those individuals. Between customer and Railway, however, the cap applies again. Please note: this section is my assessment as an entrepreneur, not legal advice.

PHP2Shell: The Second Critical Flaw of the Same Week

On the same 21 October, security updates were released for PHP2Shell, two flaws in the PHP programming language tracked as CVE-2026-109618 and CVE-2026-109619. Both score 9.2 out of 10 under CVSS 4.0 and allow code to be executed on a web server without logging in. They are fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (announcement on php.net). PHP 8.1 and older versions no longer receive an official update, only source code fixes for specialists.

Germany's Federal Office for Information Security, the BSI, rated the situation orange and advised temporarily disconnecting systems from the internet if the update cannot be applied right away (BSI cyber security warning). The US agency CISA and the FBI gave the same advice (CISA alert). The security company watchTowr has observed exploitation in its honeypots since 21 October (watchTowr on PHP2Shell).

How large the attack surface is shows an analysis by the security service Mallory based on the Shodan search engine: of 2.6 million PHP services on the internet that reveal their version, 73.5 percent run PHP 8.1 or older. In Germany it is 100,805 out of 175,443, or 57 percent (Mallory on the PHP flaw). Anyone affected there cannot simply install an update but first has to move to a supported version.

Technically, PHP2Shell has nothing to do with Railway. Taken together, though, both incidents show how thin the layer has become on which our businesses run. On 21 and 22 October we measured our own PHP sites. The most important lesson for anyone on classic web hosting: in our case, the fix came from the host within the configured major version. Switching the PHP version in the control panel in a panic gains no security but risks a broken site. Measure which version is actually running first, then act.

AI Shortens the Time Between Flaw and Attack

With PHP2Shell, artificial intelligence was in play on both sides. The flaws were found by the security firm Calif as part of an OpenAI programme and independently by Wiz, which says it worked with the models Gemini 4 Argon and GPT-5.6 Sol. A single researcher achieved in a week what used to take a top team months (Wiz on PHP2Shell). In its warning, the BSI writes that attackers can use AI tools to analyse patches quickly and build attacks from them.

The figures are clear. In its M-Trends 2026 report, Google Mandiant estimates the mean time to exploit a vulnerability at minus seven days: on average, attacks begin before the patch appears. For 2018 and 2019 the figure was still 63 days (Google Mandiant, M-Trends 2026). VulnCheck counted almost one in four exploited vulnerabilities in the first half of 2026, 23.43 percent, as exploited on or before the day of disclosure (VulnCheck, first half of 2026).

A word on the headlines: one newsletter ran „AI hacks 70% of internet“ on 22 October. There is no study behind it. The 70 percent describes PHP's share of websites whose server language is known, 69.3 percent according to W3Techs (W3Techs on PHP). Those sites were not hacked, and it was the defenders' AI that found the flaws. The sober message is serious enough: the window between discovery and attack is closing, and anyone who does not install updates within hours becomes an easy target.

Where this leads, nobody knows exactly today. The same models that find flaws in days instead of months are open to attackers, and stolen access to those models has itself become loot. For companies this means: the way we have worked for the past ten years, putting everything with one convenient provider and relying on its diligence, no longer matches this pace.

Railway Customers: What You Should Do Now

Every key that sat in an environment variable on Railway should be treated as known until proven otherwise. Replacing it does not mean entering a new value in Railway. It is replaced at the issuer, at the database, the payment provider, the AI provider. Only once the old key is blocked there is it worthless.

1. Take stock. Go through all projects and environments and map every variable to its issuer: database, cache, storage, payments, email, AI provider, container registry, webhooks, your application's signing keys.
2. Prioritise by damage. First whatever moves money or opens customer data: payment and exchange keys, wallet keys, database credentials, AI keys with open quotas. Then email, analytics and monitoring.
3. Revoke and reissue at the issuer. Create a new key with as few rights as possible, enter it, roll it out, revoke the old one. For databases, change the user's password and close open connections. Move funded wallets to new addresses.
4. Read the logs. Check at each issuer whether the old key has been used from unfamiliar addresses since 21 October. Watch for new regions, unusual times and sudden cost spikes at AI services.
5. Check data protection. If a stranger could read personal data with the credentials, the 72-hour deadline for notifying the supervisory authority applies. The decision and its reasoning belong in writing in the file.
6. Document the effort. Hours, people, tasks, external invoices, extra cloud costs. Without this list there is neither a claim against Railway nor a notification to your cyber insurer.
7. File a claim. In writing to Railway, factual, asking for confirmation of whether your account was affected and requesting that logs and findings be preserved. The cap in the terms does not prevent you from asking for a voluntary solution.

Rethinking Infrastructure: What I Take Away From the Railway Incident

Platforms like Railway have made starting a company faster. Connect a repository, enter a few variables, and the application is online. I like using such services myself. But this convenience has a price that hardly anyone calculates: all of a company's keys sit in one place, with a third party, and that third party is liable for almost nothing. I draw five rules from this.

First: make keys short-lived. A key that is valid for a year is valuable for a year. Wherever possible, short-lived logins replace fixed passwords, for example via OpenID Connect with tokens that expire after minutes. Whatever must stay fixed belongs in a dedicated secrets vault, not in plain text in the host's dashboard.

Second: cut rights down. An AI key with a spending limit, a database user that can only read, an exchange key without withdrawal rights. If such a key is stolen, the damage stays limited. How I set up my own tools is described in my AI stack.

Third: practise the exchange. If you have never rotated your credentials, you do not know which services depend on them. A trial run at a quiet moment shows what breaks. In an emergency you then work from a list, not from memory.

Fourth: keep a second route ready. A provider can fail, block builds or change its terms. If you build your application as a container and keep the configuration in your own repository, you move in days instead of weeks. European providers such as Hetzner, IONOS, OVHcloud, Scaleway or Clever Cloud are ready for this. For data that should not leave the house, it is also worth looking at local AI for small and mid-sized companies.

Fifth: read contracts like technology. Liability cap, governing law, venue and notification deadlines belong in every provider selection, just like price and computing power. If the liability does not match the risk, cyber insurance closes the gap or another provider gets the contract.

Railway and Policy: Why Lawmakers Need to Act

Platforms like Railway have long been infrastructure. They run shops, booking systems, health apps, fintechs and the tools of thousands of small companies in Germany. When such a provider falls, many fall at once. Yet the law treats it like any software vendor free to shape its liability as it pleases. According to Bitkom's Cloud Report 2026, 85 percent of companies surveyed consider Germany too dependent on US cloud providers, up from 78 percent a year earlier (Bitkom press release). When it comes to liability, that dependence is particularly expensive.

The existing rules leave open exactly the gap the Railway case falls into:

The European Commission has recognised the imbalance itself. In November 2025 it approved draft model clauses for cloud contracts under which each party bears unlimited liability for intent and gross negligence, expressly including breach of confidentiality of customer data (draft Commission recommendation). These clauses are non-binding. And in Germany, the coalition agreement plans to relax standard-terms law between businesses, but only for contracts between large corporations. For the small customer of an international host, that changes nothing.

In my view, five steps are needed:

1. Make fair liability binding in cloud contracts. In the ongoing Digital Omnibus, clarify that Article 13 of the Data Act also covers the security duties of cloud and platform providers, regardless of the chosen law, as soon as the customer is based in the EU. The model clause on unlimited liability for gross negligence belongs in the law, not in a recommendation.
2. Enforce NIS2 for providers outside the EU. A public register showing which cloud provider has appointed which EU representative. Where none exists, the BSI can declare itself competent under Section 60 of the BSI Act. It should examine the Railway case.
3. Inform customers quickly and concretely. A maximum deadline, around 24 hours, and mandatory details for notices to customers: affected projects, time window, attack indicators. „Without undue delay“ is not enough when money is draining before the email arrives.
4. Include small businesses in software liability. The new product liability rules protect consumers. Minimum protection for micro and small businesses against security failures of cloud and software services belongs in the review of the directive.
5. Require audited security and exit plans where public money is involved. Anyone digitalising with subsidies or working for the state should choose providers with an audit certificate such as the BSI C5 catalogue and have a tested plan for switching providers.

Who You Can Write to About Railway

Politics responds to cases, not theories. If you are affected, tell the bodies that can change things. A short, factual message with your effort in hours and euros carries more weight than any press release.

Railway is not the first provider with such an incident, and it will not be the last. I hope we make more of it than a week of clean-up. You will find more of my views in politics and society. Were you affected too, and how much effort did it cost you? Write to me via the contact form, I reply to every message.

Frequently Asked Questions

What happened in the Railway security incident?

On 21 October 2026, Railway reported that an unauthorised third party may have accessed customers' encrypted environment variables and obtained the decrypted contents of some of them. These typically hold API keys and database credentials. Railway advises all customers to replace every variable and paused builds for many hours.

Am I affected as a Railway customer?

Railway speaks of a subset of customers and informs affected accounts by email, but advises everyone to rotate. Whether your own keys were misused shows in the issuers' logs, for example unusual access at your database, payment provider or AI service since 21 October.

Does Railway pay damages for the security incident?

Railway has not announced any compensation. Its terms cap liability at 100 dollars or the fees of the past twelve months and exclude business interruption, loss of data and lost profits. Customers can still submit their costs in writing and ask for a voluntary solution.

Does Railway's liability cap apply to German companies?

Under German standard-terms law it would very likely be void. But Railway chose the law of Delaware, which is permitted between businesses, and disputes go to arbitration in San Francisco. Towards affected individuals under the GDPR, however, the cap has no effect.

What is PHP2Shell?

PHP2Shell refers to two critical PHP flaws, CVE-2026-109618 and CVE-2026-109619, rated 9.2 out of 10. They allow code to be executed on web servers without logging in. They have been fixed since 21 October 2026 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The BSI advises taking unpatched systems offline if necessary.

What are good alternatives to Railway?

If you want to move, European providers such as Hetzner, IONOS, OVHcloud, Scaleway or Clever Cloud offer servers and platform services with data centres in the EU. More important than the provider is the setup: the application as a container, configuration in your own repository, secrets in a dedicated vault and a rehearsed plan for switching.

Best,
Dennis Weidner

Note: AI tools supported me in writing this article, and some images were edited with AI. I stand behind its content and every statement with my name.