Zeabur Is Shutting Down After a Second Breach Exposed 3.2 Million Secrets
Dev hosting platform Zeabur will shut down by December 31 after attackers used plaintext admin tokens, never rotated since 2024, to loot its infrastructure. It is the bleakest breach disclosure of the year.

Some breach disclosures are embarrassing. Zeabur's is terminal. The developer hosting platform announced this week that it is shutting down entirely after a second security breach in two months, winding services down from December 1 and going dark for good on December 31, 2026. The stated reason, "the increasing complexity of maintaining secure infrastructure," is doing a lot of diplomatic work. The actual reason is in the details of the attack, and the details are brutal.
The intrusion ran October 14 to 15. Attackers got in using leaked internal credentials that were stored in plaintext: admin tokens and cloud access keys, sitting as readable text in a private config repository. From there they moved through shared clusters across nine regions, dedicated servers, and internal systems, eventually reading the production database. The scope: 321,810 accounts exposed and roughly 3.2 million environment-variable records stolen. Environment variables are where developers store API keys, passwords, and service secrets. If you ever deployed on Zeabur, assume every secret you ever put there is now in someone else's hands.
The Zeabur shutdown: what happened
The attack reads like a checklist of everything a hosting company must never do:
- Plaintext admin tokens with no expiry, created in January 2024 and never rotated. Nearly three years old, sitting in readable text.
- Root access on 101 Google Cloud Platform servers, with the attackers adding their own SSH keys to 50 of them. That is persistence: even if you change the passwords, their keys still open the door.
- 16 customer disk volumes copied and attached to attacker-controlled VMs. Not just metadata, actual disk contents.
- Admin portals reachable from the public internet, so the stolen tokens could be used from anywhere.
And then the part that turns a bad breach into a company-ending one. After the first breach in August, which came through a customer's NextChat app, Zeabur publicly said "all internal admin keys have been disabled or rotated." That statement, the company now admits, was incomplete. The plaintext tokens used in the October attack were left out of the rotation. The August fix missed the exact keys the October attackers used. You can survive one breach. Surviving your own incomplete remediation is harder, because it tells customers the problem is not the attackers, it is you.
If you hosted on Zeabur, do this now
Zeabur's own disclosure includes user guidance, and it is worth repeating plainly because the window is short:
- Rotate every secret ever stored in a Zeabur environment variable. API keys, database passwords, third-party tokens. All of them, not just the important-sounding ones.
- Revoke all active sessions on every service those secrets touched.
- Rebuild any infrastructure that shared credentials with your Zeabur deployments. The attackers had root on Zeabur's GCP fleet; treat anything downstream as potentially compromised.
- Migrate your workloads before December 31. The platform is going away regardless. Pick your new host now, not during the holiday freeze.
This is the breach-response playbook applied at maximum urgency, because the blast radius here is unusually wide. The Nikkei breach earlier this month exposed 1.83 million records through stolen cloud credentials; Zeabur's is smaller in headcount but worse in kind, because what was stolen was not customer data but the keys to everything.
The uncomfortable lesson
Zeabur's shutdown will be filed under "startup fails," but the real story is operational. Nothing in this attack required a zero-day or a nation-state. It required tokens stored in plaintext, never rotated, with no expiry, guarding admin portals exposed to the internet. Every one of those is a solved problem: secret managers exist, rotation policies exist, IP allowlists exist. The company just did not do them, twice.
There is a pattern worth naming. Supply-chain attacks that walk straight into cloud consoles keep working because the industry keeps underinvesting in the boring parts of security while overinvesting in the exciting parts. Zeabur is the extreme endpoint of that trade: a hosting company that could not secure its own hosting. The shutdown is honest, at least. It is more than most breached companies offer. But 321,810 accounts and 3.2 million secrets would trade the honesty for competence in a heartbeat.


