Zeabur Re-Breach: Unrotated Admin Credentials Expose 3.2 Million Environment Variable Records

1. Basic Information

• Article Title: Zeabur October 2026 security incident (preliminary report)
• Publisher: Zeabur
• Publication Date: 2026-10-19
• Original Source: Zeabur
• Related Sources: BleepingComputer: Zeabur shutting down after second security breach in two months, Zeabur is shutting down: what happens next
• Associated Malware / Threat Actor: Unidentified attacker
• Associated CVE: None
• Affected Products: Zeabur, Google Cloud Platform, AWS, GitHub Apps, Tailscale
• Severity: Critical
• Basis of Severity: Root logins were confirmed on 101 GCP dedicated servers, SSH public keys were added to 50 servers, 16 customer disk copies were attached to attacker VMs, and read commands were executed within 865 database services. Rebuilding compromised hosts and revoking target credentials are required, though this does not indicate that all commands succeeded.
• Reason for Update: Updated to align the primary source, prerequisites, observation scope, confidence statements, and ATT&CK mappings with primary sources and official specifications. This editorial update is distinct from the original source's publication or update timestamp.

2. Quick Summary

Zeabur announced that long-lived administrator tokens and cloud keys left in plaintext were abused to infiltrate shared clusters across nine regions, Google Cloud Platform (GCP) dedicated servers, and production databases. The scope of platform database reads includes 321,810 accounts and 3,218,965 environment variable records. Note that environment variables migrated to dedicated servers and deleted from Zeabur after the August incident are excluded from this platform database read scope, but exposure risks due to host-level compromises must be evaluated separately.

3. Attack Flow

This incident involved two parallel intrusion vectors—one targeting shared clusters and AWS, and the other targeting GCP dedicated servers—which converged through internal network and platform database access. The following distinction between confirmed observations and Zeabur's assessments is based on Zeabur's primary report.

Path A: Shared Clusters and AWS

1. External Access to Shared Clusters (October 14): Starting at 01:36 UTC, internal AWS keys were abused, followed at 01:40 by the abuse of indefinite cluster administrator tokens to access shared clusters across nine regions. The acquisition path for these initial credentials and any direct connection to the August incident remain unconfirmed.
2. Command Execution Within Database Services: Shared cluster settings and secrets were read, and read commands were executed within 865 database services. However, command outputs were not recorded, and some executions failed, meaning this does not imply successful reads across all databases.
3. Production Secrets Read (October 15): Zeabur assesses that the attacker used over-privileged keys to read old cluster backups and obtain secret management service keys. Logs confirm that approximately 53 production secrets were read between 14:52 and 16:51 UTC on October 15.

Path B: GCP Dedicated Servers

1. Root Sign-ins to 101 Servers (Starting October 14): Zeabur assesses that plaintext root passwords were retrieved from initialization settings using legacy GCP keys. Root sign-ins to a total of 101 GCP dedicated servers were confirmed starting October 14, and this intrusion—initiated the previous day (October 14)—is not treated as a result of the production secret read on October 15.
2. SSH Key Addition and Disk Copy Attachment: Attacker SSH public keys were added to 50 of these servers, and 16 copies of customer disks were attached to five VMs created by the attacker (compromised server counts and disk copy counts are not treated as identical).

Convergence of Both Paths: Internal Network and Platform DB

1. Node Addition to Internal Network (October 15, 15:30 UTC): Internal network administrator credentials obtained via Path A were used on compromised GCP servers to add nodes to the internal network (compromise of customer servers was not a mandatory prerequisite for joining the internal network).
2. Platform Database Read (October 15, 16:10–16:47 UTC): The platform database was queried using internal read-only database accounts. While 3,218,965 environment variable records and 321,810 accounts were within the read scope, this does not indicate that every individual secret was subsequently abused.

Vector / Target	Key Observations / Metrics	Confirmation Status & Interpretive Notes
Path A: Shared Clusters (9 Regions)	Read commands executed within 865 database services, approximately 53 production secrets read	Key retrieval from old cluster backups is Zeabur's assessment. Outputs for 865 databases were unrecorded with some failures.
Path B: GCP Dedicated Servers	Root sign-ins to 101 servers, SSH public keys added to 50 servers, 16 customer disk copies attached to 5 attacker VMs	Occurred starting October 14. Actual acquisition and abuse scope of disk contents unconfirmed.
Post-Convergence: Platform DB	Queries against 321,810 accounts and 3,218,965 environment variable records	Variables migrated to dedicated servers and deleted from Zeabur after August are excluded from DB read scope (host compromise evaluated separately).

4. Attacker Positioning and Execution Environment

• Unidentified external attackers with reachability to the Zeabur admin interface and cloud APIs
• Entities holding stolen administrator tokens and AWS/GCP keys
• Post-compromise operators who achieved root SSH access to GCP hosts and infiltrated the internal overlay network

5. Perspective of Victims and Administrators

Victims

• Service secrets and environment variables may have been read, leading to unauthorized use of external cloud, API, and database accounts.
• Dedicated servers must be rebuilt, all credentials rotated, and migrations to alternative infrastructure performed due to service termination.

Administrators and SOCs

• Cloud/API audit logs can show metadata modifications and suspicious disk attachments, and SSH key changes made through instance metadata. Root SSH sign-ins should be checked in host authentication or SSH server logs; verify that those logs were collected and retained.
• Command execution within database containers, secret store reads, and high-volume queries against the platform database occur in succession.

6. Success and Failure Conditions

Success Conditions

• Long-lived credentials remain valid and can be used to access management interfaces from the public internet.
• Over-privileged access rights are assigned to cloud keys or cluster roles.
• Root passwords and various secrets are retrievable in plaintext within configuration repositories or initialization settings.

Failure Conditions and Mitigations

• Conduct a comprehensive inventory of all administrator tokens and cloud keys per incident, applying rotation, expiration settings, and source IP restrictions.
• Restrict access to the management plane to private networks and environments requiring multi-factor authentication (MFA).
• Inference: Isolate access permissions and storage locations for customer secrets, and design systems to avoid storing plaintext root passwords in server initialization settings. Following containment, inspect secrets contained within backups and revoke or replace exposed credentials again as needed, preventing newly issued keys from being re-exposed via backups.

7. What Happens Upon Success

• Reads of 3,218,965 environment variable records and 321,810 accounts on the platform database (variables already migrated to dedicated servers and deleted so they no longer reside on Zeabur are excluded from this database read scope, nor does this imply subsequent abuse of individual secrets).
• Root sign-ins to 101 GCP dedicated servers, SSH public key additions to 50 servers, and attachment of 16 customer disk copies to 5 attacker VMs.
• Risk of secondary compromises using downstream cloud, API, and database credentials contained within exposed environment variables.

8. Observable Logs

Inference: The following items are candidates for investigation within your organization. Availability depends on products, permissions, log settings, and retention periods; isolated suspicious operations or missing logs alone do not definitively establish attribution or compromise.

Email

• Check for incident notification emails from Zeabur and unauthorized usage alerts from downstream cloud and SaaS providers.

Proxy / SWG / DNS

• Review abnormal network traffic directed at management portals, internal overlay networks, and database services.

Endpoint / EDR

• Check for unauthorized SSH public key additions, root logins, read command execution within containers, and credential discovery behavior.

Identity / IdP

• Review usage history and rotation history for administrator tokens issued in 2024, legacy AWS/GCP keys, and GitHub App private keys.

SaaS / Cloud

• Review available cloud/API audit records for GCP metadata changes and disk attachments, AWS key usage, and secret-manager reads. Correlate root sign-ins with host SSH/authentication logs; do not assume cloud audit records contain every SSH login.

Network

• Identify public management surface access and communication traversing compromised nodes to join the internal network.

9. Attack Success Determination

• Information Theft or Session Compromise Confirmed
• Basis: Publicly disclosed information confirms that Zeabur verified platform database query execution, the reading of approximately 53 production secrets, and root sign-ins on 101 GCP servers. Meanwhile, shared clusters lack complete read logs across all nine regions, and command outputs or actual data retrieval volumes for the 865 database services remain unconfirmed.
• Scope: Published record and account counts represent the read reachability scope on the platform database side and do not reflect the number of times individual secrets were actually abused.

10. Investigation Playbook

• Trigger: Identify traces of unauthorized SSH key additions, root logins, container-internal read commands, and credential discovery.
• Initial Verification: Normalize target assets, accounts, and event timestamps to UTC/JST, and preserve relevant logs.
• Endpoint / Server Investigation: Check cloud/API audit logs for metadata changes, disk attachments, and SSH key changes made through metadata. Use host authentication or SSH server logs to investigate root sign-ins, subject to collection and retention.
• Authentication / Cloud Investigation: Review usage history and rotation status for administrator tokens issued in 2024, legacy AWS/GCP keys, and GitHub App keys.
• Follow-up Operations: Assuming that 3,218,965 environment variable records and 321,810 accounts on the platform database were read, investigate potential unauthorized use of potentially leaked credentials across external services (variables migrated and deleted from Zeabur are excluded from this database read scope, though host compromises must be evaluated separately).
• Containment: Inventory all administrator and cloud keys per incident, applying rotation, expiration dates, and source IP restrictions, while rebuilding or isolating compromised hosts.
• Determination Categories: Clearly separate contact, execution, authentication success, data acquisition, and secondary compromise; do not presume unconfirmed successes.

11. Defense and Detection Ideas

• Single Events: Detect unauthorized SSH key additions, root logins, read command execution within containers, and credential discovery.
• Timeline Correlation: Inference: Track Path A (shared cluster administrator access and production secret reads) and Path B (GCP dedicated server root sign-ins and SSH public key additions) separately, then correlate them with the node addition to the internal network and subsequent convergence on platform database queries. Also verify the workflow where new keys are included in backups and utilized from unknown sources.
• Threat Hunting: Hunt for access originating from public management surfaces and traffic joining the internal network via compromised nodes.
• Log Limitations: How the initial credentials were obtained remains unconfirmed. A connection to the August incident is Zeabur's hypothesis, not an established acquisition path.
• Priority Mitigations: Inventory all administrator and cloud keys per incident, applying rotation, expiration dates, and source IP restrictions. Restrict the management plane to private networks and MFA environments. Inference: Separate permissions and storage locations for customer secrets, avoid storing plaintext root passwords in initialization settings, inspect secrets within backups after containment and revoke or replace exposed credentials again as needed, and prevent the re-exposure of new keys.

12. Facts / Inference / Hypothesis

Facts

• On October 14–15, 2026, attackers used Zeabur's internal AWS keys and indefinite administrator tokens to access shared clusters across nine regions from outside.
• Long-lived administrator credentials were stored in plaintext within private configuration repositories and were omitted from rotation following the August incident.
• Attackers executed read commands within 865 database services, but outputs were unrecorded and some failed. Separately, the reading of approximately 53 production secrets, platform database accounts, and GitHub App private keys was confirmed.
• Root sign-ins on 101 GCP dedicated servers, SSH public key additions on 50 servers, and the attachment of 16 customer disk copies to 5 attacker VMs were confirmed (the full extent of disk content acquisition and abuse remains unconfirmed).
• 321,810 accounts and 3,218,965 environment variable records fall within the platform database read scope. Variables migrated to dedicated servers and deleted from Zeabur after August are excluded from this database read scope, though exposures from host-level compromises must be evaluated separately. This does not imply that all commands succeeded or all records were abused.
• Zeabur's official shutdown notice states that some service shutdowns begin and dedicated server renewals are disabled on December 1, 2026, with all dedicated servers and shared clusters shut down by December 31 (this does not mean all services remain operational until the end of December).

Inference

• The combination of inadequate credential inventories following the August incident, management interfaces reachable from the public internet, and over-privileged keys expanded the blast radius of the re-breach.
• Because environment variables contain downstream SaaS and cloud credentials, investigations must proceed under the assumption of secondary exploitation outside the Zeabur environment.

Hypothesis

No additional hypotheses. Unverified items are listed under "Open Questions and Additional Investigations".

13. MITRE ATT&CK Mappings

ID	Technique	Confidence	Basis
T1078	Valid Accounts	high	Zeabur confirmed access using valid AWS/GCP keys and indefinite admin tokens. Definition
T1552.001	Unsecured Credentials: Credentials In Files	medium	Plaintext configuration repositories or initialization settings could serve as credential sources, though the initial credential acquisition path is unconfirmed. Definition
T1098.004	Account Manipulation: SSH Authorized Keys	high	Addition of attacker SSH public keys to 50 GCP servers was confirmed. Definition
T1530	Data from Cloud Storage	medium	Acquisition of old cluster backups is Zeabur's assessment. Acquisition of separate customer database backups is confirmed by host-level evidence. Definition
T1059.004	Command and Scripting Interpreter: Unix Shell	high	Read commands within database containers were recorded. This does not imply success for all commands. Definition

14. Open Questions and Additional Investigations

• How the initial credentials were obtained, and whether their acquisition was connected to the August incident
• Whether individual exposed customer secrets were actually abused
• Whether root sign-ins observed between September 1–5 originated from the same actor as the current attackers
• The full volume of data actually exfiltrated from databases or disk copies

15. Impact on SOCs and Organizations

Revoke and reissue all secrets stored within Zeabur's platform database or compromised dedicated servers, and inspect audit logs from cloud and SaaS providers outside Zeabur for signs of secondary use. In addition to recovery and migration tasks on the PaaS infrastructure side, customers must also rotate or review the tokens, API keys, and sessions associated with their own accounts.

16. Summary by Role

• For SOCs: Check for access from public management surfaces and traffic joining the internal network via compromised nodes, and investigate traces of unauthorized SSH key additions, root logins, container read commands, and credential discovery.
• For Administrators: Inventory all administrator and cloud keys per incident, applying rotation, expiration dates, and source IP restrictions.
• For Users: If you encounter suspicious notifications, outages, or authentication requests, do not act on them independently and promptly contact your administrator.