Zeabur to shut down after a non-expiring admin token opened its shared cluster

Developer hosting platform Zeabur published a preliminary incident report on October 19 saying an attacker used its own internal credentials to take over its shared cluster on October 14 and 15. The keys were a shared-cluster admin token created on January 10, 2024 with no expiry, plus internal AWS keys, both stored in plaintext in a private configuration repository and usable from the public internet. Zeabur suspects they were obtained in its August breach, when a GitHub App private key was read and replaced but the plaintext credentials were not rotated. The attacker read 3,218,965 environment-variable records covering 321,810 accounts, the platform database, and settings for 865 hosted database services, added SSH keys to 50 dedicated servers, and called the API as two impersonated accounts. Zeabur rotated its login signing key on October 15 and, per BleepingComputer, will shut down by December 31, 2026.

Why it matters

Every failure here is a non-human identity control: a token with no expiry, a credential stored in plaintext, an admin path reachable from anywhere, and an incident response that rotated the key that was known stolen but not the secrets that key could reach. A platform that holds customers' environment variables is a secrets manager whether it calls itself one or not.

If you deployed on Zeabur, treat every variable as leaked: revoke API keys, cloud keys, database passwords and signing keys at the provider first, then redeploy. Rebuild GCP dedicated servers, and check the GitHub audit log for Zeabur GitHub App actions between 15:05 and 18:54 UTC on October 15. For your own platforms, give admin tokens an expiry, keep them out of repositories, and make secrets rotation after any breach cover everything the stolen key could read.

Source: Zeabur