Zeabur Said Every Admin Key Was Rotated. Weeks Later, the Ones It Missed Read 3.2 Million Secrets

Every vendor risk programme eventually rests on a sentence a supplier writes after something goes wrong. When a hosting provider tells customers that an incident is contained and its keys are rotated, those customers decide what to rotate themselves, what to migrate and whether to stay. Zeabur, a cloud deployment platform, has now published the clearest case yet of what happens when that sentence is wrong. Its October incident report states that the August report's claim that "all internal admin keys have been disabled or rotated" was incomplete, and that the keys it missed were the ones used to read every secret on its shared cluster.

The First Breach Started in a Customer's App

Zeabur's August incident report traces the first intrusion to August 27. The attacker exploited CVE-2026-7644, an authorization flaw in the MCP functionality of NextChat v2.16.1, in a service one customer had deployed publicly on a shared cluster. That gave code execution inside the container and a view of the cluster's internal network. From there the attacker found a routing cache holding legacy API keys, batch-tested them until one belonged to a team administrator, and used it to read an internal management service whose environment variables contained AWS keys, including a long-retained root key. A cleanup job with an over-permissioned database credential then provided a path to the production database.

The response list in that report is long and specific: legacy API key authentication disabled, cluster permissions removed, hosts replaced, new alerting. It also states that all internal admin keys, database passwords and cache passwords had been disabled or rotated. Customers reading it had good reason to believe the platform itself was clean, and their job was to replace the third-party credentials named in their notices.

What the Rotation Missed

The October incident report, published as a preliminary account on October 19, explains why that was not true. The August rotation covered only keys confirmed leaked at the time. It did not cover the shared cluster admin tokens or the AWS keys stored in plaintext in a private configuration repository. One of those tokens had been created on January 10, 2024 with no expiry, and was written into the repository on January 20, 2026. Root passwords for GCP servers were found in plaintext initialization settings on September 3 and were not fixed. A secrets migration that started on October 3 had not been merged when the attacker returned.

The timeline from there is short. The first use of a Zeabur AWS key came at 01:36 UTC on October 14, and the first shared cluster access with an admin token four minutes later. By 12:39 the settings and secrets of every service on the shared cluster had been read. Zeabur's investigation began at 13:56 the next day, after a user report, roughly 36 hours after that first key was used. The report counts 3,218,965 environment variable records and 321,810 accounts read from the platform database, commands run inside 865 hosted database services across nine regions, root sign-ins on 101 GCP dedicated servers belonging to 92 users, SSH keys added to 50 of them and 16 customer disk copies attached to other machines.

Zeabur is careful to label the link between the two incidents as a hypothesis: the August GitHub App key may have exposed the configuration repository, but the evidence is indirect and the attacker IP addresses do not overlap. As BleepingComputer reported, the platform's administrator portals were also reachable from the public internet, and Zeabur's own root cause statement is that the long-lived credentials "could be used from the public internet."

Why This Lands on the Customer's Risk Register

The exposure was not limited to Zeabur's own data. Of the 865 database services the attacker touched, 736 were n8n workflow instances, and 602 of the 607 n8n deployments Zeabur checked kept their encryption key in an environment variable, so the credentials those workflows store for other systems are exposed too. Zeabur's shutdown announcement ties its growth to deployment demand "from n8n and OpenClaw to vibe coding", which describes exactly the kind of fast-built, credential-heavy workloads that tend to land on platforms like this one outside formal procurement. Renewals stop on December 1 and every shared cluster and dedicated server stops by December 31.

The remediation burden sits with customers. Zeabur tells all users to replace every password and key stored on the platform, even ones already replaced after August. eSecurityPlanet's customer guidance spells out the trap: changing a database password in an environment variable does not change it inside the database, and a password change does not remove an attacker's SSH key. Rotation has to happen at the issuing provider, and persistence has to be hunted for separately.

• Treat a supplier's incident report as a claim, not evidence. Zeabur's own words show "all keys rotated" can mean "all keys we knew were leaked". Ask what was in scope, and how the vendor decided what was out of it.
• Rotate your own secrets after any platform breach, whatever the notice says. Zeabur now tells customers to replace keys they already replaced after August, because shared cluster services did not move off the platform database automatically after August, so many replacements sat in the same store that was read in October.
• Ask suppliers about credential lifetime. A cluster admin token with no expiry, created in January 2024, sat behind this breach. Token age and storage belong in due diligence questions alongside certifications.
• Inventory where shadow deployments live. n8n instances and AI-built apps on developer-chosen platforms hold real production credentials, and they rarely appear in a vendor register.
• Rotate at the source and check for persistence. Revoke keys with the issuing provider, change passwords inside databases, and review authorized SSH keys, cron jobs and service accounts before calling a host clean.
• Plan exits before a supplier forces one. Zeabur's customers have until December 31 to migrate, with the data deletion date still unannounced. A tested export path turns a forced move into a routine one.

Zeabur's October report is unusually candid, down to the minute-by-minute timeline and the admission about its own August statement. That candour is useful precisely because it shows how much a customer could not have known from the first report. A breach notice tells you what a supplier found. It cannot tell you what the supplier did not look for.