# Zeabur August 2026 security incident

> Investigation progress, confirmed impact, response measures, and security improvements.

**All event dates and times in this article are in Coordinated Universal Time (UTC).**

On August 27, 2026, an attacker gained unauthorized access to Zeabur systems. The attack began with a vulnerability in a user's publicly accessible service and escalated through four system boundaries, reaching the internal network of shared cluster, the platform accounts, the AWS account, and the production environment. We confirmed that part of the production database was read, including account information and project environment variables containing third-party API keys, database passwords, and other service credentials.

We apologize to every user affected by this incident. It revealed gaps in how we stored internal credentials and scoped the permissions, how we isolated shared cluster networks, and how we monitored and alerted on unusual access. Remediation and [platform upgrades](#product-and-security-improvements) have since been carried out.

<div id="confirmed-impact-scope" />

## Scope of impact confirmed

We cross-referenced platform request logs, production database query logs, AI Hub access-key, usage, and billing records to identify which accounts, projects, and services were queried or read. This defines the scope of impact we have confirmed to date.

### Project environment variables

Our investigation confirmed the unauthorized access to the names and values of project environment variables. The variables held API keys for AI and other third-party services, cloud access credentials, database connection details and passwords, application signing keys, and other project settings. We compared the affected projects and services against production database query logs to define the scope of this impact.

We have completed [our handling of internal platform credentials](#internal-credential-response). We also sent the first notice on August 28, 08:53 and the second notice at 17:03 the same day, asking the affected users to [replace all third-party credentials involved](#third-party-credential-response).

### Accounts and AI Hub

Platform request logs show that the attacker exploited the Zeabur Legacy API Keys they had obtained to query accounts and AI Hub information, and to create AI Hub access keys. After further checks on AI Hub usage and billing records, no AI Hub usage was identified for those keys, and no AI Hub charges were produced. We have [reviewed and revoked all of the keys created by the attacker](#ai-hub-response).

## What happened

The incident path we have confirmed traverses four system boundaries. The attacker first exploited a remote code execution (RCE) vulnerability in a public-facing service to gain access to the internal network of the shared cluster, then obtained a privileged Zeabur Legacy API Key from cache, with which they read the environment variables of an internal management service. An AWS root key among those variables allowed the attacker to access our cloud infrastructure at the highest privilege level. Using the shared cluster's existing private network connection and database credentials, the attacker then reached the production database.

<EscalationLadder
  title="Incident path"
  description="Dashed lines are the boundaries that existed between systems. Each arrow marks the access the attacker gained at that stage"
  entry={{
    title: 'Attacker on the public internet',
    detail: 'The starting point was a publicly accessible user service',
  }}
  crossings={[
    {
      boundary: 'Boundary 1  Application',
      reason:
        'CVE-2026-7644 in NextChat v2.16.1: insufficient authorization checks in its MCP functionality',
      zone: 'Shared cluster user namespace',
      gained: 'Code execution inside the container',
    },
    {
      boundary: 'Boundary 2  The shared cluster internal network',
      reason:
        'The shared cluster allowed cross-project internal connections, and the activity reached the routing cache over that network',
      zone: 'Zeabur platform',
      gained: 'A team administrator’s Legacy API Key',
    },
    {
      boundary: 'Boundary 3  Platform account and cloud account',
      reason:
        'The internal management service settings contained a long-lived AWS root key',
      zone: 'AWS account',
      gained: 'AWS root access and control of the Tokyo shared cluster',
    },
    {
      boundary: 'Boundary 4  Shared cluster and core production',
      reason:
        'An existing maintenance job had a private network connection to production and database credentials',
      zone: 'Core production',
      gained: 'Read access to the core production database',
    },
  ]}
  caption="Figure 1: The incident path we have confirmed, and the access the attacker gained at each stage"
/>

This path involved two legacy product mechanisms that were undergoing the retirement process prior to the incident: shared clusters and Zeabur Legacy API Keys. We [announced the shared cluster retirement plan](/changelogs/phasing-out-shared-cluster) in February 2026, disabled the creation of new projects in March, and disabled the creation of new services within existing projects in April. The service involved in this incident had been deployed before the service retirement announcement and was still running at the time.

### Stage one: entering the shared cluster's internal network through a public service

Our investigation confirmed that the attacker began with a [NextChat](https://github.com/ChatGPTNextWeb/NextChat) v2.16.1 service that a user had deployed to shared cluster. The service's runtime logs contained clear evidence of exploitation, pointing to [CVE-2026-7644](https://nvd.nist.gov/vuln/detail/CVE-2026-7644), which concerns authorization checks in its MCP functionality. Once code execution had been obtained in that service, the related activity could also connect over the shared cluster's internal network to internal endpoints the service could reach.

<NamespaceCrossing
  title="From a user service to the platform routing cache"
  description="After entering the shared cluster, the attacker used the internal network to connect to the cache that held routing information"
  clusterLabel="Tokyo shared cluster (hnd1)"
  left={{
    zone: 'user namespace',
    title: 'NextChat service v2.16.1',
    detail:
      'After CVE-2026-7644 was exploited, the attacker gained code execution inside the container',
  }}
  right={{
    zone: 'ingress namespace',
    title: 'Routing cache',
    detail:
      'Held ingress routing information, and also stored Zeabur Legacy API Keys',
  }}
  crossing={{
    label: 'Connected over the shared cluster internal network',
    note: 'The access controls in place at the time did not stop this connection',
  }}
  outbound={{
    label: 'Called with the administrator key that was obtained',
    zone: 'Platform control plane',
    title: 'Zeabur API',
    detail:
      'Request logs show this identity being used to query accounts, AI Hub, and project and service settings',
  }}
  caption="Figure 2: After entering the shared cluster through NextChat, the attacker obtained Legacy API Keys from the routing cache over the internal network"
/>

The cache was originally designed to hold the mapping between domains and services, and it also stored Zeabur Legacy API Keys. Once the attacker read the cache, their access was no longer limited to NextChat.

We compared the accounts and resource lists associated with the attacker against platform request logs and confirmed that these Zeabur Legacy API Keys came from the same cache file. The attacker then batch-tested the keys to identify the valid ones with higher permissions, one of which belonged to a team administrator.

Legacy API Keys were an early authentication method that Zeabur provided for the CLI and automation scripts. The original design did not support scopes, so permissions were limited neither by operation and resource nor by expiry. This was one of the reasons the impact of this incident widened.

All Zeabur Legacy API Keys have been disabled. The current Access Tokens support scopes, with permissions now able to be limited by purpose, and with expiry dates and retained audit records. Since the incident we have also [strengthened the authorization checks in our APIs](#api-authorization-response).

### Stage two: from Zeabur administrative access into the AWS account

The attacker abused this administrator's Zeabur Legacy API Key to enumerate internal projects and read the environment variables of an internal management service. Those variables contained several AWS access keys, including a long-retained key for the AWS root user. Cloud audit logs show that once those settings had been read, the same source immediately tested and abused the keys involved.

The keys held in the internal project at the time carried cloud permissions beyond what day-to-day operations required, which is why we evaluated the scope of this incident as extending to the AWS account.

### Stage three: from AWS and the shared cluster into production

After obtaining AWS root access, the attacker began enumerating cloud resources, then entered the Tokyo shared cluster. Cloud audit and cluster logs show unusual one-off jobs and privileged changes in the cluster, including a service account being granted cluster-administrator permissions. At this point, the attacker had the highest level of control over the accessed shared cluster.

Zeabur's core systems run on a different cloud provider. The production database has no public network entry point and can only be reached over private network. An existing scheduled maintenance job in the shared cluster, however, had that connectivity.

This scheduled job was designed to clean up services inside the designated shared cluster, which is why it required connectivity to the core systems. The database credential of the job could read more than what the job actually required, and it could connect back to the core systems over the private network. When the attacker took control of the Tokyo shared cluster, they gained access to both the network connection and the database.

<NetworkPivot
  title="The path from the shared cluster back to production"
  description="The production database had no public entry point. A maintenance job in the shared cluster could connect over the private network"
  blocked={{
    title: 'Public internet',
    label: 'No public entry point, connections blocked',
  }}
  pivot={{
    zone: 'AWS · Tokyo shared cluster',
    title: 'Shared cluster service cleanup job',
    detail:
      'For operational purpose, this job held a core database credential with more permissions than it required, and could connect back to the core systems over the private network. The attacker gained both after taking control of the cluster',
    label: 'Private network · trusted traffic',
  }}
  target={{
    zone: 'Core production · a different cloud provider',
    title: 'Production database',
    detail:
      'The attacker used this service identity to read project environment variables: the first confirmed intrusion record appears at 07:54, with bulk reads from 11:52',
  }}
  caption="Figure 3: A maintenance job in the shared cluster held both a private network connection and database credentials, which is how the attacker was able to reach the production database"
/>

Database records confirm that the attacker assumed this service identity to read project environment variables in production. After comparing the query logs, we found no evidence that any other data had been read, and we have [revoked this credential](#production-access-response) and removed the shared cluster's path back to the core systems.

## Our responsibility and why the attack spread

The NextChat vulnerability was the initial entry point for this incident. As a platform that allows users to deploy and run applications, we are and should be responsible for limiting the networks, data, and permissions an attacker can reach when a workload is compromised. Platform credentials held in the routing cache, Legacy API Keys with no scope or expiry, excessive cloud permissions held by an internal service, and a maintenance job that had both cross-environment connectivity and an over-permissioned database credential together widened the impact of this incident. Shared clusters and Legacy API Keys were undergoing the retirement process, and maintaining adequate isolation and access controls on them until they ceased operating was part of that process.

## Response and remediation

For the [confirmed scope described above](#confirmed-impact-scope), we first closed the access paths we had identified, then addressed the credentials and affected environments individually.

### Completed

- <span id="internal-credential-response" />
  **Internal platform credentials:** We disabled or rotated every internal
  administrative key, database password, and cache password, and disabled Zeabur
  Legacy API Key authentication entirely. None of the legacy keys can be used to
  access Zeabur.
- <span id="ai-hub-response" />
  **AI Hub access keys:** Every AI Hub access key confirmed to have been created
  by the attacker has been revoked. AI Hub remains disabled, and we will
  announce our plans for it separately.
- <span id="api-authorization-response" />
  **API authorization and access records:** We strengthened the authorization
  checks in our existing APIs and added access records to the current Access
  Tokens. On the [Access Token management
  page](https://zeabur.com/account/api-keys) you can review when each token made
  a request, the source of that request, and the operation it performed, so that
  you can identify usage you do not recognize and investigate unusual access.
- <span id="production-access-response" />
  **Production access paths and database credentials:** We disconnected the
  shared cluster's existing connection to the production database, revoked the
  corresponding database service account, and removed the unusual cluster
  permissions we identified.
- **Legacy internal services and shared clusters:** We disabled the legacy internal services involved in this incident, separated routing information from user credentials, removed the credentials from the legacy cache, and completed the replacement of the shared cluster hosts.
- **Auditing, monitoring, and alerting:** We addressed the gaps in our cluster, network, database, and cache operation records, added alerts for privileged changes, unusual cloud account usage, and suspicious database queries, and enabled cloud runtime security monitoring.
- **Log retention and internal security checks:** We extended the retention period for monitoring, logs, and request traces, expanded storage, and completed security self-checks of the employee devices and development environments involved.

### Ongoing

- **Cross-system log comparison:** We continue to compare cloud, cluster, database, and application records to determine whether any other activity is related to this incident.
- **Support, compensation, and reporting to authorities:** We continue to process support and compensation requests from affected users, and to report our investigation findings to the relevant authorities.
- <span id="third-party-credential-response" />
  **Replacing affected users' third-party credentials:** We sent the first
  notice on August 28 at 08:53 and the second notice at 17:03 the same day. If
  you have not yet completed these steps, you will still need to revoke the
  credentials listed in the notice, create new ones, update your service
  settings, redeploy the services involved, and review the access records and
  charges.
- **Preventive credential replacement:** To reduce further risk, we recommend replacing every credential that was ever stored in a Zeabur environment variable and remains valid, including any not listed in the notices.

<div id="product-and-security-improvements" />

## Product and security improvements

After the incident, we reduced what we hold centrally and limited each service's permissions to what its work requires, following a review of how Zeabur stores and accesses confidential information. The [security update announcement](/changelogs/security-update) describes these features and how to implement them.

### Implemented

#### Environment variables stored on your own server

The new storage method keeps environment variables directly on your Dedicated Server, rather than centrally in Zeabur's database.

New services use this method by default. Existing services can migrate from the environment variables page, and once that is complete the corresponding variables are removed from Zeabur's central database. This currently applies to Dedicated Servers only. Services on shared clusters do not switch automatically.

This changes only how variables are stored. It does not invalidate old credentials, so the credentials involved in this incident still need to be replaced.

#### Removing SSH credentials stored by Zeabur

For newly purchased servers, Zeabur no longer retains SSH passwords or private keys. For existing servers that support migration, the credentials Zeabur holds can also be removed from the server's settings, without affecting other server management features. You can also review SSH login records in the Zeabur console to see the sources of successful logins and login attempts, and firewall settings allow you to limit which sources can connect to your server.

### Continuing improvements

#### Isolation and monitoring for systems being retired

We will continue to maintain isolation, monitoring, and access controls on the systems undergoing the retirement process, until the workloads on them have migrated or stopped running.

#### Authentication, authorization, and auditing

Zeabur Access Tokens already support scopes, so permissions can be limited by purpose. We are also continuing to strengthen scope and authorization checks in our existing APIs, and adjusting login-token expiry, component permissions, resource authorization, and logging for sensitive operations.

While we were adjusting access controls, GitHub-related features, environment variable management, and email were affected for a period. We are improving how we validate changes in advance, to reduce the effect of later adjustments on our services.

#### Incident detection and user communication

We only confirmed this incident after receiving a report of API key abuse on August 28 at 02:34. A subsequent review of database records identified the earliest intrusion record at 07:54 on August 27. Our monitoring and alerting at the time did not identify this unauthorized access.

During the initial investigation, incomplete evidence led us to misjudge the scope of impact. We sent the first notice on August 28 at 08:53, then the second at 17:03. We apologize for the inconvenience caused by that first notice not covering the full scope of impact, and we are improving how we verify scope and notify users, so that we can provide accurate remediation instructions sooner once an incident is confirmed.

## Key timeline

The table below lists out the confirmed timeline in UTC. The first recorded use of a credential does not indicate that the attacker obtained it and began misusing it at that same moment.

| Time (UTC)              | Event and response                                                                                                                                                          |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| August 27, 02:34:17     | Earliest confirmed unusual API requests. Probing of platform interfaces and account-related functionality begins.                                                           |
| August 27, 02:36:09     | This activity uses a team administrator's Zeabur Legacy API Key for the first time, querying account and AI Hub information.                                                |
| August 27, 02:37:57     | First AI Hub access key created through that administrator account.                                                                                                         |
| August 27, 03:53:50     | First read of project environment variable names and values, with the administrator's Zeabur Legacy API Key.                                                                |
| From August 27, 05:26   | The administrator's Zeabur Legacy API Key is abused to list internal projects and services, and probing of internal settings continues.                                     |
| August 27, 05:39:28     | The environment variables of an internal service are read, including an AWS access key abused shortly after.                                                                |
| August 27, 05:40:15     | The same source authenticates to AWS with that access key.                                                                                                                  |
| August 27, 05:42:36     | The internal management service settings are read, including the privileged AWS key abused shortly after.                                                                   |
| August 27, 05:45:57     | The same source authenticates to AWS with the root user key.                                                                                                                |
| August 27, 05:46:34     | Cloud resource enumeration begins under that root identity, and the requests succeed.                                                                                       |
| August 27, 06:08:56     | The earliest confirmed unusual one-off job is created in the Tokyo shared cluster.                                                                                          |
| August 27, 07:26:25     | A privileged change in the Tokyo shared cluster: a service account is granted cluster-administrator permissions.                                                            |
| August 27, 07:54        | Earliest confirmed intrusion record in the database.                                                                                                                        |
| From August 27, 11:52   | Records of bulk reads of project environment variables appear in the production database.                                                                                   |
| August 28, 02:34        | We receive the first report of API key abuse.                                                                                                                               |
| August 28, 08:53        | We send the first notice. With the evidence still incomplete, our assessment of the scope was incorrect.                                                                    |
| August 28, 17:03        | We send the second notice.                                                                                                                                                  |
| August 28               | AI Hub suspended as a precaution during the investigation. It remains disabled.                                                                                             |
| August 30–31            | We communicate with AWS about the incident, continue strengthening security measures, and review compensation requests.                                                     |
| August 31 – September 3 | We provide investigation findings to the relevant authorities and expand the retention of audit and forensic data.                                                          |
| September 4–5           | We publish our interim results: the confirmed incident paths are closed, internal credentials have been rotated, and monitoring continues to be strengthened.               |
| September 7             | We publish the [major security update](/changelogs/security-update), covering how environment variables and SSH credentials are stored, and the new SSH connection records. |
| As of this update       | Correlation of the activity and credential sources in this incident is complete. We continue to review cross-system records and adjust security measures.                   |

Earlier progress updates are available on the [incident status page](https://status.zeabur.com/incident/1037896).

## Support and compensation

If you need help, or you find unusual access or charges you cannot account for, please contact us through [Zeabur Support](https://zeabur.com/support) and we will help you review the relevant records and the next steps. Before contacting us, please:

- Revoke the affected credentials first, to reduce the risk of them being reused.
- Provide only redacted identifying information.
- Do not include complete, still-valid keys, passwords, or other credentials in a support ticket or any public channel.

If a third-party AI service API key was abused because of this incident and produced additional charges, please submit a compensation request through a support ticket. We will then:

- review the provider's usage records, the period of unusual activity, and the charges with you
- proceed with the compensation arrangements

## Closing

We understand the additional effort and inconvenience that followed the incident, which required our users to replace credentials, check services, and reconcile charges. We sincerely apologize for the risk and the additional work this incident has caused.

We will continue to carry out the support, compensation, and improvements scheduled. Further progress will be announced on the incident status page and in related posts.

Zeabur Team