Zeabur shuts down after second breach hits 321,810 accounts

Developer-platform startup Zeabur will shut down after a second security breach in roughly two months. The October intrusion exposed 321,810 accounts and more than 3.2 million environment-variable records across shared clusters in nine regions. The cause, per Zeabur's own account, was leaked internal credentials stored in plaintext. If you ran anything on Zeabur, rotate every secret it held and plan your exit now — services begin pausing December 1.

Zeabur is a GitHub-connected PaaS that handled deployments, databases, HTTPS and infrastructure for its users. The disclosure was first reported by BleepingComputer and, in Taiwanese press, by BNext. Zeabur's earlier incident is documented in its own August security write-up.

What happened

Per Zeabur's disclosure as reported, the second compromise ran October 14–15. An attacker used leaked internal Zeabur credentials to reach the shared cluster, some dedicated servers and internal systems, then read the platform database. Beyond the database theft, the reporting describes:

• Root sign-ins on 101 GCP servers by 92 distinct users.
• SSH keys added to 50 servers.
• 16 customer disk copies attached to attacker-controlled VMs.

The exposed data is account information, environment variables and secrets — the credentials customers stored for their own third-party services.

Why it worked

Zeabur named the failures itself. Administrator portals were reachable from the public internet, and the admin tokens used to move through infrastructure had no expiry and were never rotated after the first breach. In Zeabur's words: "The admin tokens had no expiry, had not been rotated since they were created in January 2024."

The first breach, in late August, began when attackers exploited a flaw in a customer's NextChat application, pivoted through poorly isolated internal systems, stole AWS credentials and reached the production database. Zeabur believes — but has not confirmed — that the credentials used in October were obtained during that August intrusion.

Shutdown timeline

• December 1: renewals disabled; running services on shared clusters paused.
• December 31: all dedicated servers expire and shut down; all shared clusters stop.

Zeabur has said users may get additional time to migrate data but has published no firm timeline.

Action checklist

1. Rotate every secret you ever stored in Zeabur — API keys, database passwords, tokens, service credentials. Assume all environment variables held in the platform are compromised.
2. Audit the rotated credentials for abuse: check third-party provider logs (cloud, AI, payment, source-control tokens) for unauthorized use since mid-October.
3. Migrate off before December 1, when shared-cluster services start pausing. Stand up replacement hosting and move data now rather than during the wind-down crunch.
4. For any host you ran on Zeabur, review for attacker SSH keys and unexpected disk-copy or VM activity matching the dates above.

Context

A platform that stores customers' environment variables is a concentrated secret store, and its blast radius is every downstream service those secrets unlock. Two compounding failures made this one worse: secrets kept in plaintext and admin tokens that never expired or rotated — the same non-expiry gap that let an August foothold become an October mass-exposure. For anyone running a multi-tenant platform, the lesson is unglamorous and specific: expire and rotate privileged tokens, keep admin planes off the public internet, and never store secrets in the clear.