October 2026 Security Incident

An attacker compromised the shared cluster and GCP Dedicated Servers and read the environment variables stored in the Zeabur platform database. This post explains what happened, what data was affected, what we have done, and what you need to do.

This article is also available in 繁體中文 , 简体中文 , 日本語 , Español , and Bahasa Indonesia .

All times in this article are in Coordinated Universal Time (UTC). The investigation is ongoing, and we will update this article as it progresses.

What happened: On October 14–15, 2026, an attacker used leaked Zeabur internal credentials to break into the shared cluster, some Dedicated Servers, and Zeabur internal systems, and eventually read the platform database.

Entry points closed: The cluster admin tokens, AWS and GCP keys, and internal network node the attacker used have all been revoked or removed, and public SSH access to the admin interfaces and servers has been blocked. All users have been signed out, and all platform Access Tokens have been revoked. The attacker's last recorded activity was on October 15, 21:05.

Who is affected: Mainly services on the shared cluster and GCP Dedicated Servers . Environment variables stored in the Zeabur platform database were also read. Projects that followed our guidance after August and moved their environment variables to their own Dedicated Server are outside the scope of the platform database read.

What you need to do: Leaked data can still be misused. Replace every password and key stored on Zeabur, even if you already replaced them after the August incident. See What you need to do for the steps.

Root cause: The root cause of this incident lies with Zeabur: long-lived admin credentials were stored in plaintext and could be used from the public internet. See Why it happened .

Relation to the August incident: The rotation in August did not cover the credentials used this time. Projects that moved their environment variables as advised in August avoided the platform database leak. See Relation to the August incident .

Terms used in this article: "Confirmed" means a log directly records it. "Assessed" means the timing and content match, but there is no direct record. "Cannot be confirmed" means there are no records to check, and we treat it as leaked. "Hypothesis" means a possible explanation supported only by indirect evidence; these are collected in Unconfirmed hypotheses .

The attacker took two paths that eventually met inside Zeabur's internal network.

Path A: shared cluster and AWS

From October 14, 01:36, the attacker used Zeabur internal AWS keys, and from 01:40, the shared cluster's admin tokens. These credentials were stored in plaintext in a private Zeabur configuration repository. How the attacker obtained them currently cannot be confirmed ; we hypothesize it is related to the GitHub App private key leaked in the August incident. See Unconfirmed hypotheses .

The shared cluster's admin interface was open to the public internet at the time, and the admin tokens had no expiry. This let the attacker access the shared cluster in 9 regions from outside.

From 01:51, the attacker read some system secrets. From 12:39, this widened to the settings and secrets of all services, including environment variables. In regions with complete read logs, we confirmed the content was read. Other regions lack logs, and we treat them as leaked.

From 13:40, the attacker ran read commands inside user database containers. They started with a few new-api/one-api instances, read n8n at scale from 15:41, and read some PostgreSQL databases table by table from 16:50. The last command was at 17:04. In total, the attacker ran commands in 865 database services, though not every command succeeded.

Using another over-privileged key in the cluster, the attacker read a backup of an old cluster ( Assessed ). The backup contained a key that could read Zeabur's secrets management service.

From October 15, 14:52 to 16:51, the attacker read 53 production secrets ( Confirmed ). These included the internal network's admin credentials, a platform database account, and the GitHub App private key.

Path B: GCP Dedicated Servers

From October 14, 13:40, the attacker signed in as root to 101 Dedicated Servers that Zeabur manages on GCP.

These servers' initialization settings stored the root password in plaintext. The attacker held an old GCP key that could read these settings. We assess that the attacker used this key to obtain the passwords.

From October 15, 14:26, the attacker used the old GCP key to modify server settings and add their own SSH key. At 15:05, the attacker also obtained a production GCP key from the secrets management service. After we disabled the old key at 17:17, the attacker used this new key at 17:28 to add the SSH key again, and we disabled it as well at 17:31. The first sign-in to the GCP servers on October 14 came before the first known read of production secrets on October 15, so the latter cannot be described as the starting point of the former.

Earlier still, from September 1 to 5, an unknown source signed in to the same servers with the root password, reaching 98 servers on September 5 alone. Whether this was the same attacker currently cannot be confirmed .

Where the two paths met

On October 15, 15:30, on a compromised GCP server, the attacker used the internal network admin credentials from Path A to add a node to Zeabur's internal network.

The internal network rules allowed this kind of node to connect to the platform database. From 16:10 to 16:47, the attacker read the platform database using an internal read-only account ( Confirmed ). We compared connection records from both ends of the internal network with the database logs. All 29 database connections in this period map to this node, and every sign-in and query in those connections can be traced, for a total of 8,903 operation records.

At 17:58, we removed this node.

Some credentials rotated during the incident were later used without authorization. Zeabur's daily cluster backups store all secrets, and on October 15, 15:04, the attacker read the access key for these backups. The new key we put in place at 15:40 was captured by the 16:00 backup, and the attacker used it at 20:30. We deleted the backup access key at 18:51 and rotated the affected credentials again at 21:47. That the new key was captured by the backup and later used is confirmed; whether the attacker downloaded that backup is assessed. The attacker may have obtained the backup before 18:51, so the use at 20:30 does not mean downloads were still possible after 18:51.

What data was involved

Platform database. From October 15, 16:10 to 16:47, the attacker read the data in the table above. Account data includes the information on your profile page, such as email, username, and phone number. The attacker also searched environment variables and config files for API keys and private keys. Based on the commands and their later behavior, the attacker was mainly looking for API keys they could use directly, especially keys for AI services: they searched the platform database for keys, read credentials in n8n and new-api/one-api at scale, and tried to call Amazon Bedrock with Zeabur's AWS keys. This is only an observation of the attacker's intent. The attacker also read account data, and we still treat everything that was read as leaked. For the two-factor authentication and passkey tables, only statistics were queried; there is no record of their contents being read. We have revoked all users' platform Access Tokens, and none of the old tokens can be used anymore.