What happened
Zeabur is a developer hosting and deployment platform: connect a GitHub repository, and it handles deployment, databases, HTTPS, and the surrounding infrastructure automatically. Between October 14 and 15, an attacker used leaked internal credentials to get into the platform's shared cluster, some of its dedicated servers, and internal systems, then read the platform's own database. Zeabur confirmed the attacker gained root access on 101 Google Cloud servers across nine regions, with 92 separate users performing those sign-ins.
The scale of the intrusion went well beyond a simple data read. Attackers added SSH keys to 50 servers, giving themselves persistent access independent of the original stolen credentials, and attached 16 customer disk copies to virtual machines they controlled, a step that suggests an attempt to exfiltrate customer data directly rather than just browse the platform's internal records. In total, about 3.2 million environment variable records and account information for 321,810 users were exposed.
The root cause: credentials that were never rotated
The detail that turns this from a bad breach into a damning one is how the attacker got in. Zeabur's admin tokens had no expiration date and had not been rotated since January 2024, nearly three years of exposure window if those credentials were compromised at any point during that span. Admin portals were also reachable from the public internet, removing even a network level barrier that might have limited who could attempt to use those credentials in the first place.
Credential rotation and token expiration are not advanced security practices. They are baseline hygiene that every infrastructure provider handling other companies' production databases and secrets is expected to maintain as a matter of course. Their absence here, combined with public internet exposure of the admin surface, describes a company that treated its own internal security posture with less rigor than it almost certainly asked its customers to apply to theirs.
A second breach, the same failure repeating
This was not Zeabur's first incident this year. In August, attackers exploited a vulnerability in a customer's NextChat application and moved through poorly isolated internal systems from there, eventually stealing AWS credentials and reaching the production database, exposing account information, API keys, and other secrets. Zeabur responded to that breach, but says it believes, without having confirmed, that the credentials used in the October breach were obtained during the August incident.
If that belief holds up, it means the remediation after the first breach failed to close off the access the attacker had already gained, and the second breach was not really a new intrusion so much as the first one being used again months later. That is a far more serious failure than a single bad incident, because it points to an incident response process that cleaned up the visible symptoms in August without finding and revoking everything the attacker had actually touched.
Why the company chose to shut down
Zeabur announced its shutdown over a weekend following the October breach, citing three and a half years of growth, including a record 2026, that had made the platform increasingly complex and hard to maintain as it scaled. It paired that explanation with a direct reference to the recent security failures, telling customers in its own words that it had ultimately decided to wind down rather than continue operating under the weight of both problems at once, infrastructure complexity and repeated security lapses feeding into each other.
That framing, growth complexity alongside security failure, is a candid admission that the company's operational and security practices had not kept pace with how large and complex the platform had become over three and a half years of expansion. Winding down is arguably the right call for a company that has lost the confidence to guarantee the basic security of customer data twice in two months, and it is a more honest outcome for customers than limping forward while quietly hoping a third breach never materializes on top of the first two.
The migration window customers are facing
The shutdown timeline is tight. Starting December 1, Zeabur will disable renewals and pause running services on shared clusters. By December 31, all dedicated servers will expire and shut down, and shared clusters will stop entirely. Zeabur has said it may give users extra time for data migration but has not committed to a specific extended timeline, leaving affected customers to plan around the worst case date rather than a confirmed grace period.
Zeabur's own guidance to customers is to rotate every exposed credential and secret immediately, revoke all active sessions, and rebuild any compromised Google Cloud servers rather than trusting them after the fact. It also notes that variables customers moved to their own servers during the August response were not exposed in this second database leak, though any host that was itself compromised could still expose those variables through a different path.
What this means for vendor risk reviews
Any enterprise evaluating a developer infrastructure vendor, whether for hosting, deployment, databases, or secrets management, should treat credential rotation policy and admin surface exposure as standard due diligence questions, not advanced ones reserved for a security team's deepest audit. Ask directly when administrative tokens were last rotated and whether admin interfaces are reachable from the public internet, because Zeabur's honest answers to those exact two questions would have predicted this outcome well before the October breach ever occurred.
The broader lesson sits with incident response quality, not just prevention. A breach handled well closes every door the attacker opened, not just the one that was initially visible to the team investigating it under pressure. Zeabur's second incident is a reminder that remediation needs to be verified as thoroughly as the original vulnerability was investigated, and that any vendor's post incident report should state plainly what they did to confirm the attacker's access was fully revoked, beyond listing which specific vulnerability they patched after the fact.
