Zeabur Says an Attacker Read Platform Env Vars and Accounts

Zeabur says an attacker broke into its shared cluster and GCP dedicated servers in mid-October and read the environment variables stored in its platform database, including secrets many customers still keep on the host. Anyone with apps, databases or AI keys on Zeabur’s shared platform needs to treat those credentials as compromised and rotate them again, even if they already did so after the company’s August incident.

In a preliminary incident report published on 19 October, the cloud platform said the intrusion ran on 14–15 October 2026 (UTC), that the attacker’s last recorded activity was at 21:05 on 15 October, and that the investigation is ongoing. Zeabur has separately said it will shut down by 31 December 2026 as an operational decision, while still handling support and compensation for this breach.

What Zeabur says was taken

Zeabur’s own “Confirmed” figures, from logs of the platform-database read between 16:10 and 16:47 on 15 October, are stark. The attacker pulled 3,218,965 service environment-variable records (names and values) and data on 321,810 accounts, including email, username and phone number. It also obtained 566 zSend API keys stored in plaintext, which Zeabur says it has revoked, and 11,536 platform Access Tokens that were stored only as irreversible hashes and have all been revoked.

On the shared cluster, Zeabur says the attacker ran read commands inside 865 database services. How much was actually copied from each database is only “Assessed,” because audit logs kept the commands, not their output. Sign-ins as root are confirmed on 101 GCP Dedicated Servers belonging to 92 users. Projects that, after August, moved their environment variables onto their own Dedicated Server were outside the scope of this platform-database read, Zeabur says — though compromised hosts still need fresh secrets.

How the company says it happened

“The root cause of this incident lies with Zeabur: long-lived admin credentials were stored in plaintext and could be used from the public internet,” the report states. Cluster admin tokens had no expiry and the admin interface was reachable from the open internet. An old GCP path let the attacker obtain root passwords from server initialisation settings that still held them in plaintext.

Two paths met inside Zeabur’s internal network. From a compromised GCP server, the attacker used internal-network admin credentials taken via the shared-cluster path, joined a node that the network rules allowed to reach the platform database, and read it with an internal read-only account. Zeabur says it has revoked the tokens, keys and nodes used in the attack, signed all users out, and revoked platform Access Tokens.

The company observes that the attacker was “mainly looking for API keys they could use directly, especially keys for AI services,” searching environment variables and reading credentials from n8n and new-api/one-api instances at scale. That is Zeabur’s reading of intent, not a claim about every record stolen.

What users are told to do — and what is still open

Zeabur’s advice is blunt: replace every password and key stored on Zeabur, even if those secrets were rotated after August. Revoke old keys with each provider first, then redeploy. Change passwords inside databases as well as environment variables on the platform. Users of the 101 GCP hosts were emailed and had root passwords reset; they are told to check for unfamiliar SSH keys and login paths.

How the attacker first obtained the plaintext AWS keys and cluster admin tokens “cannot be confirmed,” Zeabur writes. It hypothesises a link to the GitHub App private key leaked in August, and notes that “the rotation in August did not cover the credentials used this time.” Both that August link and a separate note that an OpenAI key was abused on 16 October are labelled hypotheses. The investigation continues, and Zeabur says it will keep updating the report and its status page through the wind-down to 31 December.

Our read

This is TSN’s analysis. A second breach in under two months, driven by plaintext admin credentials that survived the last rotation, is a hard lesson for any PaaS that still centralises customer secrets. Zeabur’s Confirmed counts give customers a clear trigger to rotate; its Hypotheses should stay labelled as such until the logs catch up — and migration plans now have a hard stop on New Year’s Eve.

Sources

• Zeabur: October 2026 security incident, 19 October 2026
• Zeabur: Zeabur is shutting down — what happens next, 17 October 2026

Related stories

• FirstVDS Says Hackers Used a VMmanager Flaw to Copy Customer Data
• Cairn AI Agents Used to Break Into 100+ Company Sites, Reuters Reports