Threat intel
Zeabur breach: replace every secret you stored there
Zeabur is shutting down after a second breach read 3.2 million environment variable records. How to find, revoke and migrate every secret you kept there.
Zeabur, a Taiwanese cloud deployment platform, is closing. On October 14 and 15 an attacker used Zeabur's own admin credentials to get into its shared cluster, its Google Cloud (GCP) Dedicated Servers and its internal systems, and read the platform database. Zeabur's preliminary report of October 19 counts 3,218,965 service environment variable records read, names and values, and 321,810 accounts. Two days earlier, on October 17, the founder had announced the wind-down and stopped new server and domain purchases.
This was the second breach in seven weeks. On August 27 an attacker read part of the production database, including project environment variables full of API keys and database passwords. If you, a contractor or a team at your company ever deployed anything on Zeabur, Zeabur's advice is to replace every password and key you stored there, including the ones you already rotated after August. Shared cluster services pause on December 1 and everything is gone by December 31, so the rotation and the migration now have to happen together.
How it works
A platform as a service (PaaS) like Zeabur builds and runs your code, and you give it the secrets the code needs as environment variables: an OpenAI key, a Stripe key, a DATABASE_URL, a JWT signing secret. The platform has to store those values somewhere it can read them back at deploy time, which in Zeabur's case was its platform database. Whoever can read that database, or the cluster that runs your containers, can read every customer's secrets in one place.
The August intrusion started in a customer's container. A user had deployed NextChat v2.16.1, which has CVE-2026-7644, an authorization flaw in its MCP (Model Context Protocol) feature that gave the attacker code execution inside the container. From there they reached a cache on the shared network that held Zeabur Legacy API Keys, found one belonging to a team administrator, used it to read an internal service's environment variables, and found an AWS root key among them. That led to the Tokyo shared cluster and, through an over-permissioned maintenance job, to the production database.
The October intrusion needed no customer bug. Zeabur says the root cause was "long-lived admin credentials" stored in plaintext. The shared cluster admin tokens had been created in January 2024 with no expiry and were not part of the rotation after August. With them the attacker had admin access to the shared cluster in nine regions, which means read access to the settings and secrets of every service running there. Zeabur suspects, without proof, that the credentials trace back to a GitHub App private key read in August.
What the attacker did
According to Zeabur and coverage by teiss and iThome, the attacker signed in as root to 101 GCP Dedicated Servers belonging to 92 users, added SSH keys to 50 of them, and attached copies of 16 customer server disks to virtual machines they created.
The August keys were put to work quickly. Zeabur first heard of that breach on August 28 from a report of API key abuse, not from its own alerts, and its founder said stolen Anthropic, OpenAI and OpenRouter keys were being used without authorization. Zeabur has revoked its cluster tokens and cloud keys, signed every user out and revoked all platform Access Tokens and zSend API keys. None of that touches the third party keys you stored, which stay valid until you revoke them.
What to do
1. Build the list. Open every project and every service in the Zeabur Dashboard and copy out the variable names, including services that have been idle for months. Then search your repositories for what the code reads at runtime (process.env., os.environ, os.Getenv) to catch anything set by a template or a teammate. Mark each one with the provider that issued it.
2. Revoke at the source. Deleting or editing a variable on Zeabur does nothing to the key itself, and creating a new key at the provider does not disable the old one. For each entry, revoke the old credential in the provider's console and issue a new one. Start with what costs money or opens other doors: cloud keys, payment keys, AI provider keys, GitHub tokens, email sending keys.
3. Change database passwords inside the database. A new value in the environment variable leaves the real password unchanged. On PostgreSQL that is ALTER ROLE app_user WITH PASSWORD '...', followed by a check of \du for roles you did not create and of installed extensions and scheduled jobs. If a shared cluster database was among those read, it is cleaner to create a new database and import only the data.
4. n8n. The N8N_ENCRYPTION_KEY that protects n8n's stored credentials sat in the same environment variables, so treat every credential in n8n as exposed. Export your workflows with the old key in place, then in the new environment set a fresh key and re-create each third party credential with newly issued secrets.
5. Look for use. Read provider usage pages and bills from August 27 onward. For AWS keys, aws iam get-access-key-last-used --access-key-id <id> shows the last call, region and service, and CloudTrail shows the rest. Check your GitHub organization's audit log for actions by the Zeabur GitHub App you did not expect: clones, pushes, new deploy keys, changed webhooks.
6. Dedicated server owners. Treat the machine as compromised and rebuild it from a clean image after backing up data. Until then, remove any key in /root/.ssh/authorized_keys with the comment zeabur-pentest, change the root password and set PasswordAuthentication no in sshd_config. Zeabur's report lists the attacker IP addresses and SSH key fingerprint to search for in your sign-in logs.
Migrating without carrying the problem along
Back up databases and volumes before December 1 and restore them once in the new environment to prove the backup works. Copying the old .env file to the new host would move secrets you have just declared compromised, so only the new values should reach it.
This is also the moment to stop keeping secrets as plain environment variables in a hosting dashboard. Put them in a secret manager such as AWS Secrets Manager, Google Secret Manager or HashiCorp Vault, have the application or the deploy pipeline fetch them at start-up, and turn on the access log so every read is recorded. For cloud access, use workload identity (GitHub Actions OIDC, GCP Workload Identity Federation, AWS IAM roles) so the host gets short-lived credentials and there is no static key to steal. Give each service its own credential with the smallest scope the provider allows, so one leaked value does not open everything.
Ask the same question of the platforms you still use: who on their side can read your secrets, and would you know if they did? Zeabur learned of the August breach from a customer whose stolen key was already being abused.
If you need help working out what a Zeabur deployment exposed, or moving workloads to a setup where secrets live in a manager rather than a dashboard, our cloud and Kubernetes security and platform and cloud engineering teams do this work. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Zeabur October 2026 security incident (preliminary report), Zeabur August 2026 security incident, Zeabur is shutting down, Zeabur status page incident, teiss, iThome, AIIDE List migration guide, Ray's blog, Frank Chen.