The Zeabur breach was not a smash-and-grab. According to the hosting platform’s own preliminary report, published Oct. 19, an intruder used leaked internal credentials over Oct. 14 and 15 to move through its systems and read the database holding customers’ environment variables. Zeabur says the attacker’s main interest was keys that could be spent immediately, above all keys for AI services. It is the company’s second security incident since late August, and Zeabur has also said it will close on Dec. 31.
Where it stands: Zeabur says “the attacker’s last recorded activity was on October 15, 21:05” UTC (5:05 p.m. ET), that every user has been signed out, and that all platform access tokens were revoked. Its report is labeled preliminary, and Zeabur says the investigation is ongoing.
What the Zeabur breach exposed
Zeabur’s report sorts every finding into labels: Confirmed (a log records it), Assessed, Cannot be confirmed, and Hypothesis. The two largest items are both Confirmed:
| What was read or reached | Scope Zeabur reports | Zeabur’s label |
|---|---|---|
| Service environment variables (names and values) | 3,218,965 records | Confirmed |
| Account, project and service data | 321,810 accounts | Confirmed |
| zSend email API keys | 566 keys, now revoked | Confirmed |
| Commands run inside customer databases | 865 database services | Commands confirmed; output assessed |
| Root sign-ins to GCP Dedicated Servers | 101 servers | Confirmed |
The account data includes profile details such as email address, username and phone number, according to the report. The database read itself happened in a short window. Zeabur says the attacker read the platform database from 16:10 to 16:47 UTC on Oct. 15 (12:10 to 12:47 p.m. ET) through an internal read-only account, and it labels that finding Confirmed.
Not every command inside customer databases worked. Zeabur says “the attacker ran commands in 865 database services, though not every command succeeded,” and its logs kept the commands but not their results.
What the attacker was after: AI keys
The most telling passage in the report concerns intent. Zeabur writes that “the attacker was mainly looking for API keys they could use directly, especially keys for AI services.” It describes searches of the platform database for keys, bulk reads of stored credentials in n8n and in new-api/one-api (self-hosted gateways that relay requests to AI providers), and attempts to “call Amazon Bedrock with Zeabur’s AWS keys.”
Those Bedrock calls went nowhere. Zeabur says “every attempt failed and no charges were incurred.”
Whether customer keys were actually abused is less clear. Zeabur flags one case only as a hypothesis: a user’s OpenAI key stored on Zeabur was used to send “about 1,107 image generation requests” in the early hours of Oct. 16 UTC. Zeabur says it cannot rule out that the key leaked some other way.
Zeabur also stresses that the AI-key focus is an observation about intent, and that it treats everything the attacker read as leaked.
How it happened, in Zeabur’s words
Zeabur does not hedge on blame. “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.”
Several weak points stacked up, according to the report. Cluster admin tokens had no expiry and had been sitting in a private configuration repository. The admin interface could be reached from the internet. And “a deploy key for a decommissioned service remained valid four months after the service was shut down.”
Detection lagged too. Zeabur says the attacker used real credentials through normal access paths, so “the roughly 36 hours between the first known credential use (10/14 01:36) and the start of the investigation triggered no alerts.” Its own timeline shows the investigation began at 13:56 UTC on Oct. 15 (9:56 a.m. ET) after a user report.
How the attacker first got the credentials is still unconfirmed. Zeabur’s leading hypothesis ties it to its August incident, but the company says that is not proven.
Why the August fixes didn’t hold
Zeabur’s first breach began on Aug. 27, and the company says it “only confirmed this incident after receiving a report of API key abuse on August 28 at 02:34.” It rotated credentials afterward.
That rotation was incomplete. “The rotation in August did not cover the credentials used this time,” the October report says. Zeabur also retracted an earlier statement that all internal admin keys had been disabled or rotated, calling it incomplete.
One group of customers came out better. Zeabur says customers who followed its August advice and shifted their variables onto a Dedicated Server they control fell outside the platform database read. Their hosts could still be at risk if those servers were compromised.
What Zeabur users need to do
Zeabur’s instruction is blunt: “Please act now; do not wait for a notification email. Credentials you replaced after the August incident must be replaced again.” Its steps, in its own order:
- Every user: replace all credentials in environment variables, from AI and cloud API keys to database passwords and any keys used for signing or encryption. Zeabur’s guidance is to “revoke the old ones with the service provider first, then create new ones and redeploy.”
- Access tokens: sign in again, create new platform access tokens, and look for requests you don’t recognize.
- Databases on the shared cluster: change passwords inside the database itself. Zeabur warns that changing environment variables on Zeabur “does not change the passwords inside the database.” If your database stores your own users’ sessions or tokens, regenerate those too.
- n8n: replace the n8n encryption key and recreate every third-party credential stored in n8n.
- new-api/one-api: revoke the upstream AI service keys and issue new access tokens.
- GitHub: check your audit log for actions by the Zeabur GitHub App between 15:05 and 18:54 UTC on Oct. 15 (11:05 a.m. to 2:54 p.m. ET), looking for unexpected clones, pushes, deploy keys or webhook changes.
- Bills: review usage for each connected service from Oct. 14 onward; GCP Dedicated Server users should go back to Sept. 1.
- GCP Dedicated Servers: treat the server as compromised. Zeabur’s advice is to “back up your data and rebuild the server.”
For AI keys, the provider side matters as much as the platform side. Anthropic’s help center says that if a key may be compromised, it recommends “revoking the key immediately.” OpenRouter recommends “setting a credit limit on every key,” warning that a key with no limit “lets a leaked key or a runaway agent spend your entire balance, including any auto top-ups.” If a leaked key ran up charges, Zeabur says users can request compensation through a support ticket. Our guide on protecting API keys and tokens covers the longer-term habits.
Is this connected to Railway?
Railway disclosed its own environment-variable incident on Oct. 21 and said, “We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.” Railway named no other company. Zeabur’s report does not mention Railway, and no source found for this article links the two. They are reported here as separate incidents; our Railway explainer covers that case.
The Dec. 31 shutdown
Zeabur says it “will shut down on December 31, 2026,” and describes that as an operational decision. Until then it says it will keep answering support and compensation requests about the breach and update its report and status page. For customers, that means two jobs at once: rotate everything now, and plan a move before the platform closes. The October report already lists 101 GCP Dedicated Servers that Zeabur says received root sign-ins from the attacker.
Frequently Asked Questions
What happened in the Zeabur breach?
Zeabur says an attacker used leaked internal credentials on October 14 and 15 to get into its shared cluster, some Dedicated Servers and internal systems, and then read the platform database. That database held customer environment variables, account details and project data.
How many Zeabur accounts were affected?
Zeabur lists 321,810 accounts whose account, project and service data was read, and 3,218,965 environment variable records, both marked Confirmed in its own report.
What should Zeabur users do now?
Replace every key and password stored on Zeabur, even ones changed after the August incident. Zeabur says to revoke the old credential with the service provider first, then create a new one and redeploy. Change database passwords inside the database, recreate access tokens, and review bills from October 14 onward.
Is the Zeabur breach connected to the Railway breach?
No source has connected them. Railway has said it suspects a wider campaign against platforms, yet it has not identified any other victim, and Zeabur’s report does not mention Railway. Treat them as separate incidents.
When is Zeabur shutting down?
Zeabur says it will shut down on December 31, 2026, and calls that an operational decision. Until then it says it will keep handling support and compensation requests related to the incident.
Sources
- Zeabur October 2026 security incident (preliminary report) — Zeabur (Yuanlin Lin), October 19, 2026
- Zeabur August 2026 security incident — Zeabur, September 7, 2026
- API Authentication – Secure Access to OpenRouter — OpenRouter documentation, undated docs page (fetched October 21, 2026)
- What should I do if I suspect my API key has been compromised? — Anthropic (Claude Help Center), undated help article (fetched October 21, 2026)
- Security Disclosure: Wednesday October 21st — Railway (Jacob Cooper), October 21, 2026
This article is news reporting and general security information based on the public sources listed above, as they stood on the dates shown. Incident details often change as investigations continue; check the affected company’s own status page and notices for the latest. Data Breach Radar is not affiliated with any company named here.