Zeabur customers face two urgent jobs: replacing exposed credentials and moving their applications before the platform shuts down.
The developer hosting platform disclosed an Oct. 14–15 intrusion that exposed information for 321,810 accounts and more than 3.2 million environment-variable records. The incident followed another breach in August, and Zeabur has announced plans to stop operating by the end of December.
For security teams, the concern extends beyond account details. Credentials stored with a deployment provider can give attackers access to databases, cloud resources, and paid AI services elsewhere.
What the attacker accessed
Zeabur’s preliminary incident report confirms that the attacker read 3,218,965 environment-variable records, including names and values, alongside account information such as email addresses, usernames, and phone numbers.
Environment variables hold application settings and can contain passwords or API keys. The record count does not mean 3.2 million separate customers or usable credentials were exposed. Zeabur said variables migrated exclusively to customers’ own servers after August were outside this database exposure, although compromised hosts could still expose them.
Zeabur also confirmed root access to 101 Google Cloud dedicated servers serving 92 users. Attacker-controlled SSH keys were added to 50 servers, creating a way to return after the initial intrusion.
Account holders should watch for targeted phishing and take steps to check whether their personal information has been exposed. Application owners also need to identify which external services their stored credentials could reach.
The risk resembles the recent OpenCode API-key exposure: a credential taken from one developer platform may authorize activity directly with another provider.
Unrotated credentials left access open
Zeabur said long-lived administrator credentials were stored in plaintext, and its shared-cluster management interface was accessible from the public internet. Some administrator tokens had not been rotated since January 2024 and were missed during the August response.
The company has not confirmed how the attacker initially obtained those credentials. A connection to the August breach remains a hypothesis.
The incident reinforces the value of network segmentation and restricted access: possessing one service credential should not provide unrestricted routes into other systems.
December shutdown adds a migration deadline
In its shutdown announcement, Zeabur set out two deadlines:
- Dec. 1: Dedicated-server renewals stop, with servers shutting down on their individual expiration dates. Running shared-cluster services will be paused, although customers can restart them manually to back up data.
- Dec. 31: All dedicated servers and shared clusters stop operating.
Customers should plan around their server’s expiration date. The company has not finalized its data deletion date, final export deadline, or support closure date.
What security teams should do now
The immediate priorities are credential revocation, investigation, and recovery. Zeabur urges customers to replace exposed credentials and rebuild compromised Google Cloud servers.
A practical response should include:
- Revoke credentials at the issuing provider. Revoke and replace exposed API keys, cloud keys, database passwords, and signing or encryption keys, then update dependent applications. Changing a database password in an environment variable does not change it inside the database.
- Review activity and costs. Check provider audit logs, database activity, and AI-service bills for unfamiliar access or charges.
- Investigate persistent access. Examine SSH keys, accounts, scheduled tasks, and service configuration. A password change alone will not remove an attacker’s added SSH key.
- Prepare a clean migration. Preserve relevant logs and back up required data before rebuilding and testing replacement services.
Verify recovery across connected services
Security teams should treat credential cleanup and migration as connected work. Moving an application can restore availability while leaving a stolen key valid at its original provider. Before closing the incident, verify that old credentials fail and replacement credentials work only where intended.
Give each affected integration an owner. That person should document what the credential could access, when it was revoked, which logs were reviewed, and whether suspicious changes need further investigation. Prioritize credentials with administrative rights, sensitive-data access, or significant spending authority.
Keep recovery separate from copying the old environment wholesale. Validate application code and configuration, restore required data, and check that unauthorized accounts or access mechanisms have not followed the workload into its new home.
For organizations assessing other hosting vendors, this case suggests concrete questions: Can the provider identify every credential involved in an incident, demonstrate that revocation is complete, and provide logs sufficient to investigate customer impact? Those answers help determine whether a security assurance is enough to resume trusting the service.
Read more: The ConnectWise Cloud Backup breach shows why disabling compromised vendor credentials still leaves administrators with work to do to uncover unauthorized changes and persistent access.