Zeabur's two breaches: attackers went hunting for AI keys, and an un-rotated admin token ended the platform

Zeabur, a Taiwanese deployment platform widely used to host n8n automations and AI chat front-ends, has published a detailed post-mortem of its second breach in two months, and its own conclusion is blunt: the attacker "was mainly looking for API keys they could use directly, especially keys for AI services". The October 14–15 intrusion ran on long-lived admin credentials that were stored in plaintext, had never expired and, by Zeabur's account, were missed by the rotation after the August breach — which itself began in a customer's AI chat app. Zeabur announced on October 17 that it will stop all services by December 31, 2026; the lesson for everyone else is that AI keys are now the first thing intruders look for, and a platform's secrets store is where they look.

The short version

Zeabur is a platform-as-a-service: you point it at code or pick a template, and it runs the app for you on shared clusters or on dedicated servers. It later leaned into AI tooling — n8n templates and its own "AI Hub" gateway, as an early user recounts — and, like every such platform, it kept each customer's configuration, including passwords and API keys, as environment variables in its own database.

In late August an attacker got in through a vulnerable copy of NextChat, an open-source AI chat web app that one customer had exposed to the internet, and worked their way up to Zeabur's cloud accounts and production data. Zeabur rotated credentials and said all internal admin keys had been dealt with. They had not all been. On October 14 someone used a Zeabur AWS key and a cluster admin token that dated from January 2024, read the settings and secrets of every service on the shared cluster, got root on 101 Google Cloud servers, and finally read the platform database: about 3.2 million environment-variable records and 321,810 accounts. More than 16 hours of this triggered no alert; a user report started the investigation.

What the attacker went after is the part that matters beyond Zeabur. They read credentials out of n8n workflow instances and out of new-api/one-api — the self-hosted relays people use to pool and resell access to AI models — and they tried to call Amazon Bedrock with Zeabur's own AWS keys. AI keys convert straight into money or free compute; they are the new cloud password.

Zeabur was not an isolated case. On October 30, Wiz Research listed Zeabur (disclosure dated October 14) among at least nine AI developer platforms breached in October 2026 by attackers hunting stored AI keys; Wiz found no single vulnerability linking them (our coverage of the Wiz analysis).

Timeline

All times UTC, as given by Zeabur.

• January 10, 2024 — Shared-cluster admin token created, with no expiry (October report).
• January 20, 2026 — That admin token written in plaintext to Zeabur's configuration repository (October report).
• May 2, 2026 — CVE-2026-7644 published: improper authorization in NextChat's addMcpServer function, versions up to 2.16.1 (OSV).
• August 27, 2026 — First intrusion. Attacker starts from a customer's publicly accessible NextChat v2.16.1 service on the shared cluster; first read of project environment variables at 03:53, bulk reads from 11:52 (September 7 report). Zeabur's GitHub App private key is read the same day (October report).
• August 28 — First report of API-key abuse at 02:34; AI Hub suspended; first user notice at 08:53, which Zeabur later said "did not cover the full scope of impact" (September 7 report).
• August 31 — GitHub App private key replaced; other plaintext credentials not rotated (October report).
• September 1–5 — An unknown source signs in to about 98 GCP dedicated servers with the root password; on September 3 root passwords are found in GCP initialization settings but not fixed (October report).
• September 7 — Zeabur publishes its August report, stating it "disabled or rotated every internal administrative key".
• October 14, 01:36–01:40 — Attacker first uses a Zeabur AWS key, then the shared-cluster admin token.
• October 14, 12:39–13:40 — Attacker reads settings and secrets of all services on the shared cluster, begins reading database containers and signing in to GCP servers.
• October 15, 13:56 — Investigation starts after a user report.
• October 15, 15:30–16:47 — Attacker adds a node to Zeabur's internal network and reads the platform database.
• October 15, 20:25–21:05 — Login signing key rotated and all users signed out; public SSH to GCP servers blocked; last observed attacker activity at 21:05 (AWS).
• October 16, 01:50–02:56 — A customer's OpenAI key sends about 1,107 image-generation requests; Zeabur hypothesises the key came from this leak.
• October 17 — Founder Yuanlin Lin announces Zeabur is shutting down.
• October 19 — Preliminary October incident report published.
• October 20–21 — BleepingComputer and SC Media report the shutdown.
• October 30 — Wiz Research includes Zeabur in its analysis of nine October breaches at AI developer platforms.
• December 1 / December 31, 2026 — Renewals end and shared-cluster services pause; all services stop.

What we know

Who said it. Almost everything here comes from Zeabur itself: the October preliminary report (October 19), the August incident report (September 7), and the shutdown announcement (October 17), all signed by founder Yuanlin Lin. Press coverage adds no independent reporting. As of November 5, 2026, the October report is still labelled preliminary and carries no dated updates.

Root cause, in Zeabur's words. "The root cause of this incident lies with Zeabur: long-lived admin credentials were stored in plaintext" and were usable from the public internet. The report lists contributing factors: admin tokens with no expiry, never rotated; an admin interface reachable from the internet; plaintext secrets in the configuration repository, code and cluster settings; root passwords in GCP initialization settings; cluster backups containing every secret, with the backup key stored next to them; an AWS key that could read every bucket; a GCP default service account with project-wide write access; an internal "read-only" database account that could read all data; and internal and customer workloads sharing one cluster.

Detection. "More than 16 hours of attack activity on October 14 triggered no alerts," the report says. Both incidents were found by customers: in August through a report of API-key abuse, in October through a user report.

Scale (Zeabur's figures). Platform database: 3,218,965 service environment-variable records and 321,810 accounts (email, username, phone number, project data); 11,536 platform access tokens and 566 zSend API keys, all revoked. Shared cluster: nine regions, commands run inside 865 customer database containers — 736 of them n8n instances, 211 PostgreSQL databases read "table by table" (up to 50,000 rows per table), and 10 new-api/one-api instances. Dedicated servers: root sign-ins on 101 GCP servers belonging to 92 users, attacker SSH keys on 50, five VMs created and 16 customer disk copies attached. About 53 production secrets were read.

The AI targeting. Zeabur states that the attacker "searched the platform database for keys, read credentials in n8n and new-api/one-api at scale" and "was mainly looking for API keys they could use directly, especially keys for AI services". They "started with a few new-api/one-api instances, read n8n at scale from 15:41". Of the n8n instances on PostgreSQL that Zeabur checked, 602 of 607 had their encryption key set in an environment variable — the same place the attacker was reading. The attacker "tried to call Amazon Bedrock, but every attempt failed and no charges were incurred."

In August the pattern was similar: the attacker read project environment variables containing "API keys for AI and other third-party services", and created access keys for Zeabur's own AI Hub, for which Zeabur says "no AI Hub usage was identified". AI Hub was suspended on August 28 and never came back.

The broken promise. The August report said Zeabur had "disabled or rotated every internal administrative key". The October report: "That statement was incomplete, and we are correcting it here." The August rotation did not cover the cluster admin tokens and AWS keys sitting in plaintext in the configuration repository.

Attribution. None. Zeabur names no actor, mentions no law-enforcement referral, and says that whether the August and October intruders are the same person "currently cannot be confirmed". The only tooling detail is a Boto3 (AWS Python SDK) user agent and "heavy use of rotating proxy servers".

The shutdown. Lin's post cites growth that "started to run into limits", an architecture that became "increasingly complex and difficult to maintain", and the weaknesses the two incidents exposed. Customers who lost money through the incident can claim compensation via support; Zeabur says it will check providers' usage records.

Technical analysis

Two chains, one lesson. The August chain is a textbook escalation through four trust boundaries, each crossed with a secret found lying around: a customer app on a shared cluster → a routing cache that also held platform API keys → an internal service whose environment held an AWS root key → a maintenance job with a network path into production. The October chain needed no exploit at all: valid, never-expiring admin credentials, usable from anywhere. The likely connection — that the October credentials came from the configuration repository, possibly reached via the GitHub App key read in August — is Zeabur's hypothesis, not a finding.

Why the controls failed. Every layer assumed the one below was private. Secrets lived in places that were "internal" (a config repo, a routing cache, init scripts, backups) and therefore unprotected, and the credentials themselves had no expiry, no network restriction and broad scope. Incident response then rotated what was found to be compromised rather than everything that could have been — the classic post-breach mistake, and it is what turned a bad incident into a terminal one. Detection depended on customers noticing abuse of their own keys.

What is new about the AI angle. Nothing in the reports says the attacker used AI. The AI angle is economic and architectural:

• AI keys are the most liquid secret in an environment-variable dump. A database password needs a reachable database; an AI API key works from anywhere, immediately, and can be resold or burned for compute. Zeabur's description of the attacker's priorities fits what our October 18 brief on Bitsight's findings and earlier pieces on PoeLLM and Carbonato described: stolen model-provider keys are now a commodity that funds other operations.
• AI middleware concentrates keys. new-api and one-api exist to pool many upstream model keys behind one endpoint; an n8n instance holds credentials for every service its workflows touch, encrypted with a key that, in 602 of 607 checked cases, sat in the same environment. Reading one of these yields many keys. They are high-value targets by design, and they are usually deployed by people who think of them as productivity tools, not as credential vaults.
• The AI app was the door. The August entry was an AI chat front-end with an authorization flaw in its MCP (Model Context Protocol) feature — the plug-in mechanism that lets the app connect to tools. Our assessment: MCP "add a server" functions are a dangerous class, because adding a tool server can mean telling the host what program to run; an unauthenticated version of that function is close to remote command execution by design. A patched or unexposed NextChat would have closed the August door, though not the October one.
• Platform-held cloud keys can buy AI too. The Bedrock attempts with Zeabur's own AWS keys show attackers now test stolen cloud credentials for model access as a matter of course. Zeabur's calls failed; Zeabur does not say why. Our assessment: in a cloud account where the stolen key's permissions do allow model calls, the bill lands on the victim.

What remains unclear

• How the October credentials leaked. Zeabur lists four unconfirmed hypotheses; the configuration-repository route via the August GitHub App key is the leading one. The September report does not mention the GitHub App key at all — it surfaced only in October.
• Who signed in to about 98 GCP servers on September 1–5, with the root password, before the October attack. Zeabur says it found the passwords on September 3 and did not fix them.
• Downstream abuse. Zeabur offers one hypothesised case (1,107 OpenAI image requests). It has not said how many customer AI keys were used, nor whether any provider (OpenAI, Anthropic, Google, AWS) revoked keys in bulk.
• Unverifiable access. Whether user database backups in two regions were downloaded, and how 359 Hetzner and 48 DigitalOcean servers were used, "cannot be confirmed".
• Final numbers. The October report is labelled preliminary and promises updates; the August report gave no counts at all.
• NextChat's fix. OSV lists versions up to 2.16.1 as affected but names no fixed version; anyone running NextChat should check the project's releases directly.
• Data deletion and support end dates are still "to be announced".

Lessons and what to do

If you used Zeabur: follow its list without waiting. Replace every credential that ever lived in a Zeabur environment variable — revoke at the provider first, then rotate. Replace n8n encryption keys and recreate all n8n credentials. Revoke upstream AI keys behind any new-api/one-api instance. Treat GCP dedicated servers as compromised and rebuild them. Check GitHub audit logs for Zeabur GitHub App activity on October 15, 15:05–18:54 UTC, and review bills from October 14 (from September 1 for GCP dedicated-server users). Start migration now; renewals end December 1.

Security teams, for any PaaS or internal platform:

• Inventory AI keys as tier-one secrets, alongside cloud root credentials. Give each app its own key, set per-key spending caps and alerts at the provider, and treat a usage spike as an intrusion alarm — in both Zeabur incidents, abuse of customer keys was the first signal.
• Do not let AI middleware (key relays, n8n, agent frameworks) store its master encryption key next to the data it encrypts. Use a secrets manager or a separate key store.
• After an incident, rotate everything the attacker could have read, not only what you proved they read. Re-verify any public "all keys rotated" statement against an inventory before you publish it.
• No credential without an expiry; no admin interface on the public internet; no secrets in backups whose key sits beside them.
• Alert on the moves seen here: admin tokens used from new addresses, commands run inside customer containers, new nodes joining the internal network.

AI builders: keep MCP and other tool-registration endpoints behind authentication and off the internet by default, and document what an unauthenticated "add tool" call can do.

Leadership: a platform's survival can hinge on one un-rotated token. If you depend on a small hosting provider for AI workloads, ask how it stores customer secrets, how it rotates its own, and whether it can show you its last incident report.

Sources

• Zeabur — "October 2026 security incident (preliminary report)", Yuanlin Lin, October 19, 2026
• Zeabur — "August 2026 security incident", Yuanlin Lin, September 7, 2026
• Zeabur — "Zeabur is shutting down", Yuanlin Lin, October 17, 2026
• OSV — CVE-2026-7644 (NextChat addMcpServer improper authorization)
• Wiz Research — "Black October" for AI Developer Platforms, October 30, 2026

Coverage:

• BleepingComputer — "Zeabur shutting down after second security breach in two months", Bill Toulas, October 20, 2026
• SC Media — "Zeabur to shut down following major security breach", October 21, 2026
• Is Ray, Not Array — "Zeabur Is Shutting Down: A Taiwanese Startup's Growing Pains", October 18, 2026 (an early user's account)