Zeabur Breach Turns Environment Variables Into A Full Rebuild Problem

Zeabur says an attacker used long-lived internal credentials on October 14 and 15 to enter shared clusters, cloud systems, customer database containers, and its internal network. Confirmed platform-database access covered 3,218,965 environment-variable records and 321,810 accounts. The company also confirmed root sign-ins to 101 GCP Dedicated Servers and attacker-added SSH keys on 50 of them. It treats some additional databases, backups, and provider-management paths as exposed where logging cannot settle what was taken.

This is not a single-password reset. Customers need to revoke and replace every secret stored on the platform, change credentials inside databases, recreate n8n and AI-service credentials, review GitHub App activity, and rebuild root-accessed servers. Zeabur is also winding down: dedicated servers and shared clusters are scheduled to stop by December 31, with November 30 deadlines for account-balance requests and security-incident claims. Recovery and migration therefore need one coordinated inventory rather than separate tickets.

Zeabur's preliminary report describes two routes rather than one exploit chain. In the first, the attacker used internal AWS keys from 01:36 UTC on October 14 and shared-cluster admin tokens four minutes later. Those credentials were stored in plaintext in a private configuration repository. The admin tokens had no expiry, dated to January 2024, and could be used against an internet-reachable administration interface. By 12:39, the attacker was reading settings and secrets for services across nine shared-cluster regions.

The second route involved an old GCP service-account key and plaintext root passwords held in dedicated-server initialization settings. Zeabur confirmed root sign-ins to 101 managed GCP servers beginning October 14. On October 15, the attacker used cloud access to add an SSH key, obtained another production GCP key, and added access again after the first key was disabled. Zeabur also found root-password sign-ins to about 98 of the same servers from September 1 to 5, but it cannot confirm whether the same actor was responsible.

The routes converged after the attacker obtained internal-network administration credentials and added a node from a compromised server. Network rules allowed that node to reach the platform database, where an internal read-only account could read all data. Zeabur traced 29 connections and 8,903 operations between 16:10 and 16:47 on October 15. The account's read-only label limited writes, not blast radius.

The platform-database record is unusually specific. Zeabur confirms that 3,218,965 records containing service environment-variable names and values were read. It also confirms records covering 321,810 accounts, with email addresses, usernames, phone numbers, projects, environments, and services; 566 plaintext zSend API keys; and 11,536 platform access-token hashes. Zeabur revoked the zSend keys and all platform access tokens. It says the hashes cannot be reversed, but the signing key used for login credentials was also read and was likely used to impersonate two accounts before rotation.

Inside shared clusters, the attacker ran read commands in 865 database services. Logs capture commands rather than returned output, and some commands failed, so Zeabur calls the database-content impact assessed rather than universally confirmed. The targets included n8n, PostgreSQL, new-api or one-api, Redis, MongoDB, and MariaDB. For 602 of 607 checked n8n instances using PostgreSQL, the n8n encryption key was present in an environment variable, making encrypted third-party credentials effectively available with the database content.

Other boundaries remain uncertain. The attacker listed database backups in two regions, but download cannot be confirmed. Management tokens for 359 Hetzner and 48 DigitalOcean servers were exposed, but those providers did not offer logs that could establish whether the tokens were used. The Zeabur GitHub App private key was read from 15:05 to 18:54 on October 15; the company found no use but was still seeking fuller GitHub records. Treating unlogged access as exposed is prudent, but it is not the same as claiming confirmed download or misuse.

The incident shows why rotation is a system operation rather than a single console action. At 15:40 on October 15, Zeabur replaced a credential during response. A 16:00 cluster backup captured the new value because the backups stored all secrets. The attacker later used that credential at 20:30. Zeabur had deleted the backup access key at 18:51 and rotated affected credentials again at 21:47, but the sequence proves that a new secret can be compromised immediately when snapshots, build jobs, logs, or configuration copies retain it.

Customers should build a dependency graph before issuing replacements. Start with each exposed environment variable and identify the service that validates it, every workload that consumes it, any database or third-party account it controls, and every backup or artifact that may retain it. Revoke the old credential at its authority first where safe, issue the replacement, update all consumers, redeploy, verify successful use, and search for later use of the retired value. Reversing that order can leave both old and new credentials active.

Changing the Zeabur variable is not enough for a database password because the database still accepts the original password until it is changed inside the database. The same distinction applies to API tokens, OAuth client secrets, signing keys, session keys, and n8n credentials. If a signing or encryption key was exposed, rotate dependent sessions or protected values as the product requires. Otherwise an attacker may continue using artifacts created before the visible secret change.

Zeabur confirmed root access to 101 GCP Dedicated Servers, attacker-added SSH keys on 50, five attacker-created virtual machines, and 16 attached copies of customer server disks. It classifies all 101 hosts as affected systems with possible data exposure and possible unauthorized access mechanisms. Resetting the root password closes one authentication path but does not remove an added user, systemd unit, scheduled task, modified binary, container workload, kernel persistence, or copied credential.

The company's primary recommendation is to back up needed data and rebuild each affected server. That should mean creating a new host from a trusted image, patching it, restoring only validated application data and configuration, issuing new credentials, and moving traffic after comparison tests. Do not clone the entire compromised disk into the replacement and call it clean. Retain an evidence copy where contractual, legal, or investigative needs justify it, but keep that copy isolated from production credentials and networks.

If immediate rebuild is impossible, Zeabur recommends removing the attacker key identified by the comment @zeabur-pentest and every unfamiliar key, reviewing the google-sudoers group, accounts, cron, systemd services, and k3s workloads, changing the root password, and disabling password-based SSH. Those steps reduce risk but do not restore trust in a root-accessed host. They should buy time for migration, not become the final state.

This was Zeabur's second disclosed security incident in less than two months. After the August event, the company said internal administrator keys had been disabled or rotated and advised dedicated-server customers to move environment variables and configuration files off the platform database. The October report corrects that statement: cluster admin tokens and AWS keys stored in the configuration repository were not included, and plaintext GCP root passwords identified on September 3 had not been fixed before the later intrusion.

Zeabur hypothesizes that a GitHub App private key exposed in August may relate to configuration-repository downloads on August 30 and September 2. It does not claim that link as confirmed, and it cannot identify who downloaded the archive. The distinction matters. The defensible finding is that important credentials remained live and plaintext after the earlier rotation, not that the public evidence proves a single continuous actor or one exact leak path.

Some August guidance did reduce October scope. Customers that completed the move of environment variables to their own dedicated servers kept those values out of the platform-database read. That protection does not apply when the destination host itself received root access. A control can work at one layer while another layer fails, which is why recovery needs separate decisions for the management plane, secret store, workload host, database, source repository, and third-party accounts.

Zeabur announced that it will wind down service after the second incident. New dedicated-server and domain purchases stopped immediately. Shared clusters and dedicated servers are scheduled to stop operating by December 31, with some service restrictions beginning December 1. The company published a migration guide and says customers can seek support. A security rebuild on the same platform may therefore be only an interim step needed to export clean data and move safely.

Create one migration inventory that includes services, domains, databases, object storage, queues, cron jobs, environment variables, certificates, DNS, backups, retention obligations, and external integrations. Build the replacement in a separate account or provider boundary, issue fresh secrets there, validate data and traffic, then revoke Zeabur-era credentials after cutover. Preserve the minimum evidence needed for investigation or claims without importing compromised executables, unknown SSH material, or full system images into the new environment.

The October 22 notice sets November 30 as the deadline for account-balance refund requests submitted through support and for security-incident claims. Claims need affected accounts and services, the types of leaked credentials, and third-party invoices or usage records. Operational teams should save relevant bills, audit exports, support correspondence, timelines, and replacement costs now. Zeabur says its investigation is still ongoing, so keep the incident report and status page under change control and revise the local scope if the company publishes new evidence.