Cloud deployment platform Zeabur has published its full investigation into an August security incident, saying attackers reached its production environment database and read some users’ project environment variables after chaining together multiple weaknesses across its infrastructure.
According to the report, the attackers first exploited a vulnerability in a user-deployed NextChat service inside a shared cluster, then obtained Zeabur administrator privileges and an AWS root key, and finally used an internal maintenance task to connect into the production database. The data read by the attackers included sensitive configuration such as third-party and AI service API keys, cloud access credentials, database connection details and passwords, and application signing keys.
NextChat flaw opened the path into the shared cluster
Zeabur said the attackers initially targeted a NextChat v2.16.1 service that was still running in a Tokyo shared cluster. They used CVE-2026-7644, which the report linked to insufficient authorization checks in the MCP feature, to gain remote code execution inside the container.
From there, the attackers took advantage of cross-project internal network access already present in the shared cluster and reached a cache that stored routing information. That cache held mappings between domains and services, and also contained Zeabur’s older Legacy API Keys.
After testing the keys they obtained, the attackers found a small number of still-valid high-privilege keys. One of them belonged to a Zeabur team administrator. Zeabur said Legacy API Key was an older authentication method used for CLI tools and automation scripts. It did not support scoped permissions, had no clear expiration, and could not restrict permissions by action or resource, which allowed the intrusion to expand quickly.
Internal services held multiple AWS credentials, including a root key
With an administrator API key in hand, the attackers enumerated Zeabur’s internal projects and services and read environment variables from an internal management service. Zeabur said those variables included multiple AWS access keys, as well as a long-retained AWS root user key.
Cloud audit records showed that after reading the configuration, the attackers immediately tested and used those keys, enumerated AWS resources as root, moved into the shared cluster in Tokyo, created an anomalous one-off job, and elevated one service account to cluster administrator.
Zeabur said its core systems were deployed with another cloud provider and that the production database had no public internet entry point. Even so, a scheduled maintenance task used to clean up services inside the shared cluster could connect back to the core system over a private network. That task also held database credentials with broader access than the job required. Once the attackers controlled the shared cluster, they gained that private network path and the database access route, which led them into the production environment database.
Project environment variables were read; AI Hub keys were created but not used
Zeabur said the attackers read the names and contents of some project environment variables. The data may have included:
- Third-party AI API keys for services including OpenAI, Anthropic, Gemini, and OpenRouter
- Cloud service credentials for AWS, Cloudflare, and DigitalOcean
- GitHub tokens
- Database connection URLs and passwords
- JWT secrets, application signing keys, and other confidential project settings
The attackers also used the stolen Zeabur Legacy API Key to query some account and AI Hub information and created new AI Hub access keys. Zeabur said it compared usage and billing records and found that those keys were never used to call AI Hub and did not generate any charges. The keys have since been revoked.
For the production database itself, Zeabur said the query records currently confirm only the reading of project environment variables, and that it has not found evidence that the attackers accessed other types of data.
Unauthorized activity was confirmed about 24 hours later
The earliest confirmed anomalous API request appeared at 02:34 UTC on Aug. 27. By 07:54, there was already a record of intrusion into the production database. Starting at 11:52, the attackers began reading project environment variables at scale.
Zeabur said it did not confirm the security incident until 02:34 UTC on Aug. 28, when a user reported that an API key had been abused. That was about 24 hours after the earliest anomalous request. The company said its monitoring and alerting at the time failed to identify the unauthorized access.
The team sent its first emergency notice at 08:53 on Aug. 28, but misjudged the scope of impact because the initial evidence was incomplete. A second notice followed at 17:03 the same day.
Shared clusters and Legacy API Keys were already being phased out
Zeabur said that while the NextChat vulnerability was the initial entry point, the platform itself remained responsible for limiting what an attacker could reach in terms of network access, data, and privileges after a user workload was compromised.
The report said the incident exposed several internal security gaps, including platform credentials stored in routing cache, Legacy API Keys with no permission limits or expiration, excessive AWS privileges held by internal services, and maintenance tasks that combined cross-environment network access with overprivileged database credentials.
Zeabur added that both shared clusters and Legacy API Keys had already entered the retirement phase before the incident. It announced a shared cluster retirement plan in February this year, stopped creating new projects in March, and stopped creating new services in existing projects in April. The service used in this attack, however, had been deployed before those retirement announcements and remained in operation.
Company disabled Legacy API Key authentication and urged users to rotate credentials
After the incident, Zeabur said it disabled or rotated internal management keys, database passwords, and cache passwords, completely shut down Legacy API Key authentication, and cut off the shared cluster’s path to the production database.
It also strengthened API authorization checks so that current access tokens support scopes, expiration, and request logs. The company added alerts for high-privilege changes, anomalous use of cloud accounts, and suspicious database queries.
Zeabur also rolled out a larger security upgrade that allows dedicated server users to move environment variables entirely to their own servers and remove them from Zeabur’s central database. Users can also remove SSH passwords and private keys stored by Zeabur and review SSH login records.
The company said those changes do not automatically invalidate old credentials that may already have been exposed. Zeabur advised all users to replace any credentials that were stored in platform environment variables and are still valid. It also told users to review access logs, usage, and bills for third-party services even if they were not included in an official notice.
If third-party AI API keys were abused in this incident and generated extra charges, users can apply to Zeabur for compensation. Zeabur marked the incident as resolved on Sept. 9 and said most compensation claims had already been verified, while cross-system log reconciliation, user support, and follow-up security improvements would continue.