Developer Platform Security Incidents: Railway, Zeabur and TiDB Cloud (October 2026)

TL;DR: In one week, three developer platforms disclosed security incidents involving customer data or secrets. Zeabur says an attacker used leaked internal credentials on 14 and 15 October to read environment variables and account data from its platform database, and ran read commands inside some customer databases. PingCAP says stolen service account credentials were used between 9 September and 7 October to copy TiDB Cloud account, billing and support-related records, while finding no evidence that data stored in TiDB was affected. Railway says an unauthorized party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents", with impact that "may be limited to a subset of users". No vendor has stated a common root cause or a shared upstream provider. We group them because they share a pattern: secrets and credentials held by a platform you or your suppliers deploy on. All three advise customers to act now as a precaution, including rotating stored credentials or API keys; Zeabur and PingCAP say explicitly not to wait for a direct notification. None of these incidents has a CVE.

Platforms such as Railway, Zeabur and TiDB Cloud hold the environment variables, API keys, database passwords and deploy integrations that applications need to run. When secrets stored on a platform are exposed, the risk is not limited to the platform itself: it can extend to the cloud accounts, AI providers, payment services and code repositories whose credentials were stored there. For most organisations, the bigger question is indirect: which of your SaaS suppliers build and run their products on these platforms?

Technical Information

All times below are converted to Cyprus time (UTC+3) from the UTC times the vendors publish. Where a vendor gives only a date, we give only the date.

Zeabur: leaked internal credentials, environment variables read (14 to 15 October)

Zeabur published a detailed preliminary report on 19 October and says the investigation is ongoing (Zeabur report). Zeabur states that "the root cause of this incident lies with Zeabur: long-lived admin credentials were stored in plaintext and could be used from the public internet."

What Zeabur says was affected (Zeabur's own figures and certainty labels):

• Platform database: 3,218,965 environment variable records (names and values) and 321,810 accounts (email, username, phone number and similar), plus project, environment and service data. Confirmed.
• zSend API keys: 566 keys stored in plaintext, all revoked. Confirmed.
• Platform Access Tokens: 11,536 tokens, stored only as hashes Zeabur says cannot be reversed, all revoked.
• Shared cluster: environment variables and secrets of all services in 9 regions; partly confirmed, the rest treated as leaked. Read commands were run in 865 database services; Zeabur says how much was actually taken "cannot be confirmed".
• GCP Dedicated Servers: root sign-ins confirmed on 101 servers belonging to 92 users; Zeabur classifies all 101 as affected hosts.
• GitHub App: the private key was read on 15 October and rotated the same day; Zeabur has "found no use of it so far".
• Hetzner and DigitalOcean servers: management tokens leaked; whether they were used cannot be confirmed.
• User database backups (Taipei tpe1 and Hong Kong hkg1 regions): whether they were downloaded cannot be confirmed; Zeabur tells users in those regions to treat backup data as leaked.

De-escalating facts Zeabur reports: the entry points used have been revoked or removed; for two-factor and passkey tables "only statistics were queried"; projects that moved their environment variables to their own Dedicated Server after Zeabur's August incident are "outside the scope of the platform database read"; and attempts to call Amazon Bedrock with Zeabur's AWS keys "failed and no charges were incurred". Of 890 Linode servers, Zeabur says the 847 with records show no attacker sign-ins.

Attacker intent, as Zeabur observed it: Zeabur says the attacker "was mainly looking for API keys they could use directly, especially keys for AI services", and stresses this is "only an observation of the attacker's intent". Zeabur also says how the attacker first obtained the credentials "currently cannot be confirmed"; its leading hypothesis, linking them to its August 2026 incident, is explicitly labelled unconfirmed.

Context for supplier reviews: Zeabur has announced it will shut down on 31 December 2026, and says incident-related loss claims must be submitted by 30 November 2026. Its 22 October notice adds that dedicated servers end on their own expiry dates, which may be earlier than 31 December (Zeabur claims notice).

PingCAP (TiDB Cloud): stolen service account credentials, records copied (9 September to 7 October)

PingCAP published its incident report on 19 October (PingCAP report) and recommended customer actions on 20 October (PingCAP customer actions).

What PingCAP says was affected: exported records included TiDB Cloud user names and email addresses, organization and project associations, SQL editor text and errors, and in some records organization, project and cluster identifiers; business and billing information including customer contacts, contract terms, orders, pricing, payment terms and billing configuration; and a table containing encrypted TiDB Cloud API-key values. PingCAP says these findings "do not mean that every customer had every category of information exposed" and that it is determining scope customer by customer.

De-escalating facts PingCAP reports: an external firm found "no evidence that the attacker ran commands or maintained persistent access" in the production systems reviewed; "there is no evidence that data stored in TiDB was impacted"; one investigator-owned API-key value from the exported table "could not be used directly as an API key"; and, on its customer actions page, PingCAP says it has "not found evidence that any were decrypted or used." In its Japanese notice, PingCAP says (Rescana translation) that neither it nor the outside investigators found unauthorized access to TiDB Cloud itself or any leak of credit card information, that up to about 50,000 items of personal information in Japan were leaked, and that it has reported the incident to law enforcement and to supervisory authorities in the relevant countries.

Still open, per PingCAP: customer-specific impact; whether other usable credentials were exposed; and whether the fixed vulnerabilities were exploited earlier. PingCAP notes that attacker claims about credentials in support materials "have not been verified". The Japanese notice describes the exposed key data as the encrypted public-key part only, with the private-key part not leaked, so the leaked public key alone cannot be used to operate TiDB Cloud (Rescana translation); the English report says only "encrypted TiDB Cloud API-key values". The two notices describe the same data at different levels of detail, and PingCAP has not publicly explained the difference. Either way, PingCAP recommends rotation as a precaution.

Railway: environment variables possibly accessed, builds paused (21 to 22 October)

Railway disclosed on 21 October (Railway disclosure) and has been posting updates on its status page (Railway status).

What Railway says was affected: an unauthorized third party "may have accessed encrypted environment variables and, for some of them, obtained the decrypted contents", which "may contain secrets such as API keys or database and registry credentials". Railway has reset the S3 credentials for every storage bucket and the GitHub tokens it held for account connections, and says GitHub access tokens stored as registry credentials "still work on GitHub until you revoke them" (Railway bucket and GitHub guide).

De-escalating facts Railway reports: initial analysis "suggests the impact may be limited to a subset of users"; Railway has notified upstream providers "to revoke all keys proactively"; and it will contact affected customers directly by email as it confirms them. Railway's disclosure gives no number of affected users, and Railway has not published a root cause (both checked 22 Oct, 18:34 Cyprus time).

Is there a common cause?

No common root cause or shared upstream provider has been confirmed by any primary source. Railway says it believes its incident "is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers", but it does not name the other companies. Zeabur attributes its incident to its own plaintext, long-lived admin credentials and observed the attacker hunting for AI service keys. PingCAP attributes its incident to stolen service account credentials and does not mention AI providers. None of the three vendors refers to the others. This post groups them because of the shared pattern, not because of a proven link.

Affected Product Versions

These are hosted services, so there are no product versions to patch. Per the vendors:

Workaround and Mitigation

What the vendors ask customers to do

Railway recommends that all users "immediately roll all environment variables, including any API keys, stored in Railway, as well as any private registry credentials, and review logs for those services for unusual activity" (Railway disclosure). Railway also says to:

• Create new Railway API tokens, because all existing tokens were invalidated.
• Redeploy services that use storage buckets so they pick up the new credentials, update anything outside Railway that used the old ones (local development, CI jobs), and reconnect GitHub.
• Revoke GitHub access tokens that were stored as registry credentials on GitHub itself.
• Follow its per-service guides, which cover rotating PostgreSQL, MySQL, MongoDB and Redis credentials and checking for anomalous GitHub, AWS and GCP access and unexpected OpenAI, Anthropic, OpenRouter, Grok and Stripe usage (Railway status).
• For GitHub, review security and organization audit logs, authorized apps, keys and tokens, and each repository's deploy keys, secrets, webhooks and collaborators, exporting the logs before revoking anything (Railway GitHub guide).

Zeabur asks all users to act now, "do not wait for a notification email", and to replace credentials again even if they were replaced after the August incident (Zeabur report):

• Replace all credentials in environment variables (API keys, cloud keys, database passwords, signing and encryption keys): revoke with the provider first, then create new ones and redeploy.
• Sign in again and recreate Access Tokens; zSend users must recreate API keys.
• Check the GitHub audit log for Zeabur GitHub App actions between 15 October 18:05 and 21:54 Cyprus time (unexpected clones or pushes, new deploy keys, modified webhooks).
• Review bills for each service from 14 October onward (from 1 September for GCP Dedicated Server users).
• Shared cluster users: change passwords inside databases, replace the n8n encryption key and recreate n8n credentials, revoke upstream AI keys used by new-api/one-api, and check PostgreSQL for unrecognised roles, functions, triggers, jobs or extensions. Users in the Taipei (tpe1) and Hong Kong (hkg1) regions should treat database backup data as leaked.
• GCP Dedicated Server users: treat the server as compromised and rebuild it; Hetzner and DigitalOcean users should check whether the root password was reset or the system reinstalled after 14 October.

PingCAP recommends two precautions (PingCAP customer actions): organization owners should replace active TiDB Cloud management API keys (create new, update and verify dependent applications, then revoke the old ones), revoking immediately and contacting PingCAP if misuse is suspected; and everyone should be alert to targeted phishing, because exported records included contact and billing details, so a message "can look credible". The Japanese notice also asks customers to review access logs and organization members and roles, and asks those who have issued API keys to rotate them (Rescana translation; PingCAP Japan notice).

Rescana guidance (general hygiene, not vendor instructions)

• Rotate at the issuer, not just on the platform. Changing a variable on the platform does not revoke the old key. Revoke it with the service that issued it (cloud provider, AI provider, payment provider, database).
• Cover CI/CD and deploy hooks. Include deploy keys, webhook secrets, CI tokens and container registry credentials that connect your repositories to these platforms, and rotate any copies held in other CI systems.
• Hunt for misuse after rotation. Review cloud audit logs, AI provider usage and billing, and repository audit logs from the earliest date each vendor gives. Rotation stops future use; it does not undo use that already happened.
• Reduce what the platform holds. Where possible, use short-lived or scoped credentials, and keep high-value secrets in a dedicated secrets manager rather than as plaintext environment variables.
• Plan for exit where needed. If you or a supplier still run workloads on Zeabur, its announced 31 December 2026 shutdown makes migration planning part of the response.

Indicators of Compromise

Zeabur published the indicators below in its report, reproduced as published with IP addresses defanged (Zeabur report). Zeabur says: "If you find any of the following indicators in your systems or your service providers' logs, treat the related credentials as leaked and contact us. The attacker made heavy use of rotating proxy servers, so the table lists only representative addresses." It also notes that these IPs "may be shared by proxy services, so the same IP alone cannot confirm who was operating it."

A match is a lead to investigate, not proof of compromise (Rescana guidance).

Railway and PingCAP had not published indicators of compromise when checked (22 Oct 2026, 18:34 Cyprus time).

Sources

• Railway: Security Disclosure: Wednesday October 21st (21 Oct 2026); status page, incident QH8L8B3E (checked 22 Oct, 18:34 Cyprus time; latest update 18:29); guides Redeploy Buckets and Reconnect GitHub After the Credential Reset and Check for Anomalous GitHub Access (22 Oct 2026)
• Zeabur: October 2026 security incident (preliminary report) (19 Oct 2026); status page incident (resolved 20 Oct 2026); service migration, refunds, and security incident claims (22 Oct 2026)
• PingCAP: Security Incident Report: Unauthorized Access to PingCAP (19 Oct 2026); Security Incident: Recommended Customer Actions (20 Oct 2026); Japanese-language notice (updated 21 Oct 2026)

No CISA, CERT-EU, NCSC, JPCERT/CC or TWCERT/CC notice naming these incidents was found (checked 22 Oct 2026, 18:34 Cyprus time).

Why this matters for third-party risk

You may never have signed a contract with Railway, Zeabur or PingCAP, but your SaaS suppliers may host their products or databases there, along with the keys to their cloud accounts, AI providers, payment processors and sometimes integrations with your systems. Each vendor describes limits on what it has confirmed, so a supplier on one of these platforms is not necessarily affected; the useful question is whether your suppliers know which platforms hold their secrets, and whether they have rotated them.

Forward this to your TPRM owner: Ask your SaaS suppliers this week which developer platforms and managed cloud databases host their production services, whether any of them run on Railway, Zeabur or TiDB Cloud, and, if so, whether they have rotated the secrets stored there (cloud, AI provider, payment and repository credentials, plus any integrations with your systems) and checked their logs for misuse. Ask them to confirm in writing (Rescana guidance).

Want to know which of your vendors depend on third-party platforms like these, and how quickly they respond when one has a security incident? Book a demo.