Zeabur's Unrotated Administrator Credentials Triggered the Breach That Shut the Company Down

Zeabur is shutting down entirely by December 31, 2026, after unrotated administrator credentials from an August breach let a second attacker walk back in through the same front door in October. Per the company's own incident report, the attacker used admin tokens created in January 2024 with no expiration date, stored in plaintext, that were never included in the credential rotation Zeabur ran after its first breach just seven weeks earlier.

Jump to what we checked in our own rotation process if your incident response plan has ever included the phrase "rotate all credentials."

How a Breach in August Set Up the Breach in October

The August 2026 intrusion started with a vulnerability in a customer's public-facing NextChat deployment, which the attacker used to pivot into Zeabur's internal network and read a cached legacy API key belonging an administrator. That key had no permission scopes and no expiration, and it led the attacker to AWS root credentials and, from there, the production database. Zeabur's response disabled legacy API keys and rotated what it described as every internal administrative credential.

It had not. The cluster admin tokens the October attacker used, per Zeabur's own report, had been created in January 2024, sat unencrypted in a private configuration repository, and were simply not included in the post-August rotation. Separately, root passwords for Zeabur's GCP-managed dedicated servers had been stored in plaintext in server initialization settings since before the attack, a problem Zeabur's own team found on September 3 and had not fixed by the time the second attacker arrived.

What the October Attacker Actually Did

Zeabur's own timeline is specific down to the minute. The attacker first used a stolen AWS key at 01:36 UTC on October 14, then a shared-cluster admin token four minutes later. By 12:39 they were reading the settings and secrets of every service on the shared cluster. An hour later, at 13:40, they began both reading database containers and signing in as root to GCP dedicated servers.

The attacker's last database command landed at 17:04 on October 14. Zeabur did not start investigating until 13:56 the next day, after a user reported something wrong, more than 20 hours after the first unauthorized access.

By the time Zeabur fully contained the intrusion, the attacker had signed in as root to 101 dedicated servers across 92 customer accounts. They added SSH keys to 50 of those servers for persistence.

The attacker also attached 16 customers' disk volumes directly to virtual machines they controlled. The confirmed database exposure totals 3,218,965 environment variable records and account data for 321,810 users.

What We Checked in Our Own Rotation Process

We pulled every credential rotation runbook at Krova Cloud and checked each one for a hard-coded list of what gets rotated, the exact failure mode in Zeabur's case: a rotation that only touches the credentials someone remembered to list.

We replaced two of our runbooks with a rotation step that queries our secrets manager for every active credential by type, rather than rotating from a static checklist. A credential nobody remembers to name still gets rotated this way.

What to Check If You Used Zeabur

• Rotate every credential ever stored in a Zeabur environment variable, including ones you already rotated after the August incident, since the October exposure is a separate database read.
• If you run a Zeabur GCP dedicated server, change the root password and remove any SSH key you don't recognize, particularly one reported under the name zeabur-pentest.
• Treat any variables you migrated to your own server after August as still worth re-checking, since a compromised host could expose them even though they weren't part of this database read.
• If your own incident response plan has ever used the word "rotated" without naming exactly which systems were checked, assume it missed something, because that is precisely the gap that caused this company's second breach.

The honest limitation in Zeabur's own account is that it still doesn't know how the attacker first obtained the plaintext tokens. The company's working theory, which it labels unconfirmed, is that a GitHub App private key leaked in August gave the attacker read access to the configuration repository where the tokens sat.

The verdict doesn't depend on resolving that gap. Those tokens existed in plaintext with no expiration for nearly two years, and nobody's checklist caught that during the first incident response, which is the part of this story that was always inside Zeabur's control.

The Rule

A credential rotation that works from a list of "things we think we need to rotate" will always miss the credential nobody remembered existed. Zeabur's root cause isn't that administrators reused a password or clicked a phishing link. It's that an old, unscoped, never-expiring token sat in a config file through one full incident response and came back to end the company. If your own rotation process can't answer "which credentials did we check" with a system-generated list instead of a person's memory, you have the same gap.

Frequently Asked Questions

Why is Zeabur shutting down?

Zeabur suffered a second security breach in two months, on October 14-15, 2026, after administrator credentials from an August breach were never fully rotated. The company announced it will wind down services starting December 1, 2026, with full shutdown by December 31.

What data was exposed in the October breach?

Zeabur confirmed 3,218,965 environment variable records and account data for 321,810 users were read from its production database. Attackers also signed in as root to 101 GCP dedicated servers across 92 accounts and attached 16 customer disk volumes to their own virtual machines.

Why didn't the August credential rotation prevent the October breach?

The admin tokens used in October were created in January 2024 with no expiration date, stored in plaintext in a private configuration repository, and were not included in the rotation Zeabur performed after the August incident.

What should Zeabur customers do now?

Rotate every credential ever stored in a Zeabur environment variable, even ones already rotated after August, change root passwords and remove unrecognized SSH keys on any GCP dedicated server, and begin migrating workloads before the December 31, 2026 shutdown.

I'm Rohit, founder of Krova Cloud: disposable VMs where a credential rotation means the VM is gone, not a checklist someone has to remember to finish. More debugging stories at debugly.dev.