metaTitle: "Zeabur Breach: Unrotated Credentials and Shutdown" metaDescription: "Zeabur says credentials left out of an earlier rotation enabled access to platform systems in October. See what the company confirmed, what remains uncertain, and what customers should do before the shutdown."
Zeabur’s October breach exposed gaps in credential control
Zeabur says an attacker used leaked internal credentials to access its shared cluster, some dedicated servers and internal systems, and read data from the platform database. The company attributes the incident in part to a gap after an August breach: some administrator credentials were not rotated. Some admin tokens had no expiry, and internal systems were not sufficiently segmented. (Zeabur’s preliminary incident report)
Zeabur disclosed the incident on October 19, describing activity on October 14 and 15. Its investigation was ongoing. The report distinguishes confirmed activity from assessed exposure and from systems where access or data removal could not be confirmed; it does not establish that every potentially affected asset was downloaded. Zeabur advised customers to treat potentially exposed credentials as compromised. (Zeabur’s preliminary incident report) For a related example of a serious web-application flaw and breach exposure, see the Metabase SQL injection incident.
What the attacker accessed—and what remains uncertain
Zeabur says the attacker read platform database information including environment-variable names and values, account details, project, environment and service data, and plaintext zSend API keys. The company reported 3,218,965 environment-variable records and 321,810 accounts in the affected data categories. It said 566 zSend keys were revoked. Platform Access Tokens were stored as hashes that could not be reversed; 11,536 were revoked. (Zeabur’s preliminary incident report)
The report also describes access to infrastructure beyond the database. Activity on GCP dedicated servers was confirmed, while the full scope for some other server environments could not be established. Zeabur said shared-cluster environment variables and secrets were affected across nine regions, with only part directly confirmed. For database contents on 865 services, the company described its conclusion as an assessment, not direct confirmation. It also said it could not confirm whether certain backups had been downloaded. (Zeabur’s preliminary incident report)
These categories should not be conflated: some access was confirmed, some exposure was assessed, and some possible access or downloads could not be confirmed. The report does not support treating every listed asset as a confirmed theft. (Zeabur’s preliminary incident report)
Zeabur says that on October 15 the attacker searched environment variables and configuration files for API keys and private keys. Its logs recorded the last attacker activity at 21:05 UTC that day. The company revoked cluster administrator tokens and AWS and GCP keys used in the activity, removed an internal network node, blocked public SSH access to admin interfaces and servers, signed users out and revoked platform Access Tokens. (Zeabur’s preliminary incident report)
Why the August response left credentials exposed
The October compromise followed an August incident, but Zeabur’s disclosures describe different entry paths. The August attack began with exploitation of a vulnerability in a user-facing service and escalated across system boundaries. Zeabur reported access to internal systems and production data, including environment variables containing third-party credentials. (Zeabur’s August incident report)
After August, users were told to rotate credentials and move environment variables and configuration files off the platform. Some did. Zeabur says projects that moved those values to their own dedicated servers were outside the scope of the later platform database read. (Zeabur’s August incident report; Zeabur’s preliminary October incident report)
The October report identifies what the earlier rotation missed: cluster administrator tokens and AWS keys stored in plaintext in a configuration repository, as well as root passwords in GCP server initialization settings. Zeabur says these credentials were used in October. It also corrected its earlier statement that all internal admin keys had been disabled or rotated, acknowledging that the statement was incomplete. (Zeabur’s preliminary incident report; Zeabur’s August incident report)
The rotation missed credentials in internal repositories and server settings. Some admin tokens had no expiry, and weak segmentation allowed valid credentials to reach systems that were not adequately separated. (Zeabur’s preliminary incident report)
What users should do now
Zeabur told customers to replace every password and key stored on the platform, including credentials they had already changed after August. Customers should identify secrets and configuration values stored with Zeabur and rotate them with the services that issued them. The company’s warning reflects potential exposure; it does not mean every credential was used. (Zeabur’s preliminary incident report)
Zeabur says platform Access Tokens were revoked and all users signed out. Customers should still check provider accounts and logs where available, especially for credentials granting access to cloud infrastructure, databases, source repositories or third-party services. (Zeabur’s preliminary incident report)
The company said projects that moved environment variables to their own dedicated servers after August were outside the platform database read. That distinction does not settle the status of other infrastructure or credentials. Customers should check Zeabur’s incident notice for updated findings because the investigation was ongoing. (Zeabur’s preliminary incident report)
The shutdown adds a second urgent deadline
On October 17, Zeabur announced it would wind down the platform. New dedicated-server and domain purchases stopped immediately. From December 1, 2026, dedicated-server renewals would be disabled, while shared-cluster services would be paused; users could restart them manually to back up data. The company said all dedicated servers and shared clusters would stop operating by December 31. It had not yet announced the final data-export deadline, deletion date or support closing date. (Zeabur’s shutdown notice)
Customers now need to manage migration and incident response at the same time: preserve needed data, move workloads, and rotate exposed credentials before relying on them elsewhere. Check Zeabur’s later updates for any changes to the announced dates. (Zeabur’s shutdown notice; Zeabur’s preliminary incident report)
The incident’s clearest security lesson
Zeabur’s account identifies the gap: the August rotation missed internal credentials later used in October, and weak segmentation allowed access across systems. Moving environment variables helped some customers avoid the later platform database read, but did not address those internal credentials. The company also reported that valid credentials and legitimate access paths did not trigger alerts during the initial period. (Zeabur’s preliminary incident report; Zeabur’s August incident report)