al-ice.ai

Plaintext Tokens, Public Admin Panels, No Rotation Since 2024: Zeabur's Second Breach Ends the Platform

Agent & Supply Chain Security by al-ice.ai Editorial

Some breach disclosures end with “we take security seriously.” Zeabur's ends with the company itself shutting down. On 17 October 2026, founder Yuanlin Lin announced that Zeabur will wind down entirely: no new dedicated-server or domain purchases effective immediately, renewals disabled and shared-cluster services paused from 1 December, everything stopped by 31 December 2026. Two days later the company published its preliminary incident report for the 14–15 October breach — and the report is remarkable for how precisely it names its own failures. The stated root cause, in Zeabur's own words: long-lived admin credentials were stored in plaintext and could be used from the public internet. Attackers used those credentials to read 3,218,965 environment-variable records from the platform database, run commands in 865 database services, sign in as root to 101 managed servers, and — per BleepingComputer's reporting on the disclosure — attach 16 customer disk copies to their own virtual machines.

This is the second Zeabur breach in two months. In late August, attackers entered through a flaw in a customer's NextChat application, moved through poorly isolated internal systems, stole AWS credentials, and reached the production database. The October attacker plausibly started from credentials surviving that first incident — Zeabur itself says the August rotation did not cover the credentials used this time. That sentence is the one to sit with: the post-August rotation created a boundary the company treated as containment, and the attacker was standing on the far side of it. The admin tokens abused in October had no expiry, had not been rotated since they were created in January 2024, and were excluded from the post-August rotation, while the admin interfaces they unlocked stayed reachable from the public internet.

Two paths that met inside the internal network

Zeabur's report reconstructs the intrusion as two paths converging, all times UTC, with an evidence taxonomy worth adopting industry-wide: “Confirmed” means a log directly records it, “Assessed” means timing and content match without a direct record, “Cannot be confirmed” means no records exist (treated as leaked), and “Hypothesis” marks explanations supported only indirectly. Vendors that graded every claim this way would end the era of breach prose where “we have no evidence” quietly means “we have no logs.”

Path A — shared cluster and AWS. From 01:36 on 14 October the attacker used internal AWS keys, and from 01:40 the shared cluster's admin tokens — both stored in plaintext in a private configuration repository, obtained by a route Zeabur cannot confirm but hypothesizes traces to the GitHub App private key leaked in August. With the admin interface open to the internet and tokens that never expired, the attacker reached the shared cluster in 9 regions, read system secrets from 01:51, widened to all services' settings and secrets including environment variables from 12:39, and from 13:40 ran read commands inside user database containers — new-api/one-api instances first, n8n at scale from 15:41, PostgreSQL table-by-table from 16:50 — across 865 database services. An over-privileged cluster key then led to a backup of an old cluster, which contained a key into Zeabur's secrets-management service; from 14:52 to 16:51 on 15 October the attacker read about 53 production secrets, including internal-network admin credentials, a platform database account, and the GitHub App private key.

Path B — GCP dedicated servers. From 13:40 on 14 October the attacker signed in as root to 101 Zeabur-managed GCP servers, because those servers' initialization settings stored the root password in plaintext and the attacker held an old GCP key able to read them. From 14:26 on 15 October the attacker modified server settings to add its own SSH key; at 15:05 it pulled a production GCP key from the secrets service, and after Zeabur disabled the old key at 17:17, it used the new one at 17:28 to re-add the SSH key before that was disabled too at 17:31. An ominous footnote: from 1 to 5 September, an unknown source had already signed in to the same servers with the root password, reaching about 98 servers on 5 September alone. Zeabur states plainly that whether this was the same attacker cannot be confirmed.

The paths met at 15:30 on 15 October, when the attacker used Path A's internal-network admin credentials from a Path-B-compromised server to join a node to Zeabur's internal network — whose rules permitted the connection — then read the platform database through an internal read-only account from 16:10 to 16:47. Zeabur mapped all 29 database connections in that window to the rogue node: 8,903 operation records, every query traceable. The node was removed at 17:58; the last recorded attacker activity was 21:05.

The backup that captured the new key

The detail defenders should study hardest is the self-defeating rotation. Zeabur's daily cluster backups store all secrets. At 15:04 on 15 October the attacker read the backup access key; the replacement credential deployed at 15:40 was captured by the 16:00 backup, and the attacker used it at 20:30. Zeabur deleted the backup key at 18:51 and re-rotated at 21:47 — noting that use at 20:30 does not mean downloads were still possible after 18:51, since the attacker may have pulled the backup earlier. The lesson generalizes beyond Zeabur: any rotation performed while the attacker still holds backup-read access is just the next credential you hand them. Kill backup and snapshot access first, rotate second, and assume the announces of “we rotated everything” are only as good as the inventory of everywhere secrets are copied — backups, logs, container images, IaC state, and the private config repos where this whole incident started.

Why this is an AI-supply-chain story, not just a hosting story

Zeabur's shutdown post names the demand wave directly: “from n8n and OpenClaw to vibe coding, AI has created unprecedented demand for cloud deployment.” The October attacker's container reads started with new-api/one-api instances — LLM gateway projects — and scaled through n8n, the automation layer where AI-agent workflows live. Environment variables on a deployment platform are where provider API keys, database credentials, and registry tokens concentrate, which is exactly the asset class attackers spent October harvesting across the ecosystem: Railway's environment-variable disclosure on 21 October named AI inference keys as the assessed target, and the poisoned LiteLLM 1.107.0 release stole AI-provider credentials off developer machines. Zeabur is the third point on that curve — and the one where the platform decided the remediation cost exceeded the business. Customers who followed the August guidance and moved variables to their own dedicated servers escaped the platform-database read; everyone else must replace every password and key stored on Zeabur, even ones already replaced after August, revoke sessions, rebuild compromised GCP servers, and migrate by December — with a vendor-supplied migration guide the company suggests you can “hand to your coding agent.” After a breach that spread partly through plaintext secrets in repos, handing credentials-adjacent migration work to an agent with broad tool access deserves its own scoping review: least-privilege tokens, no production secrets in prompts, human approval on destructive steps.

What to do

  • If you ran on Zeabur: rotate everything, including post-August rotations. Every password and key ever stored on the platform, reissued at the provider side first. Revoke all sessions and tokens, rebuild any GCP dedicated server the attacker touched rather than cleaning it in place, and treat database contents read table-by-table as exfiltrated.
  • Migrate on the shutdown clock, and verify backups independently. Shared services pause 1 December; everything stops 31 December. Export data to infrastructure you control, confirm the data-deletion date when Zeabur announces it, and do not assume attacker-added SSH keys or disk attachments die with the account — audit the destination environment too.
  • Audit your own plaintext-credential inventory this week. Config repos, server init settings, IaC state, CI variables, daily backups: enumerate everywhere a long-lived admin credential is stored in recoverable form, then check each for expiry, rotation history, and network reachability of the interface it unlocks. Zeabur's root cause is a checklist item most estates have not actually completed.
  • Sequence rotations behind access revocation. Disable backup/snapshot access, old service-account keys, and public admin interfaces before issuing replacement credentials — otherwise, as Zeabur demonstrated at 16:00 on 15 October, the new secret lands in a store the attacker can still read.
  • Treat “series of attacks on platform companies” as a planning assumption. Railway's disclosure assessed its incident as part of a campaign against platforms to reach AI inference providers; Zeabur's attacker started on LLM-gateway and automation containers. Inventory every platform holding your inference keys outside a secrets manager with audit logging, and shrink that list.

Our write-up is analysis of Zeabur's preliminary incident report (19 October 2026) and shutdown announcement (17 October 2026), both read in full, plus BleepingComputer's reporting of the same disclosure for the server/disk figures. The investigation is ongoing and Zeabur says it will update the report; the September root sign-ins and the exact credential-acquisition route remain explicitly unconfirmed by the vendor. We did not contact any affected system or verify the intrusion independently.

Sources: