Zeabur Shuts Down After October Breach: Rotate Secrets and Migrate Before December 31

What happened in October​

Zeabur's preliminary report says on October 14–15, 2026, an attacker used leaked internal credentials to break into the shared cluster, some Dedicated Servers, and internal systems, and eventually read the platform database. BleepingComputer's account puts the scale at 321,810 accounts and about 3.2 million environment-variable records. Zeabur's own table lists 3,218,965 records of service environment variables, names and values, as confirmed.

Zeabur's figures, as reported, include:

• Shared clusters across nine regions were affected.
• Root sign-ins were confirmed on 101 GCP dedicated servers, used by 92 users.
• The attacker added SSH keys to 50 of those servers.
• Sixteen customer disk copies were attached to the attacker's own virtual machines.

These counts are the company's own. Nobody has independently audited them. Zeabur also says some activity can't be confirmed because logs are incomplete. It says it cannot confirm whether database backups from the Taipei and Hong Kong regions were downloaded. It treats anything it can't rule out as leaked.

The credential failures​

Zeabur's report points to a cluster of weak practices:

• Admin tokens had no expiry. They dated from January 2024 and were left out of the post-August rotation.
• Credentials sat in plaintext in a private configuration repository.
• Root passwords for the GCP servers were stored in server initialization settings. Zeabur says it spotted that problem on September 3 but hadn't fixed it before the attack.
• The shared-cluster admin interface was reachable from the public internet.
• Cluster backups held secrets, and the backup access key was stored alongside other secrets.

Zeabur says the attacker's route to those credentials is unconfirmed. Its leading theory is that a GitHub App private key stolen in August let someone read the configuration repository. The company labels this as unproven. It says it has no direct evidence and is waiting on GitHub's audit logs. BleepingComputer, summarising Zeabur's disclosure, says the attackers likely obtained the credentials in August. Treat that as a hypothesis.

How August set up October​

The first incident began on August 27. In Zeabur's September 7 report, the attacker first got in through a vulnerability in a service a user had deployed on a shared cluster. The service was NextChat v2.16.1, tied to CVE-2026-7644. The attacker then moved through four boundaries: the application, the shared cluster's internal network, the platform and cloud accounts, and the production database. Along the way they pulled an administrator's legacy API key from a routing cache and found an AWS root key in an internal service's variables.

Zeabur's own October report admits that its August claim of having rotated or disabled every internal admin key was incomplete. The rotation didn't touch the plaintext cluster tokens and AWS keys the attacker later used.

For anyone who runs infrastructure, that is the lesson. A "we rotated everything" announcement is only as good as the inventory behind it. If you can't enumerate every place a credential lives, you can't promise it's gone.

The shutdown schedule​

Founder Yuanlin Lin announced the wind-down on October 17. The confirmed dates are:

• Immediately: purchases of new dedicated servers and domains have stopped. Refunds, incident compensation and migration help go through Zeabur Support.
• December 1: dedicated server renewals are disabled and each server shuts down on its own expiration date. All running services on shared clusters are paused, but you can restart them manually to back up your data.
• December 31: all dedicated servers and shared clusters stop operating.

December 31 is the final shutdown date, not a guarantee that everything runs until then. Zeabur says the data deletion date, the final export deadline and the support closing date are still to be announced. Don't wait for them before backing up.

The security incidents weren't the only reason Zeabur gave. It also cited growth limits, as AI makes deployment easier, and an architecture that became increasingly complex and difficult to maintain. It said the two incidents made the shortcomings in our security and operations even clearer.

What Zeabur customers should do now​

This is guidance drawn from Zeabur's own advice, not independent testing.

1. Rotate every credential stored in Zeabur environment variables. That covers API keys, cloud keys, database passwords, signing keys and encryption keys. Revoke the old ones at the provider first, then issue new ones and redeploy. Do this even if you already rotated after August.
2. Re-authenticate and recreate your Zeabur Access Tokens. Zeabur says it invalidated the old ones and signed all users out.
3. Check your GitHub audit logs. Zeabur says the attacker read its GitHub App private key on October 15 and that it rotated the key at 18:54 that day. It found no sign of use, but advises checking for unexpected clones, pushes, deploy keys and webhook changes during that window.
4. Treat GCP dedicated servers as compromised. Back up your data and rebuild. If you can't rebuild at once, remove unfamiliar keys from /root/.ssh/authorized_keys, including any commented @zeabur-pentest. Also check sudoers, crontabs, systemd services and workloads, change the root password, and disable SSH password login.
5. Change passwords inside shared-cluster databases. Editing the variable in Zeabur doesn't change the password in the database. Invalidate any stored user password hashes, sessions or tokens too. For n8n, change the encryption key and recreate third-party credentials. For new-api/one-api, revoke the upstream AI keys.
6. Review billing. Look at usage from October 14 onward at every provider whose key lived in Zeabur. GCP dedicated-server users should look back to September 1 for suspicious logins.

One nuance matters. Variables you migrated to your own dedicated server after August were not in the platform-database exposure. A compromised host could still leak them. Moving secrets off a central database doesn't invalidate old credentials, and Zeabur says as much.

Planning the move​

Start with an inventory of services, domains, databases, volumes and variables. Note each dedicated server's expiration date, because that is when it stops. Domain transfers are self-service from the dashboard. Zeabur says it is preparing migration guides, including Markdown guides and Skills for coding agents. You will still need to confirm that backups are complete and that the services work in the new environment. If you contact support, tell them whether your service is down, whether you can reach your data, and when your server expires. Expect slow replies.

Bigger lessons for developers​

Zeabur's own wording about its failure is blunt: it was responsible for limiting what an attacker could reach once a workload was compromised. Three points stand out.

• Retirement is not remediation. Both incidents reportedly traced back to a shared cluster that was being retired but was still running. A system you plan to retire still needs full isolation and monitoring until it is gone.
• Detection lagged badly. Zeabur says the October activity ran for hours without alerts. By its own timeline, about 36 hours passed between the first known credential use and the start of the investigation. Zeabur says it has since added alerts for admin-privilege use, in-container command execution, bulk secret reads and unfamiliar cloud-key sources.
• Hosted platforms concentrate risk. Your secrets are only as safe as the platform's weakest internal token. Scoped, expiring tokens and secrets that stay on infrastructure you control reduce the damage when a vendor fails.

If you were a customer, rotate first and migrate second. A leaked key doesn't care that the platform is closing.