Kelvin

Appearance

Language

· 8 min read

A deployment platform Taiwan's developers loved was breached twice in two months, then shut down (Part 1): from one NextChat bug to an AWS root key

Zeabur shut down after being breached twice in two months. Part 1 walks through the August attack: how a vulnerable NextChat app one user deployed led to an admin key, AWS root access and the production database.

On Oct 17, the news raced through Taiwan's developer circles on Threads and X. The engineer Huli summed it up (translated from Chinese): "Zeabur got hacked a second time, and now it's gone."

Zeabur's founder, Yuanlin Lin, announced on the company blog that the platform would wind down and stop all services on Dec 31. The first breach had happened less than two months earlier.

If you never used Zeabur, this sounds like one more startup closing its doors. But if you have ever pasted an API key into a deployment platform, this story is about you too. I'm telling it in two parts. This one covers what Zeabur is and how the first attacker got all the way in. Part 2 covers the second breach, the shutdown, and what engineers should take away from it.

What Zeabur is, and why its breach matters to you

Zeabur is a cloud deployment platform (a PaaS). Connect a GitHub repo and it builds and deploys your app, sets up your domain and HTTPS, and spins up a database in one click. The founder pitched it as "Vercel for the backend"; it started as his graduation project at Zhejiang University.

It was a common choice among developers in Taiwan: a Chinese-language interface, a Taipei region, and one-click templates for tools like n8n. According to Zeabur, it raised a US$2 million seed round in November 2025, when it had more than 5,000 individual paying customers. Some developers have also noticed that many AI coding courses end with a "now deploy it" step, and the platform in that step is often one like Zeabur.

You only need one concept to follow this story: environment variables (env vars). Your app needs passwords and API keys to reach its database or call OpenAI. Those shouldn't live in your code, so you paste them into the platform's env var settings instead. That's convenient, but it also means the platform is holding every key you own. When the platform is breached, the keys go with it. In both Zeabur breaches, that is exactly what the attacker came for.

The two breaches at a glance

  • First breach (Aug 27): The attacker got into the platform's internal network through a vulnerable NextChat instance one user had deployed, escalated to an admin key and AWS root access, and finally read project env vars from the production database. (This part.)
  • Second breach (Oct 14–16): The attacker used an admin token created in 2024 that had never expired or been rotated, reached the shared clusters straight from the internet, and walked away with 3,218,965 env vars and account data for 321,810 users. (Part 2.)

Zeabur's preliminary report on the October incident doesn't mince words:

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 first breach: four walls, breached one at a time

At about 10:30 on Aug 28 (Taipei time, UTC+8, for all times below), Zeabur got a report that a user's API key had been abused. Going back through the logs, the team found the attacker had been inside since the previous day, bulk-reading users' env vars from the database. Monitoring had caught nothing.

The twist: the entry point wasn't Zeabur's own code at all. It was an open-source chat UI that a user had deployed. Zeabur's report, published Sept 7, breaks the attack path into four boundaries:

  1. The application. A user was running NextChat v2.16.1 on a shared cluster. Its MCP feature had insufficient authorization checks (CVE-2026-7644), which let the attacker run code inside the container.
  2. The shared cluster's internal network. Projects could reach each other. The attacker connected to the cache that stored routing data, and that cache also held Zeabur Legacy API Keys. After testing them in bulk, the attacker found one that belonged to a team admin.
  3. The platform account and the cloud account. Legacy API Keys were early CLI keys with no scope and no expiry. With one, the attacker read the env vars of an internal management service, and they included an AWS root key.
  4. The core production environment. The production database had no public endpoint. But a scheduled cleanup job on the shared cluster could reach core systems over the private network, and its database account had more privileges than it needed. Once the attacker controlled the cluster, they had both.

Timeline (Taipei time):

  • Aug 27, 10:34: First anomalous API requests
  • Aug 27, 10:36: First use of the team admin's Legacy API Key
  • Aug 27, 13:39–13:45: Internal service config read; AWS root key obtained and used to sign in to AWS
  • Aug 27, 15:26: A service account in the Tokyo shared cluster granted cluster-admin
  • Aug 27, 15:54: Earliest intrusion record in the database; bulk reads start at 19:52
  • Aug 28, 10:34: First report of an abused API key
  • Aug 28, 16:53: First notification email (Zeabur later admitted it had misjudged the scope); a second email followed on Aug 29 at 01:03

What was read: the names and values of project env vars, including AI and third-party API keys, cloud credentials, database connection strings and passwords, and app signing keys, plus account and AI Hub data. The attacker also used admin rights to create AI Hub keys, but Zeabur found no usage and no charges from them.

What Zeabur admitted it got wrong

The NextChat bug was only the starting point. Zeabur's report says a platform that runs other people's code is responsible for limiting how much network, data, and privilege an attacker can reach once one user's service is compromised. Here, four things stacked up and made the damage far worse:

  • Platform credentials sat in the routing cache, where user services could reach them.
  • Legacy API Keys had no scope and no expiry.
  • Internal services held far more cloud privilege than they needed, up to AWS root.
  • One maintenance job had both cross-environment network access and an over-privileged database account.

One more detail: the shared clusters and Legacy API Keys were both being phased out at the time. Zeabur conceded that a system on its way out still needs isolation and access control until it is actually switched off. Plenty of teams have an old system nobody wants to touch because "it's going away soon". That lesson is worth writing down.

The fixes, and one claim that turned out to be incomplete

Afterwards, Zeabur disabled every Legacy API Key, cut the path from the shared clusters to the production database, separated routing data from user credentials, and added monitoring and alerting. It also shipped a new feature: projects on dedicated servers could keep their env vars on their own machines instead of in Zeabur's central database.

The August report also said every internal admin key had been disabled or rotated. After the second breach, Zeabur corrected itself in its October report: "The August incident report stated that 'all internal admin keys have been disabled or rotated.' That statement was incomplete, and we are correcting it here."

Still, that "keep your env vars on your own server" feature did save a group of users in October. More on that in Part 2.

If you used Zeabur, do these four things now

  1. Rotate every key and password you stored in Zeabur env vars, even if you already rotated them in August. Revoke the old one at the provider first, then create a new one.
  2. Start with anything that costs money: AI API keys, cloud accounts, payment keys. Then check your bills and set usage caps while you're at it.
  3. Start migrating. From Dec 1, shared cluster services are suspended and dedicated servers shut down when their term ends. On Dec 31, everything stops and the data is deleted.
  4. File refund and security-claim requests separately. Security claims close on Nov 30. For a balance refund, open a Zeabur Support ticket by Nov 30; after that, refund requests can only go by email.

Key takeaways from Part 1

  • Your platform's env var page is where you hand over every key you have.
  • On a multi-tenant platform, someone else's vulnerability can become yours. With weak isolation, one chatbot can be a path into the whole platform.
  • Keys with no scope and no expiry, plus over-privileged internal services, are what let the damage keep spreading.
  • The most dangerous system is the one "about to be retired": nobody wants to invest in it, but it's still wired into production.

Coming in Part 2: In the second breach, the attacker held an admin token created in January 2024 that never expired and was missed by the August rotation. No alert fired for about 36 hours, and the platform database was read in 37 minutes. Shortly afterwards, Zeabur announced it was shutting down. Part 2 covers how the second breach happened, the shutdown timeline, and six lessons for engineers.

Times of day are converted from the UTC times Zeabur published to Taipei time (UTC+8). Items with a date but no time keep the UTC date from Zeabur's reports. Article and announcement dates are the publication dates shown on the official sites.

Sources