Summary
- Zeabur confirmed access to its platform database containing 3,218,965 environment variable entries and information relating to 321,810 accounts.
- Attackers obtained root access to 101 Google Cloud dedicated servers; read commands affected 865 database services, but complete extraction is unproven.
- The initial credential theft and any link to August remain unresolved; Zeabur plans to shut down dedicated servers and shared clusters by 31 December.
Cloud deployment provider Zeabur says attackers used exposed internal credentials to enter shared hosting clusters, access customer servers and read its production database during a breach on 14–15 October. A detailed investigation released on 19 October identifies failures in credential storage, management interfaces and network separation, while making clear that several possible links to an earlier security incident have not been proved.
Zeabur says the attackers queried its platform database and accessed records comprising 3,218,965 stored environment variables and information relating to 321,810 accounts, as well as projects and service settings. Environment variables can include ordinary application configuration alongside passwords, API keys and other secrets. These figures count database records, not separate victims, and do not show how many individual customer systems were subsequently abused.
Zeabur reconstructed two routes into its infrastructure. In one, the attackers used internal AWS credentials and a cluster administration token that had been stored in plain text in a private configuration repository. Its shared cluster administration interfaces were exposed to the internet, and the relevant management token had no expiry. The attackers could consequently reach infrastructure distributed across nine regions without first obtaining the credentials of an individual hosted application.
The second route involved dedicated servers hosted on Google Cloud. Zeabur confirmed root logins to 101 servers used by 92 customers, attacker-controlled SSH keys added to 50 servers, and copies of 16 customer server disks mounted on virtual machines created within its cloud project. The company consequently classed all 101 servers as potentially exposed to data theft or persistent access. Root access is confirmed; comprehensive copying of every server’s contents is not.
The two routes eventually intersected. The investigators say the attacker connected a compromised server to Zeabur’s internal network using credentials obtained elsewhere and then used a read-only account to query the platform database. The documented database access took place between 16:10 and 16:47 UTC on 15 October. The company correlated network and database records to identify the connections and queries, although its available logs do not establish every downstream use of the retrieved information.
The exposed material creates risks beyond Zeabur account profiles. Customer-managed application secrets may enable access to external databases, AI services, source code or payment systems even after the hosting platform has contained the original intrusion. Zeabur also reported exposure of 566 zSend API keys, which it revoked, while 11,536 platform access tokens were stored as hashes and subsequently invalidated. The distinction is consequential: a hashed token is not automatically a reusable credential, while a plain-text service key may be operational immediately if it remains valid.
Within shared clusters, Zeabur identified read commands executed in the containers of 865 database services, including n8n and PostgreSQL deployments. Some commands failed and the audit records captured commands rather than returned data, so the company could not determine how much content was retrieved from each service. For 602 of 607 n8n deployments it examined, an encryption key was stored in an environment variable, potentially exposing credentials that the application otherwise stored in encrypted form. The documented command count is not evidence that 865 complete databases were stolen.
Containment was complicated by the reuse of secrets held in backups. Zeabur found that a replacement credential issued during the response subsequently appeared in a backup and was used again by the attacker. The company revoked exposed tokens, rotated production credentials, restricted public SSH access to affected Google Cloud servers, and notified affected users. Those actions addressed further use of known access routes but could not reverse any earlier copying of secrets or data.
The company suffered a separate breach in August and believes an exposed GitHub application secret from that incident may have helped the October attacker obtain configuration material. It explicitly describes that connection as a hypothesis. Available audit records do not show conclusively how the initial October credentials were acquired, nor do they establish that earlier reconnaissance was conducted by the same individual. The October attack should not be presented as a proved continuation of the August incident.
Zeabur operated deployment infrastructure across multiple regions, including European locations, but its public report does not provide a country-by-country tally of affected customers. Users with shared cluster workloads, managed dedicated servers or externally connected application credentials face different categories of potential exposure. Its incident guidance addresses those differences, including secret rotation, review of connected services and rebuilding dedicated servers where an attacker obtained root access.
Founder Yuanlin Lin announced on 17 October that Zeabur would wind down operations after a second security incident in less than two months. The company said certain services would begin closing on 1 December, with dedicated servers and shared clusters scheduled to stop by 31 December; data export and final deletion deadlines remained to be announced. Customers must therefore account for potential credential exposure from the October intrusion while arranging application migration under the separately announced shutdown timetable.
