Zeabur Shutdown and Environment Variables Breach: What Users Must Do

Zeabur, a cloud deployment platform, says an attacker read about 3.2 million environment variable records on 14 and 15 October 2026, its second breach since August. It is shutting down by 31 December. Every Zeabur user should revoke and replace each stored secret, back up their data, and move off the platform before 1 December.

Below: what Zeabur has published, what was exposed, an order for rotating secrets while migrating, and lessons for any team on a platform as a service (PaaS). Facts come from Zeabur's blog and status page, with press reporting labelled.

What happened

There are three linked events: an intrusion in late August, a larger one in mid October, and the shutdown notice on 17 October.

The August incident

Zeabur's final report on the August incident, published in September, describes a chain of five steps. According to Zeabur, it began with a NextChat service that one user had deployed on the shared cluster. That NextChat version (2.16.1) carries CVE-2026-7644, an authorization flaw in its MCP server feature, which gave the attacker code execution inside that container.

From there, Zeabur says, the attacker could reach a routing cache that also held Legacy API Keys. Those keys had no scopes and no expiry. One belonged to a team administrator, and it could read the environment variables of an internal service. Those variables held AWS access keys, including what Zeabur calls a "long-retained key for the AWS root user." With root access the attacker took control of the Tokyo shared cluster and used an over privileged maintenance job to read the production database, including project environment variables.

INSIDE, a Taiwanese tech outlet, reported on 29 August that Zeabur had directly observed abuse of API credentials for Anthropic, OpenAI and OpenRouter. Zeabur's status page notes that it could not verify a dark web screenshot that circulated at the time. The status page marked the incident resolved on 9 September.

The account changed as the investigation went on. The 29 August status update said the path began with a leaked internal AWS administrative credential; the final report traces it further back, to the NextChat container and the Legacy API Keys. We cite the final report.

The October incident

Zeabur published a preliminary report on 19 October. It describes a second intrusion that used leaked internal credentials to reach the shared cluster, some Google Cloud (GCP) Dedicated Servers and internal systems. Zeabur names the root cause plainly: "long-lived admin credentials were stored in plaintext and could be used from the public internet."

The shutdown

On 17 October Zeabur's founder posted "Zeabur is shutting down: what happens next." He gives three reasons: growth had stalled even as AI tools raised demand for deployment, the system built three and a half years ago had become hard to maintain, and the security incidents exposed weaknesses in security and operations.

INSIDE reported the same day that the news first reached users by email and that, when it checked, the blog and status page did not yet carry it. The blog post is now live and dated 17 October. The October incident report describes the shutdown as an operational decision; the shutdown post itself lists the incidents among its reasons. We report both as published.

What is still open

Zeabur says its October investigation continues. Open items include how the attacker first obtained the internal credentials (Zeabur has an unconfirmed hypothesis linking them to a GitHub App key exposed in August), how much backup and storage data was downloaded, and records it has requested from GitHub. Zeabur says it will keep updating the report and its status page.

What was exposed

The numbers below come from Zeabur's preliminary report. Where Zeabur says it cannot confirm something, we say so too.

Zeabur also lists what it believes was not affected. Projects that moved their environment variables and config files onto their own Dedicated Server after the August guidance were outside the platform database read, though Zeabur notes that does not clear a host that was itself compromised. Attempted calls to Amazon Bedrock with Zeabur's AWS keys failed with no charges, and Tencent Cloud shows no use of admin credentials.

Who is affected

How it works

Most PaaS products let you paste secrets into a settings page as environment variables, which the platform stores and hands to your container at start up. The platform's database becomes one store of many customers' database passwords, cloud keys and AI provider keys.

Two things turn that store into a target. First, the values are useful the moment they leave: an OpenAI or Anthropic key can be spent at once, which is why both the Zeabur and Railway disclosures mention AI keys. Second, the platform needs strong internal credentials to manage clusters and cloud accounts. If any of those are long lived, stored in plain text and usable from anywhere, one leak can open the store.

Zeabur's reports describe both conditions. Neither is unusual in a fast growing service. For a customer, the point is simple: a secret you hand to a platform is only as safe as the platform's least protected admin credential, which you cannot see from outside.

What to do now

Work through this in order. Zeabur's report has the full detail and its indicators of compromise.

1. Revoke first, then replace. Zeabur asks users to revoke old keys at each provider before anything else. Creating a new key does not disable the old one. For AWS:

   aws iam list-access-keys --user-name app-deployer
   aws iam create-access-key --user-name app-deployer
   aws iam update-access-key --user-name app-deployer \
     --access-key-id AKIAOLDKEYEXAMPLE --status Inactive
   # once the new key works everywhere
   aws iam delete-access-key --user-name app-deployer \
     --access-key-id AKIAOLDKEYEXAMPLE
   

   Do the same in the OpenAI, Anthropic, OpenRouter, Gemini, Stripe, Cloudflare and GitHub dashboards. Do not put the new values back into Zeabur if you are about to leave; see the next section.

2. List every variable name your code reads, so nothing is missed. Names only, never values:

   grep -rhoE 'process\.env\.[A-Z0-9_]+' src | sort -u
   grep -rhoE "os\.(environ|getenv)[^A-Z]*[A-Z0-9_]{3,}" . | sort -u
   

3. Change database passwords inside the database. Zeabur points out that editing an environment variable does not change the password the database accepts. For PostgreSQL:

   ALTER ROLE app_user WITH PASSWORD 'new-long-random-value';
   SELECT rolname, rolsuper, rolcanlogin FROM pg_roles ORDER BY 1;
   SELECT extname, extversion FROM pg_extension;
   SELECT tgname, tgrelid::regclass FROM pg_trigger WHERE NOT tgisinternal;
   SELECT n.nspname, p.proname FROM pg_proc p
     JOIN pg_namespace n ON n.oid = p.pronamespace
    WHERE n.nspname NOT IN ('pg_catalog', 'information_schema');
   

   Zeabur asks shared cluster users to look for roles, functions, triggers or extensions they did not create. Compare against a known good schema dump if you have one.

4. Rebuild n8n trust. Zeabur asks n8n users to replace the n8n encryption key and recreate every third party credential stored in n8n. Export your workflows first (n8n export:workflow --all --output=workflows.json), then recreate credentials by hand on the new instance rather than exporting the old ones.

5. Revoke upstream AI keys behind new-api or one-api. If you ran one of these gateways, the keys it forwards to are the ones to revoke.

6. Treat Dedicated Servers as compromised. On GCP, Zeabur says to back up data and rebuild where you can. Where you cannot, look for unknown keys, including any with the comment @zeabur-pentest, and for persistence:

   grep -Hn "" /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys
   last -F | head -50
   journalctl -u ssh -u sshd --since "2026-09-01" | grep -i accepted
   crontab -l; ls -la /etc/cron.d; systemctl list-timers --all
   

7. Check the GitHub App window. In your organisation or account security log, filter for Zeabur App events between 15:05 and 18:54 UTC on 15 October. On plans with the audit log API, gh api "/orgs/YOUR_ORG/audit-log?phrase=created:2026-10-15" gives the raw list.

8. Read the bills. Zeabur asks users to review provider bills from 14 October, or from 1 September for GCP users. For AWS keys, CloudTrail shows what an old key did:

   aws cloudtrail lookup-events \
     --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAOLDKEYEXAMPLE \
     --start-time 2026-10-14T00:00:00Z
   

9. Sign in again and recreate tokens. All sessions, Access Tokens and zSend keys were revoked.

10. Claim what you are owed. Balance refunds and incident compensation are separate requests through Zeabur Support. Zeabur says it checks provider usage records for compensation. Send masked identifiers only, never a live key.

Migrating off a platform that is shutting down

Rotation and migration overlap here, and the order matters. The goal is that no new secret ever touches the old platform.

1. Pick the destination and set it up first. Create the new projects, databases and secret store before you move traffic.

2. Issue new credentials straight into the new home. Generate each replacement key and paste it only into the destination. The old service keeps running on the old, now revoked or soon revoked key for as short a time as possible.

3. Back up and prove the backup. Zeabur's shutdown post asks users to verify backups and test services in the new environment. For PostgreSQL:

   pg_dump -Fc -d "$OLD_DATABASE_URL" -f app.dump
   pg_restore --list app.dump | head
   pg_restore -d "$NEW_DATABASE_URL" --no-owner app.dump
   

   Count rows in a few key tables on both sides. For volumes, copy files out with tar or rsync and check sizes and checksums.

4. Note that migrated secrets may not be in backups. Zeabur's September changelog says variables moved to a Dedicated Server live there as Kubernetes Secrets and may not be included in Zeabur's service or volume backups. Keep your own copy of the names and where each value now lives.

5. Lower DNS TTLs a day ahead, then cut over and watch error rates.

6. Transfer domains out. Zeabur says domains bought through it can be transferred from the Dashboard, and Support can help.

7. Do not wait for the deletion date. Shared cluster services pause on 1 December, and Dedicated Servers stop on their own expiry dates, which can be earlier than 31 December. Zeabur offers a migration guide, including a Markdown version written for coding agents.

Lessons for PaaS users

• Your secrets inherit your provider's weakest credential. Plan as if the platform's secret store could leak.
• Shared infrastructure means shared exposure. By Zeabur's account, the August chain started in another customer's container. On a shared cluster you depend on isolation between tenants.
• Act on the first incident. Teams that moved variables to their own servers after August were outside the October database read.
• Platforms close. A runbook for leaving, with backups you have restored once, is cheap to write early.

What would have helped

Practices any team can use

• Short lived credentials instead of static keys. Use workload identity or OIDC federation for cloud access, so a leaked variable expires in minutes. Our Railway post covers moving to short lived credentials.
• Scope and cap AI provider keys. One key per service, project level limits and a monthly budget alert. A stolen key then costs a bounded amount.
• Keep secrets in your own store. A secrets manager you control, with the platform holding only a reference or a short lived token, narrows what a platform breach can reveal.
• An inventory of which service holds which secret, and rotation scripts that change a database password in the database, then the variable, then redeploy.
• Restore tests. A backup is only real once you have restored it somewhere else.
• A vendor exit plan. For each platform, note where the data lives, how to export it and how long a move takes. Our post on third party risk after the IDCF Cloud ransomware attack covers the same idea for an infrastructure provider.

Where Safeguard fits

Safeguard would not have prevented or detected this incident. It has no view into Zeabur's systems, it does not hold your environment variables or provider keys, and nothing in it would have flagged this intrusion. Its part is narrower.

Knowing what you deploy. Zeabur's August report says the chain started with a known CVE in a deployed application. Safeguard builds SBOMs from repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output) and matches components against vulnerability databases, with reachability analysis to help prioritise. That helps you find known vulnerable components in your own services. It would not have protected one tenant from another tenant's application on a shared cluster.

Finding services that likely hold keys. The platform shows which projects contain a given component and version. Searching for the openai, @anthropic-ai/sdk, boto3, pg or stripe packages lists the services that probably hold matching keys, a quick cross check on your rotation inventory. Our post on SBOM incident response explains the method.

Gates during a rushed migration. Platform policies and gates can stop a hurried redeploy from shipping a known vulnerable dependency. They do not inspect secrets.

Approved changes through the CLI. The Safeguard CLI's assistant can edit code and run commands on your machine, asking first in the default flow (/permissions offers Ask, Accept edits, Plan, Auto and Strict). You can ask it to list every variable name a repository reads, replace a hard coded connection string with an environment variable, or update deployment config for a new host, then run your tests. The desktop and phone apps can send that work to a computer running the CLI and approve each command. In CI, safeguard exec runs the checks.

Zero-Day Discovery and Gold

These address a different problem. This incident is about credentials held by a hosting platform, not a vulnerable package in your software.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems. Findings are issued as SGZ advisories before they reach public CVE databases. It has nothing to say about how either Zeabur intrusion happened.
• Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action.
• Gold Registry at registry.safeguard.sh is paid: hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages. An artifact loses its badge if it regresses.

The shared habit is speed of rebuild. Teams that recover fastest from a platform breach, a compromised package or a forced move know what they run and can redeploy from patched, signed components on a new host quickly. For the wider month, see October 2026 security incidents and what would have helped.

Common mistakes

• Rotating in Zeabur instead of at the provider. The leaked value stays valid until the provider revokes it.
• Changing DATABASE_URL but not the database password. The old password still works until you run ALTER ROLE.
• Assuming August's rotation covers October. Zeabur asks users to replace every credential again, even if they rotated after August.
• Waiting for 31 December. Shared clusters pause on 1 December, and some Dedicated Servers expire sooner.
• Exporting n8n credentials to reuse them. Those values are the exposed ones. Recreate them.
• Skipping the restore test. A dump that has never been restored is a guess.

FAQ

Was my Zeabur project affected?

Zeabur asks every user to act as if their stored credentials are exposed. Shared cluster and GCP Dedicated Server users have extra steps. Neither Zeabur nor Railway has linked their incidents publicly, but the Railway environment variables breach rotation steps are similar.

How many records were exposed?

Zeabur's preliminary report gives 3,218,965 environment variable records and 321,810 account records read from the platform database, plus other systems listed above. The investigation is ongoing and figures may change.

I rotated everything after August. Do I need to do it again?

Yes. Zeabur's October report says to replace every password and key stored on Zeabur, even if you already replaced it after the August incident.

When does Zeabur shut down?

Shared cluster services pause on 1 December 2026, Dedicated Servers stop on their own expiry dates from 1 December, and everything stops by 31 December. The data deletion date and export deadline have not been announced.

Can I get money back?

Zeabur says balance refunds and incident compensation are separate requests through Zeabur Support. For extra charges on third party API keys or cloud accounts, it checks provider usage records and explains the result.

Were my passwords or two factor settings read?

Zeabur says account records such as email, username and phone were read. Two factor and passkey tables were counted but not read, according to the report.

Was the shutdown caused by the breach?

The founder's shutdown post lists the security incidents as one of three reasons, alongside slowing growth and a system that had become hard to maintain. The October incident report calls the shutdown an operational decision.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show the Zeabur incident. Each is a real Safeguard session, and the text says how the same flow applies to a migration like this one.

The first demo is a CLI session that fixes a lodash CVE: the assistant reads the finding, asks before each command, edits package.json, runs the install and tests with your approval, and pushes nothing. Leaving Zeabur, you would open the same session in each service's repository and ask it to list every environment variable the code reads and update the deployment config for the new host, then run the tests. It asks before each edit and command.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. During a migration, you can point the same flow at the repository for one service at a time and approve each change as it moves to the new platform.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. If a cutover runs late, the engineer on call can approve the restore and test commands from a phone, or deny one that looks wrong.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation. For a broader playbook, see our incident response playbook for a compromised dependency.

Quick check

Sources

• Zeabur: October 2026 security incident (preliminary report)
• Zeabur: August 2026 security incident report
• Zeabur: Zeabur is shutting down, what happens next
• Zeabur status: Unauthorized Access to Project Environment Variable Data
• Zeabur changelog: security update for Dedicated Servers
• INSIDE: Zeabur announces shutdown by 31 December (Chinese)
• INSIDE: Zeabur environment variable leak and stolen API keys (Chinese)
• Ray's blog: Zeabur shutting down, a Taiwanese startup's growing pains
• AlphaMatch: Zeabur environment variable leak and stolen API keys

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.