Zeabur August 2026 security incident

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 have since been carried out.

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. 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.

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.

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.

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 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 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, 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.

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.

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.

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 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, we first closed the access paths we had identified, then addressed the credentials and affected environments individually.

Completed

• 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.
• 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.
• 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 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.
• 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.
• 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.

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 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.

Earlier progress updates are available on the incident status page.

Support and compensation

If you need help, or you find unusual access or charges you cannot account for, please contact us through Zeabur 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