Zeabur Shutting Down After Second Data Breach: 321,810 Accounts Exposed

Zeabur is shutting down. Founder Yuanlin Lin announced the shutdown on October 17, 2026, two days after the company began investigating its second security breach in less than two months. Shared-cluster services pause on December 1, dedicated server renewals stop the same day, servers shut down on their own expiration dates through December, and everything stops on December 31.

The shutdown is not only a security story. Lin wrote that growth had “started to run into limits” and that a system built quickly three and a half years ago had become complex and hard to maintain. The two incidents, he wrote, “made the shortcomings in our security and operations even clearer.” But for users, the security part is the urgent part: this breach exposed environment variables, account data, and server access at a scale that makes rotation and migration non-optional.

The token that outlived a whole incident response

The most damning detail in Zeabur’s own preliminary report is a date: January 10, 2024. That is when the shared cluster admin token was created, with no expiry. It was written in plaintext into a private configuration repository on January 20, 2026, and it was still valid when the attacker used it on October 14, 2026. That is roughly 33 months without rotation, while the admin interface it unlocked sat reachable from the public internet.

What makes it worse is that Zeabur already had a chance to kill it. After the first breach in late August, the team rotated credentials, but the rotation skipped the plaintext credentials in the configuration repository and the GCP root passwords stored in server initialization settings. Zeabur now admits its August statement that “all internal admin keys have been disabled or rotated” was incomplete. The attacker in October used exactly the credentials the August response left behind. Only 48 days separated the August detection from the start of the second attack.

There is a parallel lesson here for any site owner, not just Zeabur users. A rotation that misses one store of secrets is not a rotation. Zeabur’s August fix covered the obvious keys and left the config repo untouched, and the company paid for that gap with its existence. If you run WordPress, the same class of mistake shows up as keys left in wp-config backups or staging copies. Our write-up on the UpdraftCentral key compromise shows how stolen platform keys turn into backdoors on sites whose owners never knew they were connected.

What the attacker took

Zeabur’s preliminary report, published October 19, is unusually specific about scope. These figures are confirmed by Zeabur itself, not estimates:

• 3,218,965 environment variable records (names and values) read from the platform database.
• 321,810 accounts exposed, including email, username, phone number, plus project, environment, and service data.
• 566 zSend API keys in plaintext, all revoked. 11,536 platform Access Tokens revoked, and all users signed out.
• 101 GCP dedicated servers (92 users) signed into with root privileges. The attacker added its own SSH keys to 50 of them, created 5 virtual machines in Zeabur’s GCP project, and attached 16 copies of customer server disks to them. All 101 are classified as affected hosts.
• 865 database services had read commands run inside their containers, including 736 n8n instances. Of the n8n instances checked, 602 of 607 had their encryption key set in an environment variable, so third-party credentials stored in n8n were effectively leaked in plaintext.
• Environment variables and secrets of all services across the shared cluster’s 9 regions, partly confirmed by logs and otherwise treated as leaked.
• A backdoor program planted in at least 2 PostgreSQL databases in the Tokyo region, connecting back to an external host from October 14. One was still connecting on October 15.
• The login credential signing key was read, and Zeabur assesses it was used to forge login credentials. For about an hour on October 15, the attacker called the Zeabur API as two accounts, one belonging to a Zeabur employee, reading account and project lists. No resources were modified in those calls.

Two things in the report deserve emphasis. First, more than 16 hours of attack activity on October 14 triggered no alerts, Zeabur says. Zeabur found the incident on October 15 only after a user report, and the investigation started at 13:56 UTC, roughly 36 hours after the first known credential use. Second, projects that followed Zeabur’s August guidance and moved their environment variables to their own dedicated servers were outside the platform database read this time. The migration advice worked for those who took it. It just came too late for everyone else.

What to do before your server’s expiry date

December 31 is the final date, but it is not the date your service stops. Dedicated servers shut down on their own expiration dates between December 1 and 31, so check yours first and plan around it. Zeabur’s own advice is blunt: replace every password and key stored on Zeabur, even if you already replaced them after August.

1. Rotate every secret stored on Zeabur, including API keys, database passwords, and third-party credentials used by n8n workflows.
2. Check billing on every cloud and AI account back to September 1, and dispute any charge you do not recognize.
3. Rebuild any of the 101 affected GCP servers from scratch, since the attacker held root and added SSH keys.
4. Back up your data now. Shared-cluster services restart manually after the December 1 pause, but do not rely on it.
5. Transfer any domains bought through Zeabur to another registrar using the self-service transfer in the dashboard.
6. File separate Zeabur Support requests for refunds and for incident compensation, and say clearly which one you want.

If you are not sure whether your data was involved, treat it as involved. Zeabur’s position is the same: where unauthorized access cannot be ruled out, it assumes exposure. That is also the right default for any breach where the exposed data includes credentials. Our general guide to what to do when personal information leaks covers the identity-protection steps that apply alongside the technical rotation above.

The timeline, reconstructed (our analysis)

Piecing together Zeabur’s shutdown announcement, its preliminary incident report, its status page, and BleepingComputer’s October 20 report gives a timeline that is hard to read any other way than as a slow-motion failure:

• January 10, 2024: shared cluster admin token created, no expiry.
• January 20, 2026: that token written in plaintext to the configuration repository.
• August 27, 2026: first breach detected. Rotation afterwards skips the config-repo credentials and GCP root passwords.
• September 1-5, 2026: an unknown source signs into about 98 GCP servers with the root password. Attribution to this attacker cannot be confirmed.
• October 14, 2026, 01:36 UTC: second attack begins. More than 16 hours of October 14 attack activity triggers no alert.
• October 15, 2026, 13:56 UTC: investigation starts, only after a user report.
• October 15, 2026, 16:12-17:19 UTC: attacker calls the Zeabur API as two accounts, one a Zeabur employee’s, reading account and project lists.
• October 15, 2026, 21:05 UTC: last recorded attacker activity.
• October 16, 2026, 01:09 UTC: Hetzner and DigitalOcean management tokens revoked.
• October 17, 2026: founder announces the full shutdown.
• October 19, 2026: preliminary incident report published.
• December 1, 2026: renewals disabled, shared clusters paused. December 31, 2026: everything stops.

What Zeabur has not confirmed yet

Several questions remain open, and they matter for how far you take your response. How the attacker first obtained the October credentials cannot be confirmed; Zeabur’s hypothesis is that it traces back to the GitHub App private key leaked in August, but that is labeled a hypothesis in its own report. Whether the Hetzner (359 servers) and DigitalOcean (48 servers) management tokens were actually used cannot be confirmed, though both were revoked on October 16. Whether user database backups in Taipei and Hong Kong were downloaded cannot be confirmed either, and neither can the September root-password sign-ins being the same attacker.

One more open item is on Zeabur’s side, not the attacker’s: the data deletion date, the final data export deadline, and the date Zeabur Support closes have not been announced. Do not wait for those dates. Zeabur itself says to back up and migrate on the shutdown timeline rather than waiting for a deletion deadline, and that advice is right. A platform that is shutting down is not a safe place to leave the only copy of anything.

Zeabur’s story ends as a cautionary tale with an unusually honest autopsy. The company published the token dates, the missed rotation, the alert gap, and its own corrected August statement in public. That transparency is rare, and it is the reason this article can be specific instead of speculative. But transparency after the fact does not undo the exposure. If you used Zeabur, the work now is rotation, rebuilds, and migration, and the clock on it is measured in weeks, not months.

Sources: Zeabur shutdown announcement, October 17, 2026; Zeabur October 2026 security incident preliminary report, October 19, 2026; Zeabur status page; BleepingComputer, October 20, 2026.