Zeabur breach: attacker read 3.2 million stored secrets and data on 321,810 accounts
Zeabur said in a preliminary report published October 20, 2026 that an attacker using leaked internal credentials read its platform database on October 14-15, 2026, including 3,218,965 service environment-variable records and account data for 321,810 accounts, after signing in as root to 101 customer servers.
What happened
Zeabur, a developer deployment platform that hosts and deploys applications from users’ code repositories, said in a preliminary report published on October 20, 2026 that on October 14–15, 2026 an attacker used leaked Zeabur internal credentials to break into its shared cluster, some Dedicated Servers and its internal systems, and eventually read the platform database. Zeabur first disclosed unauthorised access on its status page on October 15, 2026. The credentials included shared-cluster admin tokens that had no expiry, had not been rotated since they were created in January 2024, and were stored in plaintext in a private configuration repository, while the cluster admin interface was reachable from the public internet. The attacker also signed in as root to 101 Dedicated Servers Zeabur manages for customers on Google Cloud, added their own SSH keys to 50 of them, and attached copies of 16 customer server disks to virtual machines under their control. Zeabur said it has revoked the credentials used, signed out every user, revoked all platform Access Tokens and all 566 zSend API keys, and rotated its login signing key. This was Zeabur’s second security incident in under two months, after an August 2026 breach, and the company has announced it will shut down on December 31, 2026 — renewals are disabled and shared-cluster services pause from December 1.
Who is affected
Zeabur users — 321,810 accounts in total, the company confirmed. From the platform database the attacker read 3,218,965 service environment-variable records (names and values) and account data including email addresses, usernames and phone numbers, along with project, environment and service data. On the shared cluster, which spans nine regions, the attacker read the settings and secrets of all services and ran read commands inside 865 user database services — including 736 n8n automation instances, whose stored third-party credentials were effectively in plaintext wherever the instance’s encryption key was itself stored in an environment variable, as Zeabur found was the case for 602 of the 607 instances it checked. The 101 Google Cloud Dedicated Servers signed into as root, used by 92 customers, are all treated by Zeabur as compromised hosts. Projects that followed Zeabur’s guidance after the August incident and moved their environment variables onto their own Dedicated Server were outside the platform-database read, although a compromised host could still expose them. Zeabur said the contents of its two-factor authentication and passkey tables were not read — only statistics were queried — and that the 11,536 platform Access Tokens in the database were stored only as hashes and have all been revoked.
How serious
The concrete risk is cascading account takeover, because environment variables are where developers store live secrets: API keys, cloud access keys, database passwords and signing keys. Zeabur said the attacker searched the data specifically for API keys that could be used directly, especially keys for AI services, and that a user’s OpenAI key was used to run about 1,107 image-generation requests on October 16 — which Zeabur hypothesises came from this leak. The company is offering compensation through support tickets for third-party charges caused by the incident, which underlines that a stolen key can be spent, not just read. Root access with added SSH keys on 101 customer servers gives the attacker a way back in that can survive a password change, and the account email addresses and phone numbers support targeted phishing that impersonates Zeabur during the shutdown and migration rush. The Zeabur GitHub App’s private key was also read on October 15, which in principle allowed access to repositories users had authorised Zeabur to reach during a window of under four hours that day; Zeabur said it rotated the key and has found no use of it.
What to do now
Follow Zeabur’s own guidance, and do not wait for a notification email. Replace every password and key stored in your Zeabur environment variables — revoke each old credential with its service provider first, then create a new one and redeploy — even if you already replaced them after the August incident. Sign in to Zeabur again (every user was signed out), recreate your platform Access Tokens, and if you use zSend, recreate your API keys, because all previous keys were revoked. If you connected GitHub, check your GitHub audit log for Zeabur GitHub App activity on October 15 between 15:05 and 18:54 UTC. Check usage and bills for every connected service from October 14 onward — from September 1 if you run a Google Cloud Dedicated Server. Shared-cluster users must also change the passwords inside their databases, and n8n users should replace the n8n encryption key and recreate every stored credential. Anyone with a Google Cloud Dedicated Server should treat the server as compromised: back up the data and rebuild it, and in the meantime remove any SSH key commented @zeabur-pentest or any key you do not recognise, and change the root password. Users in the Taipei and Hong Kong regions should treat database-backup data as leaked. Finally, plan the move off Zeabur now: shared-cluster services pause on December 1 and the platform shuts down on December 31, 2026.
Sources: Zeabur preliminary report · Zeabur status page · BleepingComputer