Zeabur, the deployment platform, is shutting down after a second security breach in two months, and an attacker read its platform database, including 3,218,965 service environment variable records with names and values. Environment variables are where most apps keep their secrets: AI provider keys, database passwords, payment keys, signing keys. If you ever stored one on Zeabur, treat it as exposed.
Zeabur announced the shutdown on October 17, 2026 and published a preliminary incident report on October 19. By its own account the root cause was its own: "long-lived admin credentials were stored in plaintext and could be used from the public internet." This post covers the timeline, who is affected, what to rotate and in what order, how the migration deadlines work, and the AI-agent angle. It follows our coverage of the Railway environment variable breach a week earlier; the pattern is the same, and the October trend is in the October 2026 attacks timeline.
TL;DR
| Question | Answer |
|---|---|
| What was exposed? | 3,218,965 env var records (names and values), 321,810 account records, 566 plaintext zSend API keys |
| When? | Attacker active October 14-15, 2026 (UTC); last observed activity October 15 at 21:05 |
| Who is affected? | Everyone with credentials stored on Zeabur; shared cluster and GCP dedicated server users most |
| What should I do now? | Rotate every secret ever stored there, revoke old keys at the provider, check usage logs |
| Is Zeabur shutting down? | Yes: services pause from December 1, final shutdown December 31, 2026 |
| Was it the same attacker as August? | Not established. Zeabur lists that as a hypothesis |
| Does Beam see my Zeabur variables? | No. Beam is local-first and never holds them |
What happened, and how is it different from August?
Zeabur's first incident, in August, started with an authorization flaw (CVE-2026-7644) in a customer's publicly deployed NextChat service on a shared cluster. According to Zeabur's August report, the attacker moved to internal credentials, reached AWS keys and read project environment variables and the production database. Zeabur said afterward that internal admin keys had been disabled or rotated.
The October report says that statement was incomplete. A shared cluster admin token created in January 2024 had no expiry and was not part of the August rotation. It, and AWS keys, sat in plaintext in a private configuration repository. Root passwords for GCP servers were found in server initialization settings on September 3 and not fixed. In October the attacker used those credentials.
BleepingComputer, reporting on October 20, adds that Zeabur believes the credentials were likely obtained during the August breach but has not confirmed it. Zeabur's own report treats the link as a hypothesis and notes the attacker IPs from August and October do not overlap.
Timeline (UTC)
From Zeabur's preliminary report unless noted.
| Date | Event |
|---|---|
| Jan 10, 2024 | Shared cluster admin token created with no expiry |
| Aug 27, 2026 | First breach begins (August report) |
| Aug 31 | GitHub App key replaced; plaintext credentials in the config repository not replaced |
| Sep 1-5 | An unknown source signs in to about 98 GCP dedicated servers as root |
| Oct 14, 01:36-01:40 | Attacker first uses a Zeabur AWS key, then the cluster admin token |
| Oct 14, 12:39 | Settings and secrets of all services on the shared cluster read |
| Oct 14, 13:40 | Commands begin inside user database containers; root sign-ins to GCP servers |
| Oct 15, 13:56 | Investigation starts after a user report |
| Oct 15, 16:10-16:47 | Platform database read |
| Oct 15, 20:25 | Login signing key rotated; all users signed out |
| Oct 15, 20:36 | Public SSH to GCP servers blocked |
| Oct 17 | Zeabur announces it is shutting down |
| Oct 19 | Preliminary report published |
One detail stands out: Zeabur says more than 16 hours of attacker activity on October 14 triggered no alerts, and the incident was found the next day because a user reported it.
What was exposed
| Data | Detail |
|---|---|
| Service environment variables | 3,218,965 records, names and values |
| Account records | 321,810, including email, username and phone number, plus project and service data |
| zSend API keys | 566, stored in plaintext; all revoked |
| Platform access tokens | 11,536, stored only as hashes; all revoked |
| Shared cluster | Env vars and secrets of all services across 9 regions (some confirmed, the rest treated as leaked) |
| Database containers | Commands run inside 865; output not logged, so what was taken is unknown |
| GCP dedicated servers | Root sign-ins on 101 servers (92 users); SSH keys added to 50; 16 customer disk copies attached to attacker-created VMs |
Zeabur says the attacker appeared to look mainly for API keys, especially AI service keys, and tried to call Amazon Bedrock with Zeabur's AWS keys. Those attempts failed. It also reports that a user's OpenAI key was used for about 1,107 image requests on October 16, which it hypothesizes came from this leak but cannot confirm.
Of 607 n8n instances Zeabur checked, 602 kept their encryption key in an environment variable, so the third-party credentials n8n stores are effectively exposed too.
Who is affected
- All users with credentials stored on Zeabur, plus anyone with platform access tokens, zSend keys or account data.
- Shared cluster users, especially those running databases, n8n or new-api/one-api.
- GCP dedicated server users. Zeabur treats all 101 signed-in servers as compromised.
- Hetzner and DigitalOcean dedicated server users. Tokens leaked and Zeabur cannot confirm whether they were used.
- GitHub users who authorized the Zeabur GitHub App. Its private key was read; Zeabur has found no use so far.
Variables that users had already moved to their own dedicated servers after August were not part of the platform database read, per Zeabur and BleepingComputer. Compromised hosts could still expose them.
What to do, in order
Zeabur's instruction is blunt: replace every password and key stored on Zeabur, even if you already replaced them after August. Its order is revoke at the provider first, then create the new key and redeploy.
- AI provider keys. OpenAI, Anthropic, Google, OpenRouter, Mistral, ElevenLabs and any other inference key. Revoke the old key, issue a new one, then check per-key usage since October 14 for spikes, unknown models or odd hours. Set spend limits per key.
- Database credentials. Change passwords inside the database, not just the variable. On PostgreSQL, look for unfamiliar roles, functions, triggers, scheduled jobs or extensions; if in doubt, create a fresh database and import only the data.
- n8n. Replace the encryption key and recreate every third-party credential stored in it. new-api/one-api users should revoke upstream AI keys and regenerate access tokens.
- Auth and signing secrets. JWT, session, OAuth client secrets, application signing keys. Rotating these signs users out; plan for it.
- Payments, email and webhooks. Stripe secret and webhook signing keys, email and SMS providers, Discord and Slack webhooks.
- Zeabur itself. Sign in again and create new access tokens. zSend users recreate their keys. Review bills from October 14 onward (September 1 for GCP dedicated server users).
- GitHub. Review the audit log for Zeabur App actions between October 15, 15:05 and 18:54 UTC: clones, pushes, deploy keys, webhooks.
- Dedicated servers. For GCP, Zeabur says back up and rebuild is the most reliable fix. If you cannot rebuild yet, remove unknown SSH keys (Zeabur names the comment
@zeabur-pentest), check cron, systemd and k3s workloads, change the root password and disable SSH password login. Hetzner and DigitalOcean users should check the provider console for a root password reset or reinstall after October 14.
If you see unexplained charges, revoke first, then contact support with masked values only. Never paste a full key into a ticket.
For a general playbook, see your first 24 hours after a vendor breach.
When must I migrate?
Zeabur's shutdown notice gives these dates for 2026:
| Date | What happens |
|---|---|
| Oct 17 | New dedicated server and domain purchases stop; balance refund requests open |
| Dec 1 | Dedicated server renewals disabled; shared cluster services paused (you can restart manually to back up data) |
| Dec 1-31 | Each dedicated server shuts down on its own expiry date |
| Dec 31 | Shared clusters stop; all dedicated servers expired |
| Not yet announced | Data deletion date, final export deadline, support closing date |
Zeabur warns that December 31 "does not mean that every service will keep running until that day," so check each server's expiry date and finish backups before it. It publishes a migration guide with a Markdown version meant for coding agents such as Claude Code and Codex. Customers who lost money from the October 14 incident can file compensation claims through Zeabur Support, separately from balance refunds. Expect slow support replies.
A practical point: migrate and rotate in that order of urgency only if you must. Rotation does not depend on the migration and should happen now. Do not carry old secrets to the new host.
The AI-agent angle
Zeabur says the attacker was hunting API keys, especially AI service keys. That matches what we covered in the Railway breach, the OpenCode Console incident and the OpenRouter claim: platforms that store many users' variables are a cheap way to collect inference keys, which can be resold or run up on your bill.
If you build with coding agents, ask where else the same key lives. A key set as a Zeabur variable is often also in a local .env, in an agent's MCP config, or in a shell profile that Claude Code or Codex can read. Rotating on the platform does not rotate those copies, and a revoked key left in an agent config will just fail. We cover how keys end up in files and logs in API keys in logs and env vars.
How Beam handles this
Beam is a local-first monitor for AI coding agents. It does not hold your environment variables, does not connect to Zeabur, and cannot tell you whether your project was among the 321,810 accounts. What it can do is flag, on your machine, when an agent reads or writes a .env or credential file, or when a secret-looking string appears in agent activity, so you can find the local copies of a key before rotating. Detection is pattern-based and heuristic, not semantic. Beam's deny is hook-based for Claude Code and Codex, not a sandbox, and it cannot undo a leak that already happened on a third-party platform.
What we do not know
- Whether the October attacker is the August attacker. Zeabur lists this as unconfirmed.
- Exactly what was taken from the 865 database containers, since output was not logged.
- Whether Hetzner and DigitalOcean tokens, and the Taipei and Hong Kong database backups, were used or downloaded.
- Whether the stolen keys have been abused at scale. Zeabur reports one possible OpenAI case and says it is unconfirmed.
- Final data deletion and export deadlines.
We could not load the eSecurityPlanet write-up of this incident, so nothing here relies on it. Zeabur's report is preliminary and may change.
Related reading
- Railway breach: environment variables accessed, some decrypted
- Your first 24 hours after a vendor breach: a rotation and monitoring runbook
- API keys in logs and env vars: how they leak and how to catch it
- OpenCode Console breach: provider keys, claimed vs verified
- OpenRouter breach claim and the AI key theft campaign
- LLMjacking via hijacked GCP billing accounts
- October 2026 attacks timeline
Primary sources: Zeabur is shutting down · October 2026 security incident (preliminary report) · August 2026 security incident · BleepingComputer
Accurate as of October 29, 2026. Zeabur's report is preliminary and its investigation is ongoing; check its blog for updates and final shutdown deadlines.