Zeabur's Report: A Plaintext Admin Token With No Expiry, 16 Hours Without an Alert, 321,810 Accounts
Security / news
Zeabur's Report: A Plaintext Admin Token With No Expiry, 16 Hours Without an Alert, 321,810 Accounts
The hosting platform that is closing on Dec. 31 published an hour-by-hour timeline of its October breach and put the root cause on its own credential handling.
An attacker who held a Zeabur cluster admin token with no expiry, written in plaintext to a configuration repository, read the platform database and ran commands inside 865 customer database services on Oct. 14 and 15, and Zeabur's monitoring raised no alert during more than 16 hours of that activity. The hosting platform's own preliminary report says the root cause is its practices, and the company will stop operating on Dec. 31.
Zeabur's follow-up post is signed only "The Zeabur Team" and says: "Protecting those credentials was our responsibility, and we failed to do so." The report is preliminary and the investigation is open.
What the attacker needed
The entry was a credential, not an exploit. The shared-cluster admin token was created on Jan. 10, 2024 with no expiry and written in plaintext to a configuration repository on Jan. 20, 2026. The cluster admin interface was reachable from the public internet, and Zeabur lists that public reachability as a contributing factor. Zeabur says the repository was downloaded as an archive on Aug. 30 and Sep. 2 using an employee's GitHub authorization, by a downloader it has not identified, and that this link to October is a hypothesis.
BleepingComputer's report adds that the August incident began in a customer's NextChat application and moved through poorly isolated internal systems to AWS credentials. Zeabur had not rotated all admin credentials after August, and a September rotation missed the credentials in the repository.
The October 14 and 15 timeline
| Time (UTC) | Event |
|---|---|
| Oct 14, 01:36 | Attacker first uses a Zeabur AWS key |
| Oct 14, 01:40 | First use of the cluster admin token |
| Oct 14, 12:39 | Settings and secrets for all shared-cluster services read |
| Oct 15, 13:56 | Investigation starts after a user report |
| Oct 15, 15:04 | Cluster backup access key read |
| Oct 15, 20:30 | Attacker uses the replacement backup key |
The user report on Oct. 15 at 13:56 is what started the investigation, about 36 hours after the first use of the AWS key. The backup sequence is the detail most worth reading: Zeabur's daily backups contain all secrets, the attacker read the backup key at 15:04, Zeabur issued a new key at 15:40, and the 16:00 backup captured that new key. The attacker used it at 20:30. Zeabur had deleted the old key at 18:51 and rotated again at 21:47. Whether the backup itself was downloaded is assessed, not confirmed.
Counts in the report
- Accounts in platform database322K items
- Platform Access Tokens revoked12K items
- Database services with commands run865 items
- GCP servers with root sign-ins101 items
Source: Zeabur preliminary report, accessed 2026-11-12
The platform database held 3,218,965 environment-variable records. Zeabur found 101 GCP dedicated servers with root sign-ins by 92 users, attacker SSH keys on 50 of them, and 16 customer disk copies attached to five attacker-created virtual machines. It treats all 101 servers as compromised and recommends a full rebuild after backing up data.
Contributing factors Zeabur lists
The report lists contributing factors that would each be a finding alone: backups holding every secret beside their own key, a key meant for one storage bucket that could read all of them, a GCP default service account with project-level write access, and internal and customer services sharing one cluster. This is the same class of failure as the GitBook post-mortem, where a credential path ran from a customer-facing system into production.
What customers must do
Zeabur asks users to replace every credential in environment variables, check bills from Oct. 14 (from Sep. 1 for GCP users), recreate Access Tokens and zSend API keys, change database passwords, and rebuild any dedicated server. It says it cannot pay third-party charges caused by the incident and will help users request waivers from providers, with the report attached. Renewals end on Dec. 1, when shared-cluster services pause; shared clusters stop by Dec. 31. Zeabur's is one of nine October incidents Wiz lists; Chainstack's was another.
Sources
More in Security
- 01Wiz Counts Nine AI Developer Platforms Breached in October, All Aimed at Stored API KeysWiz's roundup finds no shared vulnerability, two Bedrock abuse cases totalling about 2.5 million calls, and root causes that are each platform's own account.
- 02Railway Puts Exposed Variables at 1.85% of Workspaces, About 100,000, After a Build-Infrastructure EscalationThe platform's preliminary report says the attacker was after AI provider keys for distillation, and leaves the entry point unnamed.
- 03Northflank's Timeline Has Secrets Decrypted at 02:39 UTC and the First Alert at 11:43The status page's Nov. 6 update measures its 60-minute patch claim from the alert, not from the start of the decryption window.
- 04GitBook's Post-Mortem: An SSO Flaw Gave an Attacker Staff Sessions and a Path to ProductionThe documentation platform says the intruder moved from one customer's hijacked account to a Cloudflare API key and full infrastructure access in 76 minutes, and that it is treating all customer data as exposed.