Railway, Zeabur, TiDB Cloud: When Your Hosting Platform Leaks Your Keys

Most business owners have never heard of Railway, Zeabur or TiDB Cloud. Plenty of them run on one anyway.

These are the platforms developers, agencies and AI coding tools reach for when an app needs to go live quickly. You connect a code repository, paste in a few settings, and the app is on the internet in minutes. Those settings include the secrets the app runs on: the database password, the payment key, the key behind the AI feature. In October 2026, all three platforms disclosed that attackers had reached data their customers trusted them with.

If someone built an app, a booking tool or an AI feature for your business in the last two years, this is worth ten minutes of your time.

What each company has said

All three published their own reports, and what follows comes from those reports. Each investigation is still open, so details may change.

Railway. An attacker was inside Railway's internal systems from 20 October at 13:58 UTC until 22 October at 03:32 UTC. They obtained CI credentials, the keys Railway's own build system uses, and used them to decrypt a subset of customers' stored environment variables. Railway says at most 1.85% of workspaces, about 100,000, had some variables potentially compromised. It says user accounts were not touched, and that its final report will confirm whether source code was accessed. Railway paused builds across every region, invalidated every Railway API token, reset storage credentials and the GitHub tokens it held, and asked providers including GitHub, GitLab, Anthropic, OpenAI, OpenRouter and Stripe to revoke exposed keys. Its advice: every customer who signed up before 21 October should rotate the secrets stored on Railway.

Zeabur. On 14 to 16 October, an attacker used leaked internal credentials to get into Zeabur's shared cluster, some dedicated servers and internal systems, and read the platform database: 3,218,965 environment variable records and 321,810 accounts. Zeabur's own report is blunt about why: "long-lived admin credentials were stored in plaintext and could be used from the public internet." One admin token had been created in January 2024 with no expiry and had never been rotated, including after an earlier breach in August. Zeabur has announced it will shut down on 31 December 2026, which it calls an operational decision.

PingCAP (TiDB Cloud). Between 9 September and 7 October, someone used stolen service account credentials to get into PingCAP's internal systems, copy data and obtain source code. The exported data included customer names and emails, contract and billing details, and a table of encrypted TiDB Cloud API key values. PingCAP says it has no evidence that the data in customers' databases was affected, or that the encrypted keys were decrypted or used. It recommends replacing TiDB Cloud management API keys and watching for targeted phishing that uses the stolen billing details.

No primary source has linked the three incidents. Railway says it believes it was part of a series of attacks on platform companies aimed at AI providers, without naming anyone else.

Why your keys were the prize

Railway and Zeabur say the same thing about what the attackers wanted: AI service API keys.

That makes sense once you see a key the way an attacker does. An OpenAI, Anthropic or OpenRouter key is prepaid access to an expensive model, and whoever holds it can use it while the bill goes to someone else. Railway's early evidence points to distillation, using stolen access to a large model to generate training data for another one. Zeabur saw the attacker search its database for keys they could use directly, read credentials stored in workflow tools like n8n, and try to call Amazon's AI service with Zeabur's own cloud keys. Those attempts failed. Zeabur is also investigating one customer's OpenAI key that ran about 1,107 image requests in an hour after the breach, and it is careful to say that is not yet proven to be connected.

The other keys matter as much. A Stripe secret key can issue refunds. A database password is your customer list. An email service key can send phishing from your domain. These are what sit in a typical app's environment variables.

The lesson is not "stop using platforms"

It would be easy to read this as "these platforms are unsafe, host it yourself". That is the wrong conclusion. A small business running its own servers usually makes the same mistakes Zeabur admitted to, a password that never expires and is reachable from anywhere, without a security team investigating at 3 a.m. All three companies published detailed timelines within days, which is more than many self-hosted breaches ever get.

The real lesson is simpler. Every platform you hand a secret to becomes part of your security. You cannot audit Railway's build system. What you can control is how much damage one leaked key does, and how fast you can replace all of them.

What to do today

If your app or any part of it runs on Railway, Zeabur or TiDB Cloud:

1. Make a list of every secret stored there. Database passwords, payment keys, AI keys, email and SMS keys, cloud keys, GitHub tokens, signing and encryption keys.
2. Revoke and replace each one at its source, then redeploy. Changing the value on the platform is not enough; the old key keeps working until you cancel it in Stripe, OpenAI, AWS or wherever it was issued. Revoke first, create the new one, update the app, redeploy. Update the copies on developers' laptops and in your CI too.
3. Check your bills and logs from mid-October. AI provider usage, Stripe activity and refunds, cloud spend, and your GitHub audit log for apps, keys or collaborators you do not recognise. Railway and Zeabur both suggest exporting logs before you revoke anything, so the evidence survives.
4. Close what does not need to be open. Railway recommends removing public network access to databases. A database only your app talks to should not answer to the whole internet.
5. If you are on Zeabur, plan the move now. The platform closes on 31 December 2026, and every secret you carry across should be a new one.

Even if you are not on any of these three, do the same exercise on whatever platform you use. It is a useful rehearsal, and you will find keys nobody remembers creating.

How to make the next leak cost less

The next platform breach is a matter of when, not if. These habits turn it from a crisis into a chore.

• Put a spend limit on every AI key. Every major AI provider lets you cap monthly spend or use project-scoped keys. A stolen key with a small monthly cap is an annoyance. One with no cap is an invoice. If you are running AI features in production, our FinOps for AI guide covers the controls in more detail.
• Use the narrowest key that works. Restricted Stripe keys, read-only database users for reporting, AI keys scoped to one project. A leaked key should only open one door.
• Keep one list of where every secret lives. Which platform, which provider, who created it, when it was last rotated. When the next breach notice arrives, that list is the difference between an afternoon and a week.
• Rotate on a schedule, not only after a breach. Zeabur's worst credential was more than two and a half years old. A key that changes every 90 days is worth far less to anyone who steals it.
• Watch for the bill, not just the breach. Alerts on unusual AI usage or cloud spend are often the first sign a key is out, and they cost nothing to set up.

This is the same pattern behind most modern breaches: attackers no longer break in, they log in with keys that work, or trick someone into handing one over. And if your app was built quickly with AI coding tools, it is worth reading how to ship AI-built apps without the breach, because those apps tend to keep their keys in exactly the places this month's attackers looked.

Want someone to check it for you?

Rotating keys properly, and setting up an app so a leaked key does little harm, is the everyday work of our cloud infrastructure and DevOps engineering teams. If you want to know what an attacker could actually reach with one of your keys, our VAPT service tests your app, APIs and cloud the way an attacker would, scores every finding with CVSS, retests for free once you have fixed it, and gives you a signed letter to show clients.

Tell us where your app runs and book a discovery call. We will help you work out what to rotate first.

Part of our guide to AI security.

Sources: Railway's preliminary incident report (22 October 2026, updated 26 October), Zeabur's October 2026 security incident report, PingCAP's security update and customer actions, and BleepingComputer's report on Zeabur's shutdown. Verified against these sources on 27 October 2026.