Zeabur is shutting down after its second breach in two months

On October 14 and 15, 2026, an attacker used Zeabur’s own internal credentials to get into its shared cluster, some dedicated servers, and then the platform database. On October 17 the company said it is shutting down. Shared-cluster services pause on December 1. Dedicated servers and shared clusters stop by December 31.

If you never put a project on Zeabur, nothing of yours is in this leak. The useful part is why a second incident, two months after the first, reached customer secrets the August cleanup was supposed to have closed.

What Zeabur says happened

Zeabur’s preliminary report, published October 19, separates what a log records (“confirmed”) from what the timing suggests (“assessed”) and from what it cannot check. The short version of the confirmed path:

The shared-cluster admin tokens had no expiry. They were created on January 10, 2024, written in plaintext into a private configuration repository on January 20, 2026, and left out of the rotation after the August incident. The admin interface was reachable from the public internet. From 01:40 UTC on October 14, those tokens opened the shared cluster in nine regions.

From 12:39 that day the attacker read settings and secrets of services on the cluster, including environment variables. Zeabur says regions with complete logs confirm the read, and regions without logs are treated as leaked. From 13:40 the attacker ran read commands inside user database containers. Zeabur counts commands in 865 database services. Not every command succeeded, and the audit logs kept the commands, not their output, so Zeabur does not claim a full copy of every database.

A second path signed in as root to 101 dedicated servers Zeabur manages on Google Cloud, starting at 13:40 UTC on October 14. Zeabur assesses that an old Google Cloud key was used to read root passwords stored in plaintext in those servers’ initialization settings. On 50 of the 101 servers the attacker added their own SSH key. Zeabur says it has emailed those users and reset the root passwords.

On October 15 the two paths met. Using internal-network credentials taken from the first path, the attacker added a node from a compromised Google Cloud server. From 16:10 to 16:47 UTC that node read the platform database with an internal read-only account. Zeabur says all 29 database connections in that window map to this node, and that the read is confirmed.

What was read

From the platform database, Zeabur confirms:

• 3,218,965 environment-variable records, names and values
• account, project, and service data for 321,810 accounts, including email, username, and phone number where those were on the profile
• 566 zSend API keys, stored in plaintext, since revoked
• 11,536 platform access tokens, stored only as hashes, all revoked

Zeabur says the attacker searched what they had taken for API keys, especially keys for AI services, and tried to call Amazon Bedrock with Zeabur’s own AWS keys. Those Bedrock calls failed. Zeabur still treats everything that was read as leaked, not only the keys the attacker seemed to want.

Of the n8n instances using PostgreSQL, Zeabur says 602 of the 607 it checked kept the n8n encryption key in an environment variable, so third-party credentials inside n8n were effectively in plaintext. Rotating a database password after August did not close a read that happened from inside the container.

Projects that followed the August advice and moved environment variables onto their own dedicated server were outside this platform-database read. That does not cover a dedicated server the attacker signed into.

Zeabur also says it cannot confirm whether management tokens for 359 Hetzner servers and 48 DigitalOcean servers were used. It revoked those tokens on October 16 at 01:09 UTC. Neither provider keeps the operation logs that would settle it.

The company’s own earlier sentence, that “all internal admin keys have been disabled or rotated” after August, was incomplete. The October report says so. The tokens and AWS keys in the configuration repository, and the root passwords in Google Cloud initialization settings, were the credentials used this time. How the attacker first obtained them is still marked unconfirmed. Zeabur’s hypothesis, that this connects to a GitHub App private key read in August, is labeled a hypothesis.

More than 16 hours of activity on October 14 raised no alert. Zeabur says it started the investigation on October 15 at 13:56 UTC after a user report. The last attacker activity it had observed when the report was published was October 15 at 21:05 UTC.

The shutdown

The shutdown note on October 17 is the founder, Yuanlin Lin. New dedicated servers and domains are no longer for sale. From December 1, dedicated-server renewals stop and each server shuts down on its own expiration date, which may be before December 31. Shared-cluster services are paused that day; Zeabur says you can still restart one by hand to take a backup. On December 31, dedicated servers and shared clusters stop.

The date when Zeabur deletes remaining data, the last day to export, and the day support closes are not set. The note says not to wait for them. Domain transfers are self-serve from the dashboard. Refunds of account balance and compensation for losses from the incident are separate requests, both through Zeabur Support.

If you hosted something there

1. Replace secrets that lived in Zeabur environment variables, even if you replaced them in August. Revoke the old key at the provider, then create a new one. Zeabur’s list includes API keys, cloud keys, database passwords, and signing and encryption keys. A project that moved those variables onto its own server after August was outside the platform-database read. If that server is one of the 101 Google Cloud machines, treat the copy on the server as exposed too.
2. Change passwords inside the database, not only the variable that points at it. Zeabur says changing the variable does not change the password in the database, and does not un-leak rows already read. If the database holds your users’ password hashes or session tokens, revoke those too.
3. On n8n, replace the encryption key and recreate third-party credentials. On new-api or one-api, revoke the upstream AI keys and regenerate access tokens.
4. If you had a Google Cloud dedicated server, rebuild it. Zeabur’s own minimum, if you cannot rebuild yet, is to remove unfamiliar keys in /root/.ssh/authorized_keys (including any with the comment @zeabur-pentest), check sudoers, crontab, systemd, and k3s, and turn off SSH password login. Check sign-in records back to September 1, not only October 14. Zeabur says an unknown source signed in to about 98 of these servers with the root password between September 1 and 5, and it cannot confirm that was the same attacker.
5. Take the backup before December 1, and before your server’s own expiration date if that is sooner. December 31 is the last day, not a promise that your service runs until then.

A password you only used on an unrelated site is not in this pile. A key that was in a Zeabur environment variable, an n8n credential, or on one of those 101 servers should be treated as someone else’s now.

Sources

• Zeabur, October 2026 security incident (preliminary report), October 19, 2026
• Zeabur, Zeabur is shutting down: what happens next, October 17, 2026