Zeabur: non-expiring tokens, 101 root servers and a key reappearing in backups

Intrusion documented on October 14 and 15, 2026; preliminary report dated October 19. Zeabur describes a compromise of its shared cluster, GCP dedicated servers, and platform database. The report carefully distinguishes between what is confirmed by the logs, assessed as probable and still hypothetical. This precision allows a rare technical analysis: the attacker followed two parallel paths, one through the cluster tokens and the other through GCP keys, before bringing them together on the internal network. The company then announced that it would cease its activities on December 31, 2026, a major operational consequence but distinct from the mechanics of the intrusion.

First path: an old key becomes a current authority

The attacker had shared AWS keys and cluster administration tokens. Zeabur explains that these values ​​appeared in plain text in a private configuration repository, that the tokens did not expire and that the administration interface remained accessible from the Internet. The exact origin of their acquisition is not confirmed; the report mentions a possible link with an August incident, explicitly as a hypothesis. The consequence is documented: the cluster could be reached from outside and the associated rights covered nine regions.

The attacker read service parameters and secrets and then executed read commands in database containers. Zeabur counts 865 database services targeted by commands, although it clarifies that not all were successful. Another overprivileged key made it possible, according to Zeabur’s assessment, to access a backup of an old cluster; this backup contained access to the secrets management service. Approximately 53 production secrets were then confirmed read, including internal network identifiers and a database account.

Second path: root passwords in boot parameters

On GCP, an old service account allowed reading initialization parameters containing root passwords in clear text. Zeabur notes root connections on 101 dedicated servers and estimates that the GCP key was used to recover these passwords. The actor also added their own SSH key in the server configuration. Here again, the primary source of the old key is not established. It would be inaccurate to claim that the attacker started with the production secrets service, because GCP connections preceded some observed reads from this service.

When the two paths meet

On October 15, the attacker used an already controlled GCP server and internal network credentials obtained through the first route to add a node to the Zeabur network. This node could reach the platform database; the actor logged in with a read-only account. Zeabur claims to have linked 29 connections and 8,903 operations to this node. Its impact table gives 3,218,965 environment variable records read and data from 321,810 accounts in the platform database. These are records and accounts, not a universal tally of people whose every secret has been abused.

One detail from the report makes the incident response particularly instructive: A key replaced during the incident ended up in an automatic backup, which the attacker could still access with an old access key. Zeabur confirms that the new key was used without authorization after it was rotated and assesses backup access as a likely route. This shows why “rotating a key” is not an isolated event; it is necessary to check copies, backups, caches and access which can reintroduce the new secret into an already compromised environment.

What the investigation teaches

A preventive audit would have looked for tokens without an expiration date, exposed administration interfaces, plaintext secrets in cloud repositories and metadata, and backups that could expose newly rotated secrets. The review must follow the actual privileges of each key: reading backups, adding nodes, reaching the production network and decrypting variables. The report lets us reconstruct these transitions without inventing the initial source of every key.

Zeabur recommends rotating credentials stored on the platform, including those already replaced after the August incident. Its October 28 follow-up announces future closure and steps to help with third-party fees associated with misused keys. An honest reading retains the words of its report: “confirmed,” “assessed,” and “hypothesis” do not describe the same level of evidence.

Main sources: Zeabur preliminary report, Zeabur follow-up.