Env Var Secrets: Zeabur's Shutdown Lesson
Zeabur's shutdown follows 3.2 million leaked environment variable records. Four storage patterns for secrets, ranked by the blast radius each one leaves.
RBLast updated

title: "Env Var Secrets: Zeabur's Shutdown Lesson" slug: "2026-10-28-env-var-secrets-zeabur-shutdown-lesson" meta_title: "Env Var Secrets: Zeabur's Shutdown Lesson" meta_description: "Zeabur's second breach leaked 3.2 million env var secrets plus 321,810 accounts. Rank your storage patterns and fix rotation scope before an attacker does." primary_keyword: env var secrets author: Krova Cloud Engineering date: 2026-10-28 schema: BlogPosting+FAQPage category: AI Code Sandboxing secondary_keywords: environment variable leakage, platform credential storage, secret rotation scope, PaaS breach, agent platform secrets excerpt: "Zeabur's shutdown follows 3.2 million leaked environment variable records. Four storage patterns for secrets, ranked by the blast radius each one leaves."
Env Var Secrets: Zeabur's Shutdown Lesson
Zeabur, a Taiwanese deployment platform, is shutting down on 31 December after two breaches in two months. In October an attacker read its platform database with plaintext admin tokens. The haul: 321,810 accounts and about 3.2 million env var secrets. That env var table is the widest credential surface most platforms own. Almost nobody audits it.
The shutdown timeline is public. Renewals stop on 1 December, shared clusters pause the same day, and every server goes dark on 31 December, per Zeabur's 17 October shutdown post. The founder cited two security incidents this year alongside business reasons.
What Zeabur actually lost
The October report describes an attacker using internal credentials stored in plaintext to read the platform database. The haul covered 321,810 customer accounts and roughly 3.2 million environment variable records, the place where apps keep API keys, database strings and registry passwords.
Worse, the tokens had no expiry. SecurityToday's October roundup notes the admin tokens were never rotated since January 2024. A credential that old stops being a secret. It becomes a fixture of your infrastructure that attackers inherit.
The rotation gap is the sharpest detail. Zeabur's August report claimed all internal admin keys were disabled or rotated. Its October report corrects that as incomplete. Shared cluster admin tokens and internal AWS keys sat in plaintext in a config repo. They survived the August cleanup and worked in October, per the breach analysis published by Cremit.
Why env var secrets became the blast radius
Env vars feel harmless. They look like plain text in a config screen. In practice they form a credential database with no access log, no expiry and no rotation reminder. Every service you ever wired up left one key behind.
Attackers know this. The OpenCode Console breach exposed provider keys pasted into workspaces, and the Aoki infostealer campaign harvested agent credentials from developer machines, as we covered in the OpenCode breach breakdown and the Aoki credential analysis. Zeabur adds the platform-side version of the same story: the operator's own table became the prize.
Four storage patterns, ranked
Pattern one is the platform env table, what Zeabur kept. Every key sits in one database, readable by anyone holding one admin token. Blast radius: total.
Pattern two is a workspace secret store with encryption at rest and per-workspace access. Better, but keys still live forever unless you force expiry. Blast radius: one workspace, forever.
Pattern three is per-session injected credentials. The sandbox receives a short-lived token at start and nothing persists after stop. Blast radius: one session, minutes.
Pattern four is an external vault issuing scoped tokens on request, with issuance logged. Nothing rests inside the platform at all. Blast radius: one scope, one request. Our self-hosted CI runners guide uses this shape for build credentials.
The rotation completeness audit
Zeabur's mistake was rotating what the first incident touched, not what an attacker could reach. Scope your rotation list to the attacker's reach: every system the compromised identity could read, including systems it never touched.
Run the audit as four questions. Which credentials rest in plaintext anywhere, including config repos? Which tokens lack expiry? Which keys survived the last rotation, and why? Which third-party trusts an internal token forever? Railway's post-incident advice to rotate all variables, API keys and registry credentials is the blunt version of the same audit.
We checked Zeabur's shutdown post and both incident reports on 28 October. The pattern matches what our audits of sandbox fleets keep showing: the secrets table grows quietly and rotates never.
Verdict
We recommend moving env var secrets down the ranked list until nothing persistent rests inside your platform: vault-issued scoped tokens for services, per-session injection for sandboxes, and expiry on everything that must persist. Then run the rotation completeness audit twice a year, because Zeabur's October report proves a partial rotation reads as a full one until an attacker files the correction.
Limitations
- Zeabur's figures come from its own reports and press coverage; however, no independent forensic report has published yet.
- The ranked patterns describe blast radius, not implementation cost, and vault patterns add latency we do not measure here.
- We did not inspect Zeabur's infrastructure, so the plaintext storage detail rests on its October report.
- Rotation advice assumes you can enumerate credentials; legacy estates often cannot, and we have not solved that case.
FAQ
Why are environment variables riskier than a secrets manager?
They lack expiry, access logs and rotation prompts, and they accumulate in one readable table. A single admin token exposes every key ever stored.
Did the August rotation failure cause the October breach?
Directly, per Zeabur's own correction: tokens skipped in August were the ones used in October. Rotation scope, not rotation effort, was the gap.
What should agent platforms store for users' API keys?
Short-lived scoped tokens issued per session, never a persistent plaintext table. The OpenCode and Zeabur incidents both started from keys at rest.



