Summary
After its August breach, the developer platform Zeabur reported that it had disabled or rotated its internal admin keys and other credentials, but a no-expiry admin token and other credentials were outside that rotation. In October, the shared cluster was entered with that token and an internal AWS key, and the GCP Dedicated Servers starting from an old GCP key, and users’ environment variables were read from the platform database. Zeabur is shutting down on 31 December. Reporting keys as rotated is not enough: unless revocation is checked each time an old credential is used, a key with no expiry keeps working.
A pre-execution check means checking, each time an admin credential is used, that it is valid now and allowed for this scope of operation, and keeping a record. Detection means noticing abnormal use after it happens.
no-expiry token still got in
What got through
- What got through
- Reading settings and running commands in the shared cluster’s admin interface with a no-expiry admin token and an internal AWS key (from 14 October). Root logins to 101 Dedicated Servers starting from an old GCP service-account key (Zeabur’s assessment). Reading the platform database with an internal read-only account (15 October, after the investigation had begun).
- What reaches the receiving side
- In general, what reaches an admin API or a database is a request over a legitimate path with a valid credential. Zeabur says no alert fired for about 36 hours after first use because valid credentials and legitimate paths were used.
- Not disclosed
- How the initial credentials were obtained (Zeabur names a possible link to a GitHub App private key leaked in August as a hypothesis, not confirmed), and where the old GCP key leaked from (Zeabur says neither can be confirmed). No statement identifying the attacker was found. Hetzner and DigitalOcean are said to keep no operation audit logs, and Zeabur says it cannot confirm whether the admin access to some servers was used.
Pre-execution check
Whatever the route, the condition for telling these apart is that the side receiving admin operations and data exports checks, before execution, the expiry, scope and revocation status of the credential used.
An admin key with no expiry becomes the next way in the moment it drops off the rotation inventory.
- Who issues
- The side that issues admin credentials (the platform’s administrators). Credentials are issued with an expiry and an allowed scope, and rotation and revocation status are kept in a single register.
- Where it is checked
- At the cluster admin API and at the boundary where database contents and secrets are exported. Each time a credential is used, it is checked that it has not expired, is within scope and has not been revoked; requests that do not match are not executed.
- What is left
- A record of which credential was used, when, from where and on what scope, so that after a breach it is possible to narrow down which values were read.
The token was revoked on the day the investigation began, but in the meantime the database was read, and a key rotated during the response was picked up by a backup and used. That admin keys can be used without having been revoked is a point shared with the LiteLLM poisoned release.
What Lemma does
Lemma builds the pre-execution check into the boundary that receives admin operations and data exports. It does not look for intrusions; it checks that the credential on an incoming request is valid now and within the scope it was given.
Industries and operations to watch
- IndustryDeveloper services
- Hosting, CI and deployment providers that hold users’ API keys and connection details. One admin credential reaches the secrets of many users.
- OperationAccounts & permissions
- Issuing, storing, rotating and revoking admin tokens, cloud keys and service-account keys, including how the scope of post-breach rotation is decided.
Current controls vs Lemma
The three columns correspond, from left to right, to this case’s shared-cluster admin API (path A), the read of the platform database, and the login to GCP Dedicated Servers (path B).
| Control | Reads and commands via the admin API | Database and secret exports | Server logins with a password |
|---|---|---|---|
| Rotating keys after a breach | Partial | Partial | Partial |
| Not storing secrets in plain text | Partial | Not relevant | Partial |
| Anomaly detection and alerts | Not effective | Partial | Not effective |
| Revocation and rotation after the investigation starts | Partial | Partial | Partial |
| Lemma (pre-execution check) | Effective | Effective | Not effective |
Rotation does not reach credentials missing from the inventory, and detection struggles to tell apart requests with valid credentials over legitimate paths. Lemma checks the expiry, scope and revocation status of a credential each time it is used.
Note: Lemma’s check works only where it is built into the admin API and data-export boundary and credential issuance and revocation are kept in one register. For the way in closest to this case (a no-expiry admin token was used), it works only where the register treats credentials without an expiry as invalid and does not let revoked credentials through. It passes if a credential within its expiry is stolen and used within scope, or if the checking system itself is taken over. Server logins with a password are outside this check. The table compares what each control checks; it does not show whether anything would have stopped this case. Lemma does not detect or prevent intrusion.
Three points for your organisation to check about admin credentials
- After rotating credentials following a breach, do you test that the old values no longer give access?
- Do you check that no plain-text keys remain in backups or configuration repositories?
- Are admin interfaces and admin APIs kept unreachable directly from the public internet?
Facts and timeline
- Service
- Zeabur is a developer platform for deploying and hosting apps (operated by Zeabur Inc., a Delaware corporation). Users store their apps’ environment variables (API keys, database connection details, signing keys and so on) on the platform.
- Path A (shared cluster)
- An internal AWS key and the shared cluster’s admin token. The token was created with no expiry on 10 January 2024 and written in plain text to a private configuration repository on 20 January 2026. The shared cluster’s admin interface was reachable from the public internet and allowed reading every service’s settings and secrets and running commands inside containers. On 15 October, about 53 production secrets were read (including internal-network admin credentials, database accounts and the GitHub App private key).
- Path B (GCP Dedicated Servers)
- An old GCP service-account key (where it leaked from has not been confirmed). Zeabur assesses that this key was used to read root passwords stored in plain text in the Dedicated Servers’ initial configuration. According to Zeabur’s timeline, the plain-text issue had been identified on 3 September but was not fixed at the time of the incident. 101 servers (belonging to 92 users) were logged into as root, and persistent SSH keys were added to 50.
- Database read
- At 15:30 UTC on 15 October, the attacker used internal-network admin credentials obtained via path A, from a compromised GCP server, to add a node to the internal network (per Zeabur). From that node it read the platform database with an internal read-only account (16:10–16:47 UTC): 3,218,965 environment variables and data on 321,810 accounts (the profile-page information, such as email addresses, usernames and phone numbers).
- Other impact
- Zeabur says the attacker ran commands in 865 database services (not every command succeeded), created 5 virtual machines in Zeabur’s GCP project and attached 16 copies of customer server disks to them, and that admin access to 359 Hetzner and 48 DigitalOcean servers was among the affected items, with use of it not confirmable.
- Backup key
- The cluster’s daily backups contained every secret. A key rotated at 15:40 UTC during the response was captured in the 16:00 backup and used by the attacker at 20:30 UTC, according to Zeabur.
Timeline
- The shared cluster’s admin token is created with no expiry.
- The admin token is written in plain text to a configuration repository.
- First breach. The report published on 7 September said the internal admin keys, database passwords and cache passwords had been disabled or rotated. The October preliminary report corrects that statement as incomplete: the cluster admin tokens and AWS keys were not covered.
- The internal AWS key is first used at 01:36 UTC and the admin token at 01:40 UTC. Root logins to GCP Dedicated Servers begin at 13:40 UTC.
- At 13:56 UTC, an investigation begins after a user report. Production secrets are still read (14:52–16:51), a node is added to the internal network (15:30) and the database is read (16:10–16:47). Admin-interface access is restricted (14:43), the admin token revoked (15:32), the attacker’s node removed (17:58), and the login signing key renewed with all users signed out (20:25). The attacker’s last activity is at 21:05 UTC.
- The shutdown is announced.
- The preliminary report is published.
- Guidance on migration, balance refunds and claims for breach damage (accepted until 30 November) is published.
Facts rest on Zeabur’s preliminary report (2026-10-19, to be updated), its August breach report, and its shutdown and migration/refund notices (all primary). What is not disclosed does not mean no measure was in place. As of 2 November, no follow-up to the preliminary report appears in Zeabur’s blog listing.
After disclosure
- Credential rotation: Revoked or rotated the admin token, the GitHub App private key, the login signing key, Hetzner and DigitalOcean tokens (01:09 UTC on 16 October), 11,536 platform access tokens and 566 zSend API keys, and disabled 24 AWS keys. Stopped putting plain-text secrets in cluster backups and stored the backup key separately from other secrets.
- Added detection: Setting up alerts for abnormal admin access, commands inside containers, bulk reads of secrets or the database, new internal-network nodes and cloud-key use from unfamiliar locations.
- Requests to users: Asks all users, including those who rotated after August, to rotate every password and key stored on Zeabur, and to treat database backups in the Taipei and Hong Kong regions as leaked.
- Shutdown and claims: Renewals of paid plans and Dedicated Servers stop from 1 December, and all services stop and data is deleted on 31 December. Users harmed by the breach are to file claims through support by 30 November (with the affected account and services, the type of leaked key, and third-party bills or usage records for the incident period).
Sources
- Primary, interim reportZeabur “Zeabur October 2026 security incident (preliminary report)”
- Primary, company disclosureZeabur “Zeabur August 2026 security incident”
- Primary, company disclosureZeabur “Zeabur is shutting down: what happens next”
- Primary, company disclosureZeabur “Zeabur service migration, refunds, and security incident claims”
- Primary, terms of serviceZeabur company information (Zeabur Inc., Delaware)
1 more (reporting, analysis)
- PressBleepingComputer “Zeabur shutting down after second security breach in two months”
References: The last layer left in AI-era cyber defense