Zeabur Breach: 321,810 Accounts and 3.2M Secrets Exposed

October 19, 2026: Zeabur, a developer hosting and deployment platform, published a preliminary report on its second breach in two months. Between October 14 and 15 an attacker read secrets from every service on its shared clusters in nine regions, took root access on 101 customer servers, and read the platform database: 321,810 accounts and 3,218,965 environment-variable records. Zeabur has since announced it will shut down on December 31, 2026. Canonical: zeabur-shared-cluster2026. Primary source: Zeabur's incident report.

Zeabur lets developers connect a GitHub repository and have the platform handle builds, databases, HTTPS and servers. That convenience means customers hand it the most sensitive values they own: database passwords, cloud keys, AI provider keys and signing secrets, usually stored as environment variables. Those values are exactly what was read. This was not a breach of a few user profiles. It was a breach of the credentials that run other companies' production systems.

What happened

The August breach that set this up

On August 27 an attacker exploited a customer's NextChat application (v2.16.1, CVE-2026-7644) running on a Zeabur shared cluster. Weak isolation let them reach a routing cache holding Zeabur's legacy API keys, use a team administrator's key, find an AWS root key inside an internal service, and read project environment variables from the production database. Zeabur learned of it on August 28 from an API-key abuse report, notified users, and rotated keys. It is recorded separately as zeabur-nextchat2026.

That rotation missed two things: a shared-cluster admin token created in January 2024 with no expiry, and AWS keys, both stored in plaintext in a configuration repository since January 2026.

October 14–15: two paths in

• Path A, shared clusters. At 01:36 UTC on October 14 the attacker used a Zeabur AWS key, and four minutes later the never-expiring admin token, against an admin interface that was reachable from the internet. By 12:39 they had read the settings and secrets of all services on the shared cluster across nine regions, then ran commands inside 865 customer database services, 736 of them n8n.
• Path B, dedicated servers. Root passwords stored in plaintext initialization settings gave the attacker root sign-ins on 101 Google Cloud dedicated servers belonging to 92 users. They added SSH keys to 50 servers, created five VMs, and attached copies of 16 customer disks to them.
• Joining the paths. On October 15 internal network credentials taken from a compromised server let the attacker add their own node to Zeabur's internal network and read the platform database between 16:10 and 16:47 UTC. They also called Zeabur's API while impersonating two accounts, one belonging to an employee.

Zeabur began investigating at 13:56 UTC on October 15, after a user report rather than its own monitoring, and removed the attacker's node at 17:58. The last observed activity was at 21:05 UTC that night.

Technical analysis

Nothing here required a zero-day. The October intrusion ran on long-lived credentials that should not have existed in the form they did:

• Secrets in plaintext, in a repository. An admin token and cloud keys sat in a config repo where anyone who reached it could use them.
• No expiry and no rotation. The cluster token had worked since January 2024. Zeabur's own report says the August response did not rotate it.
• Admin surface on the internet. The shared-cluster admin interface was publicly reachable, so a stolen token needed no foothold inside the network.
• Shared root passwords on customer servers. Plaintext root passwords in initialization settings turned one data leak into root on 101 machines.
• Detection by customers. Both incidents were found through outside reports, not alerts.

The n8n detail matters for customers. Of 607 n8n instances Zeabur checked, 602 stored their encryption key in an environment variable. That key decrypts the credentials n8n keeps for every workflow, so reading environment variables effectively exposed those downstream logins too.

Impact

• Accounts: 321,810 accounts with email, username, phone number and profile data.
• Secrets: 3,218,965 environment-variable names and values, plus 566 zSend API keys stored in plaintext and 11,536 hashed access tokens (all revoked).
• Servers: root access on 101 dedicated servers, persistence through SSH keys on 50, and 16 customer disks copied.
• Possibly backups: backups in the Taipei and Hong Kong regions may have been downloaded; Zeabur has not confirmed this.

The second-order risk is larger than the first. Every API key, database password and cloud credential in those records should be treated as known to the attacker until it is replaced, which means customers' own users and data may be exposed through systems Zeabur never hosted.

Verified vs unverified

• Verified (Zeabur): the timeline, both attack paths, and all counts above come from Zeabur's preliminary report of October 19 and its August post.
• Not established: how the attacker originally obtained the October AWS key and admin token (Zeabur believes, but has not confirmed, it was during the August breach), whether a September wave of root sign-ins on about 98 servers was the same actor, and whether backups were downloaded.

What to do

1. Rotate every secret you ever stored on Zeabur. Revoke the old value with the provider first (AWS, Google Cloud, Stripe, OpenAI, Anthropic and so on), then issue a new one. Changing it only inside Zeabur is not enough.
2. Change database passwords for services on shared clusters, and on PostgreSQL look for roles, functions or scheduled jobs you did not create.
3. n8n users: replace the encryption key and re-enter workflow credentials, since the old key decrypts them.
4. Dedicated-server users: treat the machine as compromised. Back up your data, rebuild from scratch, and check authorized_keys for the comment @zeabur-pentest.
5. Create new access tokens and zSend API keys, and review your GitHub audit log for Zeabur GitHub App actions between 15:05 and 18:54 UTC on October 15.
6. Check cloud bills from October 14 (September 1 for dedicated servers) for usage you do not recognise.
7. Plan your migration now. Shared-cluster services pause on December 1 and everything stops on December 31, 2026.

Related incidents

Hosting-provider compromises spread to customers fast because the provider holds their keys. Compare the FirstVDS breach, where stolen SSH keys and API tokens put customer infrastructure at risk (our write-up), and the OpenCode Console breach, which exposed users' AI provider keys (our write-up). For a cross-tenant isolation failure at a larger platform, see Cloudflare Containers.

Sources

Zeabur: October 2026 security incident • Zeabur: August 2026 security incident • Zeabur: shutdown announcement • BleepingComputer