If you deploy to a platform, its environment-variable store is where your production secrets live. This week one such store was copied, and the platform decided to close. Zeabur, a development and hosting platform, has disclosed that an attacker used leaked internal credentials stored in plaintext to get into its infrastructure and steal more than 3.2 million environment-variable records and information for 321,810 accounts. It is the second breach in two months, and Zeabur says it will wind down the service.
For anyone who hosted there, the work starts with a list: every secret that was in an environment variable.
What Zeabur says
According to BleepingComputer's report on Zeabur's disclosure, the latest intrusion ran on 14 and 15 October. The attacker used stolen administrator credentials and cloud access keys, which gave access to shared clusters, some dedicated servers and internal systems. Zeabur says administrator tokens had no expiry and had not been rotated since January 2024, and that administration portals were publicly reachable.
- Scale. More than 3.2 million environment-variable records and information on 321,810 accounts, across nine regions.
- Reach on servers. Root sign-ins on 101 Google Cloud servers, SSH keys added to 50 servers and 16 customer disk copies attached to attacker-controlled machines.
- The earlier breach. In late August an attacker exploited a flaw in a customer's NextChat application, moved through poorly isolated systems, stole AWS credentials and reached the production database.
- The shutdown. Renewals are disabled and shared-cluster services paused on 1 December, and dedicated servers expire and clusters stop on 31 December. Zeabur cited the difficulty of maintaining the platform as it grew.
- What it tells customers. Rotate exposed credentials and secrets immediately, revoke active sessions and rebuild any compromised Google Cloud servers.
What is not known
- Whether the data has been published or sold. Zeabur says it was stolen; nothing says what happened next.
- Whether the August credentials were the ones used in October. That link is unconfirmed.
- Who the attacker is and why. No attribution or motive was given.
- Which hosts may still expose secrets and how customers will migrate.
- The contents of the records. An environment-variable record can hold anything a customer chose to put in one. Zeabur has not said which kinds were taken.
These details are Zeabur's own account as relayed by one outlet; we did not read Zeabur's original post. Treat the figures as the company's statement, not as independently verified.
Why environment variables are the prize
Environment variables are how most platforms hand secrets to applications: database URLs, API keys, OAuth client secrets, webhook secrets, cloud credentials, signing keys. A customer who built an application there has, by design, put the most sensitive values it has into that store. Copying the store is copying the keys to the customer's databases, payment providers, email services and cloud accounts.
The second lesson is about the platform's own hygiene, which customers cannot see: credentials in plaintext, administrator tokens that never expire, portals open to the internet. You cannot audit a platform's secrets, so assume that anything you give one can eventually leak and limit what each value can do.
What to rotate if you ran anything on Zeabur
- List every environment variable you ever set, including old projects, preview deployments and ones you thought you had deleted. Treat the whole list as exposed.
- Rotate by blast radius. Cloud account keys and database passwords first, then payment, email and messaging keys, then signing keys and OAuth or webhook secrets. For each, create a new value, deploy it somewhere other than Zeabur, then revoke the old one.
- Check use before you revoke. Look at the access logs of the services those secrets reach for sign-ins, API calls or downloads from unfamiliar places since the late-August breach, not only since 14 October.
- Revoke sessions and tokens. Zeabur's own account sessions and any personal access tokens or deploy keys connected to your repositories.
- Rebuild, do not clean. If you ran servers on the affected Google Cloud infrastructure, Zeabur advises rebuilding them, since SSH keys were added and disk copies were taken.
- Treat code-hosting links with care. If the platform held a connection to your GitHub or GitLab, revoke it and rotate repository secrets as well.
- Plan the migration around the deadline. You have until 1 December for shared-cluster services and 31 December for dedicated servers, but the exposure is already in the past; do not wait for the shutdown.
Reduce what the next platform can lose
Prefer short-lived credentials issued at run time to long-lived keys in a variable. Give each service its own key with the narrowest scope, restrict databases to the addresses that should reach them, and make rotation something you can do in an afternoon. Keep an inventory of where each secret lives so the next list is already written.
The migration handover
Moving to a new host produces a wave of new credentials that must reach whoever configures the new environment. It is also the likeliest moment for them to be pasted into a ticket, a chat or a README. Send each value once, to the person who needs it, over a channel that does not keep it.
Where Secretus fits, and where it does not
Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret.
It is not a hosting platform or a secrets manager. It cannot rotate your keys, tell you which variables Zeabur held or inspect your cloud logs. Do those with your providers' tooling, and use a one-time link for the moment one person gives another a new credential.