Zeabur's October 2026 Security Incident Explained: Plaintext Admin Tokens

One leaked token opens everything it was ever allowed to touch, for as long as it lives. In the Zeabur security incident, leaked admin tokens and cloud keys reached a shared cluster, 101 rented servers and the platform database.

An admin token may do almost anything on the system it belongs to. If it never expires and sits in a readable file, anyone who copies that file gets the same power, months later.

Zeabur's own report, published on 19 October 2026, says this is what happened. Its shared-cluster admin token was created in January 2024 with no expiry. In January 2026 it was written in plaintext to a private configuration repository.

Picture a common setup. A small team runs a food-ordering app on Zeabur's shared cluster: a web service, a worker and a PostgreSQL database. The setup is made up, but each of its secrets sits where the report says data was read.

Its environment variables hold the database password, a payment gateway key, an SMS key and an AI API key. The app also issues API tokens to partner restaurants and stores them in that database.

This guide follows the team through three jobs. It replaces what leaked, moves off Zeabur before the dated deadlines, and fixes its own token handling so the same mistake is far less likely in its code.

• Environment variable: a named setting, such as DATABASE_URL, that a platform hands to your app when it starts. Apps keep keys and passwords here.
• Credential: anything that proves who you are to a system, such as a password, an API key, a token or a private key.
• Plaintext: stored exactly as written, so anyone who can read the file can use the secret.
• Hash: a one-way fingerprint of a value. You can check a value against it, but you cannot turn it back into the value.
• Expiry and rotation: expiry means a credential stops working on a set date. Rotation means issuing a new one, switching apps to it and switching the old one off.
• Shared cluster: Zeabur's glossary calls it a Kubernetes cluster where services from many users run together. Kubernetes runs a group of machines as one.
• Dedicated Server: in Zeabur's glossary, a server managed by Zeabur that runs services for a single user only.
• Blast radius: everything one leaked credential can reach.

An attacker used Zeabur's own admin tokens and AWS keys, access keys for Amazon's cloud, to enter its shared cluster on 14 October 2026. They then reached internal systems and Dedicated Servers that Zeabur ran on GCP, Google's cloud.

On 15 October they joined one of those servers to Zeabur's private network as a new node, a machine on that network. They read the platform database from it.

Zeabur started investigating on 15 October at 13:56 UTC, after a user report. That was about 36 hours after the first known admin-token use. The report says more than 16 hours of attack activity on 14 October triggered no alerts.

Read the diagram as two paths. Path A started with the repository's cluster tokens and AWS keys. Zeabur assesses that a key found in an old cluster backup then opened its secrets manager, a vault for production keys.

Path B used an old GCP service account key, a key for a program rather than a person. Zeabur assesses it was used to read root passwords from server setup settings, giving root sign-ins on 101 servers.

Zeabur is still tracing where that old key leaked from, as of 23 October 2026.

The table below lists what the report says was reached. Statuses matter here, because the report separates what it confirmed from what it only assessed.

One row has two answers. The data table says it cannot confirm whether the Taipei and Hong Kong backups were downloaded. The timeline says the attacker downloaded user database backups at 15:42. Zeabur tells users to treat that backup data as leaked, which is the safe reading.

Zeabur names itself. The report says "long-lived admin credentials were stored in plaintext and could be used from the public internet." Three failures had to meet for that to work.

• No expiry: the admin tokens had not been rotated since they were created in January 2024.
• Plaintext storage: the tokens and several AWS keys sat readable in a private Zeabur configuration repository.
• Public reach: the shared cluster's admin interface accepted them from the internet. Zeabur restricted it to its own systems during the incident.

Why the August rotation missed these tokens

In late August 2026, Zeabur had a separate break-in. Its 7 September report says it began with a flaw, CVE-2026-7644, in one user's NextChat app running on the shared cluster.

That report said Zeabur had "disabled or rotated every internal administrative key, database password, and cache password", and switched off Legacy API Key authentication. The October report corrects this. It says the August rotation did not cover the cluster admin tokens and AWS keys in the configuration repository.

The report does not say how the August list was built. A secrets migration started on 3 October had also not been merged when the attack began.

How the attacker got the tokens is unconfirmed

As of 23 October 2026, Zeabur says it cannot confirm how the attacker obtained the credentials. Its leading hypothesis links them to the GitHub App private key from the August incident, and it calls this unproven.

The report also lists unexplained repository downloads on 30 August and 2 September, made with an employee's GitHub authorisation. It says these cannot be ruled out as a separate way the credentials were obtained. Be wary of any article that states the entry point as fact.

Replace every password and key you ever stored on Zeabur, then check for anything the attacker left behind. The report asks this even for keys you already replaced after the August incident.

1. 1

   Replace every stored secret

   At each provider, revoke the old key or password first, then create a new one and redeploy. That is the report's order, so expect a short outage. Include keys you replaced in August.

2. 2

   Recreate Zeabur tokens and zSend keys

   Zeabur revoked all 11,536 platform access tokens and all 566 zSend keys, which it had stored in plaintext. Any script still using an old one already fails.

3. 3

   Check GitHub for the Zeabur App

   Look in your GitHub audit log for Zeabur GitHub App actions from 15:05 to 18:54 UTC on 15 October. That is 20:35 IST on 15 October to 00:24 IST on 16 October.

4. 4

   Change passwords inside databases

   Shared-cluster users must change each password inside the database, not just the variable. In PostgreSQL, look for roles, functions, triggers, jobs or extensions you did not create.

5. 5

   Replace app-specific keys

   Shared-cluster users of n8n, a workflow tool, replace its encryption key and recreate its credentials. Revoke AI keys passed through new-api or one-api gateways. Treat Taipei and Hong Kong backups as leaked.

6. 6

   Rebuild GCP Dedicated Servers

   Treat the server as compromised and rebuild it if you can. In /root/.ssh/authorized_keys, remove SSH login keys commented @zeabur-pentest or that you do not recognise. Check the google-sudoers group, system accounts, crontab, systemd services and k3s workloads. Change the root password, disable SSH password login and replace every credential on the server.

7. 7

   Check other providers and bills

   Hetzner and DigitalOcean users should look for password resets or reinstalls after 14 October. Review usage from 14 October 2026, or from 1 September for GCP Dedicated Servers.

The 1 September date has its own reason. The report says an unknown source signed in to the same GCP servers with the root password between 1 and 5 September. It cannot yet say whether that was the same attacker.

For the team in our setup, that means a new database password, new payment, SMS and AI keys, and a check of the PostgreSQL roles. Its partner tokens sit in that database, so it reissues them too. The report tells shared-cluster users to revoke and regenerate any tokens, sessions or password hashes their own databases store.

Projects that moved their variables to their own Dedicated Server after August sit outside the platform database read, the report says. It adds that this does not rule out leaks from a compromised host, so rotate anyway.

Pick a new home, copy your data and secrets there, test it, then switch your domain. Finish before your own deadline: 1 December 2026 for shared-cluster services, or your server's expiry date for Dedicated Servers.

Counted from 23 October 2026, that leaves 39 days to 1 December and 69 days to 31 December. Zeabur's migration guide says to plan around your own expiry date rather than the last day.

What the migration guide says breaks

• Images: Zeabur keeps built images in its own registry, so pulls fail after shutdown. Keep a Dockerfile or use your new platform's build feature.
• Domains: every name ending in zeabur.app stops working. You need your own domain and permission to change its DNS records.
• Variables: Zeabur passes variables between services in a project, so copy the real values. The guide calls missing variables a common failure that breaks database connections.
• Databases: Zeabur's daily backups disappear too. Export your data yourself, then restore that export once in the new place as a dry run.

The guide's cutover order is to suspend the apps on Zeabur, sync data one last time, then change DNS yourself. It does not pick a destination; it weighs managed platforms, self-hosted platforms, k3s (a small Kubernetes) and plain Docker Compose.

Whichever you pick, ask how it stores environment variables and how quickly you could rotate them all. The guide is written so a coding assistant can follow it, and it warns never to paste your access token into a chat.

Rotation and migration are separate jobs. Rotate first, because every leaked value keeps working for the attacker until you switch it off.

A stolen hash cannot be used as the token, so a database leak does not hand over working keys. Zeabur's own report shows it: its 11,536 platform access tokens were stored only as hashes.

The report uses that fact to rule them out as the source of the attacker's impersonation, which began at 16:12 UTC. Its assessment is that the attacker forged login credentials with the login signing key instead.

The same table shows the other way. Zeabur stored its 566 zSend API keys, keys customers send to its email API, in plaintext. Those were confirmed read, and all had to be revoked.

Think of a hotel that keeps the locks and lets guests keep the keys. The desk can test any key in its lock, but someone who steals a lock still has no key. Here the key is the token and the lock is its hash.

Where the picture breaks: a locksmith can study a lock and cut a key. A hash of a long random token gives no such shortcut, but a hash of a short password can be cracked by fast guessing.

The code below issues one partner token for the team's app and stores it both ways. Pause and predict: an attacker copies both tables and presents each stored value as a token. Which one gets in?

import hashlib
import hmac
import secrets

# The pepper is a server-side key kept OUTSIDE the database (e.g. in a secret manager).
# Demo only: real code loads one fixed pepper, or every stored hash stops matching.
PEPPER = secrets.token_bytes(32)


def token_hash(token: str) -> str:
    return hmac.new(PEPPER, token.encode(), hashlib.sha256).hexdigest()


# Issue: show the token to the partner once, store only its hash.
token = "demo_" + secrets.token_urlsafe(32)          # 32 random bytes
plaintext_table = {"partner_7": token}              # the risky way
hashed_table = {"partner_7": token_hash(token)}     # the safer way


def is_valid(partner: str, presented: str) -> bool:
    return hmac.compare_digest(token_hash(presented), hashed_table[partner])


# An attacker copies both tables and tries each stolen value as a token.
print("stolen plaintext works:", is_valid("partner_7", plaintext_table["partner_7"]))
print("stolen hash works:     ", is_valid("partner_7", hashed_table["partner_7"]))
print("stored hash length:    ", len(hashed_table["partner_7"]), "hex characters")

Run it with Python 3.13 and it prints True, then False, then 64 hex characters. The stolen plaintext works as a token. The stolen hash does not, because the check hashes it again.

• secrets.token_urlsafe(32) draws 32 random bytes, which is 256 bits. Python's docs say that was believed sufficient for typical use as of 2015.
• hmac.new builds an HMAC, a hash that mixes in a secret key. Here that key is the pepper, kept outside the database, so someone holding only the table cannot test guesses offline.
• hmac.compare_digest avoids the content-based shortcut of ==, which Python's docs say helps resist timing attacks.

Why a fast hash suits tokens but not passwords

Guessing one 256-bit random value is far beyond any attacker, so a fast hash like SHA-256 is enough for tokens. Passwords are short and human, so guesses succeed. OWASP says fast hashes such as SHA-256 are not suitable for passwords.

For passwords, OWASP's Password Storage Cheat Sheet recommends Argon2id first, scrypt if it is missing, bcrypt for older systems and PBKDF2 where FIPS-140 rules apply.

Which credentials you cannot hash

Hashing protects credentials you check. A credential you must send has to exist in usable form, so a hash cannot replace it. Zeabur's admin tokens were this kind: a program presented them to the cluster.

The same goes for your app's payment key or database password. For these, the defences are short lifetimes, a secret manager instead of a repository, and network rules so a stolen copy fails from the internet.

Give every credential an end date, and rotate from one list that covers every type. Zeabur's admin tokens had no end date and were not on the list its August rotation used.

Expiry turns a leak into a time-limited problem. A token that died after ten minutes is worthless in a repository copied months later.

Short-lived tokens in Kubernetes

If your cluster runs Kubernetes, ask for a short-lived token per job: kubectl create token deployer --duration 10m. The kubectl reference says the server may return a longer or shorter lifetime than you asked for.

Kubernetes docs say tokens kept in Secrets "don't expire and don't rotate". They call that method not recommended. Zeabur's report does not say which kind of token its admin token was.

Rotation must reach backups and history

Rotation is a loop, and it includes every copy of a secret. Zeabur's daily cluster backups stored all secrets, and the backup access key sat beside other secrets.

The report adds that some credentials rotated during the incident were also captured by later backups. A rotation that leaves an old or new value in a readable backup has not finished.

List every credential with its type, where it is stored, when it was made, when it expires and which service owns it. Then let a script flag the risky rows every week.

Once the team leaves Zeabur and runs its own small cluster, it holds the same kinds of credentials a platform does. The rows below are made up, modelled on the types in Zeabur's report. The 90-day limit is an example policy, not a standard.

from datetime import date

TODAY = date(2026, 10, 23)
MAX_AGE_DAYS = 90

# One row per credential, of EVERY type. Made-up example data.
inventory = [
    {"name": "cluster-admin", "type": "cluster token", "stored_in": "config repo",
     "created": date(2024, 1, 10), "expires": None, "owner": "deployer", "owner_live": True},
    {"name": "backup-bucket", "type": "cloud key", "stored_in": "config repo",
     "created": date(2025, 6, 2), "expires": None, "owner": "backups", "owner_live": True},
    {"name": "old-docs-deploy", "type": "deploy key", "stored_in": "secret manager",
     "created": date(2025, 3, 1), "expires": None, "owner": "docs-site", "owner_live": False},
    {"name": "payments-api", "type": "api key", "stored_in": "secret manager",
     "created": date(2026, 9, 1), "expires": date(2026, 12, 1), "owner": "checkout", "owner_live": True},
    {"name": "orders-db", "type": "db password", "stored_in": "secret manager",
     "created": date(2026, 8, 29), "expires": date(2026, 11, 27), "owner": "orders", "owner_live": True},
]


def problems(c):
    found = []
    if c["expires"] is None:
        found.append("never expires")
    elif c["expires"] < TODAY:
        found.append("expired but still listed")
    age = (TODAY - c["created"]).days
    if age > MAX_AGE_DAYS:
        found.append(f"{age} days old")
    if not c["owner_live"]:
        found.append("owner service retired")
    if c["stored_in"] == "config repo":
        found.append("plaintext in a repo")
    return found


for c in inventory:
    issues = problems(c)
    print(("FIX " if issues else "ok  ") + c["name"].ljust(16), c["type"].ljust(13), "; ".join(issues))

# A rotation run that picked credentials by type, not from the inventory:
rotated = {c["name"] for c in inventory if c["type"] in {"api key", "db password"}}
missed = [c["name"] for c in inventory if c["name"] not in rotated]
print("rotation missed:", missed)

FIX cluster-admin    cluster token never expires; 1017 days old; plaintext in a repo
FIX backup-bucket    cloud key     never expires; 508 days old; plaintext in a repo
FIX old-docs-deploy  deploy key    never expires; 601 days old; owner service retired
ok  payments-api     api key       
ok  orders-db        db password   
rotation missed: ['cluster-admin', 'backup-bucket', 'old-docs-deploy']

On Python 3.13 the script marks three rows FIX, with ages counted to 23 October 2026. The rotation line misses exactly those three, because it chose credentials by type instead of reading the list.

Scan the repository, then its history

A scanner finds secrets in your files, but only in the files you point it at. We tested detect-secrets 1.5.0 on a small repo holding a fake cluster token and a sample AWS key.

pip install detect-secrets==1.5.0
detect-secrets scan > baseline.json   # scans git-tracked files only
detect-secrets scan --all-files       # also scans untracked files

# A secret deleted from a file can still sit in history:
git log -p --all -S admin_token

The scan reported an AWS Access Key in one file and a Hex High Entropy String in the other. After a commit deleted the token line, the scan no longer reported it, but git log -p still printed it.

By default the scan also skipped an untracked file holding a secret, and --all-files found it. So treat any secret that was ever committed as leaked, and rotate it rather than deleting the line.

Ask your cloud for its own list

On AWS, the IAM credential report lists each user's access keys with when they were last rotated and last used. Create it with aws iam generate-credential-report, then download it with aws iam get-credential-report.

AWS's docs say it covers only the first two access keys per user, and you can generate a new one at most every four hours.

Because many parts trusted more than they needed to. The report's "why it happened" section lists permissions and layouts that let a handful of keys reach almost everything.

• Internal and user services ran on the same cluster, so reading user settings also exposed internal credentials.
• Network rules let any node with the right tag reach the platform database.
• The internal read-only database account could read all data.
• The default service account on GCP servers had project-level write permissions.
• Root passwords in GCP initialisation settings were found on 3 September and not fixed before the incident.

Detection lagged too. The report says storage, GCP and GitHub logs are incomplete. As of 23 October, alerts for unusual admin access, bulk reads, new internal nodes and cloud keys used from unfamiliar sources are still in progress.

For the team in our setup, the lesson is small and concrete. Give the worker a database user that can touch only its tables, and alert when a partner token suddenly reads every order.

Tell it as a story about credential lifecycles and blast radius, not about one attacker. The steps below give you the frame.

1. 1

   State the root cause

   Long-lived admin tokens stored in plaintext in a config repo, usable from the internet, never rotated since January 2024.

2. 2

   Separate known from unknown

   The way in is unconfirmed, per Zeabur's 19 October report. Say so instead of guessing.

3. 3

   Draw the blast radius

   Repository tokens and keys reached a shared cluster in 9 regions and the secrets manager. An old GCP key reached 101 servers. An added network node reached the platform database.

4. 4

   Fix it in layers

   Hash tokens you receive. Make tokens you send short-lived. Rotate from an inventory that includes backups. Block admin interfaces from the internet.

5. 5

   Add detection

   Alert on admin access from new places, bulk reads and new network nodes. More than 16 hours of attack activity on 14 October raised no alert.