Zeabur, the platform developers used to put applications online without running servers, will shut down on 31 December. Its preliminary report on the October breach is one of the more detailed incident documents a company has published about its own closure, and the root cause is in its own words: "long-lived admin credentials were stored in plaintext and could be used from the public internet."

The token that was never rotated

A shared cluster admin token was created on 10 January 2024 with no expiry. On 20 January 2026 it was written, in plaintext, into a configuration repository. Neither fact changed for the next nine months.

August brought the first breach. Zeabur replaced the GitHub App private key on 31 August, and left the plaintext credentials in the repository alone. On 3 September its team found root passwords sitting in the initialization settings of its GCP servers, and had not fixed them when the second attacker arrived.

On 14 October at 01:36 an AWS key was used. Four minutes later, the admin token. By 12:39 the settings and secrets of every service on the shared cluster had been read.

What 3.2 million environment variables actually is

The platform database gave up 3,218,965 environment variable records and 321,810 accounts, along with 566 zSend API keys held in plaintext. An environment variable on a platform like this is not platform data: it is the database password, the Stripe key, the cloud token a customer pasted in so their application could reach something else.

Zeabur is blunt about what that meant: "the attacker was mainly looking for API keys they could use directly." The blast radius is therefore not Zeabur. It is every system those keys open, at every company that deployed there, most of which have no relationship with Zeabur at all.

The attacker also reached 865 database containers and signed in as root to 101 GCP servers, adding SSH keys to 50 of them.

The n8n number

Of 607 n8n instances Zeabur checked, 602 had their encryption key stored in an environment variable. n8n encrypts the credentials users hand it for third-party services, so with that key read, those stored credentials were effectively in plaintext as well. One leaked variable per instance unlocks every integration inside it.

Zeabur reports that a user's leaked OpenAI key was then used for about 1,107 image requests. Somebody checked whether the keys worked.

The company corrected its own report

Buried in the page is a paragraph more companies should copy: "The August incident report stated that 'all internal admin keys have been disabled or rotated.' That statement was incomplete, and we are correcting it here." The 31 August rotation was scoped to keys confirmed leaked, and the repository credentials were never in that scope.

A company that is closing has no commercial reason to publish that, and it did.

Its instruction to affected customers has the same quality: "Replace every password and key stored on Zeabur, even if you already replaced them after the August incident." To anyone on a dedicated server: "Treat your server as compromised."

Compare that with PingCAP, which said no TiDB database was reached and was telling the truth about a narrower thing than it sounded.

What to do

  • If you deployed anything on Zeabur, rotate every credential that was in an environment variable, including ones you rotated in August.
  • Revoke the old keys at the provider before you issue new ones. Rotating without revoking leaves the leaked key working.
  • Change database passwords directly in the database. Changing the environment variable does not change what the database accepts.
  • Replace your n8n encryption key and recreate the credentials inside it.
  • Review provider bills from 14 October, and from 1 September for dedicated servers.
  • If you ran a dedicated server there, rebuild it rather than cleaning it.

What is not established

  • Who the attacker is. No attribution appears in the report.
  • Whether the August and October intruders are the same party. Zeabur describes a hypothesis, not a finding.
  • Whether the user database backups in two regions were downloaded. Zeabur says it cannot confirm.
  • How many of the leaked keys have been used. One OpenAI key is documented.
  • Whether the Hetzner and DigitalOcean servers were touched with admin access.
  • What the final report will change. The published one is labelled preliminary and the investigation continues.