Zeabur built its business on taking the messy parts of deployment off a developer’s hands, which meant holding the keys to thousands of other people’s systems. Those keys now belong to someone else. The Zeabur data breach exposed 3.2 million environment variable records and account data for 321,810 users, nine weeks after the first attack. Days later, the firm decided to shut down for good.
How the October attack unfolded
The Zeabur data breach began on October 14, when an attacker used leaked internal logins that sat in plain text. Those logins opened the shared cluster, several dedicated servers, and the internal admin tools. From there the intruder reached the platform database, and nine regions of shared hosting fell inside the blast radius.
Environment variables sound dull, yet they hold the crown jewels of any modern app. Teams store API keys, database passwords, and cloud tokens in them, along with anything else an app needs at startup. Apps read those values live, so each stolen record works as a key that still turns. Handing 3.2 million of them to an attacker opens doors far beyond Zeabur itself.
Damage from the Zeabur data breach went well past the stolen database, because the hacker also took hold of the systems underneath. Root logins showed up on 101 Google Cloud servers, and SSH keys landed on 50 of those machines. A password reset alone would not lock that attacker out. Sixteen customer disk copies also ended up attached to virtual machines under the intruder’s own control.
A second attack that traces back to the first
Hackers had already hit the platform once in late August 2026, exploiting a flaw in a customer’s NextChat app. From there they moved sideways through internal systems that had almost no isolation between them. That first raid produced stolen AWS keys and access to the live database, leaking account details and API keys.
Zeabur has not confirmed the link, though it believes the October hacker used logins picked up during that August raid. The timing fits well enough. That August break-in set the stage for the Zeabur data breach that followed, and the second round proved far wider.
The security failures behind the Zeabur data breach
Plaintext storage of internal keys sat at the heart of this failure, since readable logins give a hacker nothing to crack. Zeabur also skipped several admin accounts during the post-August rotation. Its admin portals meanwhile stayed open to the public internet, which gave anyone with a working key a way in.
One detail stands out above all the others in this case. Zeabur created its admin tokens in January 2024 and never rotated them, and those tokens carried no expiry date. They worked for nearly two years without anyone touching them, and the post-August cleanup skipped them too.
A portion of customer data did survive the October attack untouched. Customers who had moved their environment variables onto their own servers in August stayed clear of the platform database, so those values escaped the worst. A hacked server could still leak them, however.
A shutdown follows the Zeabur data breach
The company will start shutting down services on December 1, 2026, and finish by the end of that month. Renewals stop on day one, and every service on the shared clusters pauses. Dedicated servers expire and power down by December 31. Users may get extra time to migrate, although no firm dates exist yet.
Zeabur points to three and a half years of steady growth and a record year in 2026. But scaling to meet that demand made the platform complex and hard to maintain, and the security failures reflect exactly that strain. The team argued over the company’s future after August, and the second Zeabur data breach settled the question within days. Winding down was the answer they landed on.
What developers should do now
Anyone caught in the Zeabur data breach should treat every secret stored on the platform as public. Rotate API keys, database passwords, and cloud tokens first, then revoke active sessions across every connected service. Rebuild any Google Cloud server showing signs of tampering, because an SSH key planted by a hacker survives a normal password change. The clock runs out in December, and support will thin as the team winds down.
Export your data, docs, and config files while the platform still works properly. The Zeabur data breach is also a good prompt to audit the secrets you have handed to other vendors. Most teams carry more of them than they remember.
Keep admin panels off the open internet
Open management panels deserve a hard look across your own systems, because hackers scan for them around the clock. Dashboards and internal tools belong behind a VPN or a private network. A VPN would not have fixed plaintext tokens, but it would have cut the attacker’s options sharply.
Final Thoughts
The Zeabur data breach ended a platform that thousands of developers trusted with the keys to their own systems. Nothing exotic broke the company open the second time. Old tokens that nobody expired and an admin portal that nobody closed did the job, and the attacker barely had to work for it. That gap between knowing a security rule and applying it across every system is where most breaches live.
Customers now face a moving deadline and a full key cleanup at once, and both carry real cost. The wider lesson reaches far past one hosting company, because every vendor holding your secrets forms part of your own attack surface. Rotate what you can, close what you expose, and assume that any provider could be next.
