What should I rotate and move before Zeabur shuts down on 31 December?

By Brandon Da Costa, founder of Digiton Dynamics

Published 26 October 2026Updated 26 October 2026Editorial policy

Zeabur says an attacker read environment variables and account data from its platform database on 14 and 15 October 2026. It also says all dedicated servers and shared clusters stop by 31 December. Treat every secret stored there as stolen, and plan the move now.

Who should act: Anyone with services, databases or environment variables on Zeabur, above all on its shared cluster or its GCP dedicated servers.

Update log

26 October 2026: Published.

What happened

On 17 October 2026 Zeabur's founder announced the company is winding down. Some services begin shutting down on 1 December and all dedicated servers and shared clusters stop by 31 December (Zeabur, 17 October). Its preliminary incident report, dated 19 October, says an attacker used leaked internal credentials on 14 and 15 October to enter the shared cluster, some dedicated servers and internal systems, then read the platform database.

Zeabur confirms 3,218,965 environment variable records and 321,810 accounts were read, plus 566 plaintext zSend API keys, all revoked. It says the attacker mainly searched for API keys, especially AI service keys, and tried to call Amazon Bedrock with Zeabur's AWS keys, without success. Zeabur names its own root cause: long-lived admin credentials stored in plaintext and reachable from the internet. The rotation after its August incident did not cover them.

Zeabur's 22 October notice sets the dates. Finish migration by 30 November, when refund requests and incident claims also close. On 31 December all services stop and data is deleted, and dedicated servers go on their own expiry dates, possibly earlier.

Who is affected

Anyone whose environment variables were still stored on Zeabur. Projects that moved them to their own dedicated server after August were outside the database read (Zeabur, 19 October).
Shared cluster users. The attacker ran commands in 865 database services, and Zeabur assesses 736 n8n instances were read. In 602 of 607 it checked, the encryption key sat in a variable, so stored credentials were effectively exposed.
101 GCP dedicated servers, 92 users. Zeabur confirms root sign-ins and tells those users to treat the server as compromised.
Hetzner and DigitalOcean server users. Zeabur cannot confirm whether the leaked management tokens were used and revoked them on 16 October.

What we checked

Run on 26 October 2026 on the Mac that builds this site. Each command and its output are copied as they ran.

$ curl -s https://zeabur.com/blogs/migration-refunds-and-security-claims.md | grep -m1 '^| December 31' | cut -c1-80
| December 31, 2026 | All services will stop and service data will be deleted. A

$ curl -s https://zeabur.com/blogs/october-2026-security-incident.md | grep -m2 -o -E '3,218,965 records|321,810 accounts'
3,218,965 records
321,810 accounts

Both figures and the 31 December date appear in Zeabur's own posts as of today.

What to do now

Replace every credential stored on Zeabur, even ones you replaced after August. Revoke the old one at the provider first, then create a new one and redeploy. That covers API keys, cloud keys, database passwords and signing keys.
Change passwords inside each database, because changing a variable on Zeabur does not change the password in the database. For n8n, replace the encryption key and recreate every credential. For new-api, revoke the upstream AI keys.
Treat a GCP dedicated server as compromised and rebuild it. If you cannot yet, remove keys commented @zeabur-pentest or unknown to you, and check what else was added (Zeabur's checklist).
```
grep -n 'zeabur-pentest' /root/.ssh/authorized_keys
getent group google-sudoers
crontab -l
systemctl list-units --type=service --state=running
```
Read your bills and provider usage from 14 October, and from 1 September for GCP servers. Open your GitHub audit log for Zeabur GitHub App actions between 15:05 and 18:54 UTC on 15 October, looking for clones, pushes, deploy keys and webhooks.
Take inventory before you leave. Log in with the CLI yourself, and do not paste your Zeabur token into an AI agent, because Zeabur says a token has full account access.
```
zeabur workspace list
zeabur project list
zeabur server list
zeabur domain list-registered
```
Back up databases and volumes, transfer domains out yourself, repoint DNS, webhooks and OAuth callbacks away from zeabur.app, and file any loss claim by 30 November.

What should have been in place

No plaintext admin credentials in a configuration repository. Admin tokens with an expiry and an admin interface closed to the internet, which Zeabur says it lacked.
A rotation that covers every credential, not only the ones known to have leaked.
Environment variables kept on your own server, not in a vendor database.
Alerts on valid credentials used oddly. Zeabur says about 36 hours passed between the first credential use and the start of its investigation.
An exit plan for every host: restorable backups, DNS you control and domains at a registrar you own.

Questions people ask

Is Zeabur really shutting down on 31 December 2026?

Zeabur says so itself in its posts of 17 and 22 October. Shared cluster services pause from 1 December and everything stops on 31 December, with data deleted. It recommends finishing migration by 30 November.

How many accounts and variables were affected?

Zeabur's preliminary report (19 October) labels 3,218,965 environment variable records and 321,810 accounts as confirmed. Shared cluster and server data are counted apart, and Zeabur says some of it cannot be confirmed.

Does changing a variable on Zeabur invalidate a leaked database password?

No. Zeabur says changing variables does not change the password inside the database, so change it there and at the provider that issued it.

Can Zeabur compensate me for losses from the breach?

Zeabur accepts incident claims through support until 30 November. It asks for the affected accounts, the leaked key types and third-party invoices or usage records, then checks each case (Zeabur, 22 October).

Digiton's production review maps which provider holds each secret and database and how fast you could move off it, and the checks it runs are on the vibe coded app audit page.

How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.

Sources

Zeabur, October 2026 security incident, preliminary report, 19 October 2026, read 26 October 2026. https://zeabur.com/blogs/october-2026-security-incident
Zeabur, shutdown announcement, 17 October 2026, read 26 October 2026. https://zeabur.com/blogs/zeabur-is-shutting-down
Zeabur, migration dates, refunds and security incident claims, 22 October 2026, read 26 October 2026. https://zeabur.com/blogs/migration-refunds-and-security-claims
Zeabur, final check before leaving, 23 October 2026, read 26 October 2026. https://zeabur.com/blogs/leaving-zeabur-checklist
Zeabur status page, read 26 October 2026. https://status.zeabur.com/

More security briefs

Were my Railway environment variables stolen, and what should I rotate?Was my team affected by the LiteLLM 1.107.0 supply chain attack?

How these briefs are sourced and corrected. All security briefs

Building something that has to hold up in production?

Start with a free 25-minute scoping call. If it fits, the first paid step is a production review: five working days on your real repository, scored against ten layers, with a costed fix list.

Book a 25-minute scoping call