Zeabur's Fatal Second Breach: How Plaintext Credentials and Unrotated Tokens Brought Down a Cloud Platform
Executive Summary
In October 2026, cloud developer platform Zeabur suffered its second major security breach within two months. Attackers leveraged plaintext administrator credentials and cloud access keys—likely stolen during a prior August 2026 breach—to compromise shared hosting clusters across nine global regions, 321,810 user accounts, and approximately 3.2 million environment-variable records. Threat actors gained root access to 101 GCP servers, added SSH keys to 50 servers, and attached 16 customer disk copies to attacker-controlled virtual machines. The root cause included unrotated admin tokens created in January 2024, publicly accessible admin portals, and credentials stored in plaintext. Following this second breach, Zeabur announced a full platform shutdown by December 31, 2026.
This incident highlights an accelerating pattern of credential-reuse attacks targeting cloud-native developer platforms. As organizations consolidate infrastructure on shared PaaS environments, unrotated secrets, plaintext credential storage, and overly permissive admin interfaces create compounding blast radii. Regulatory scrutiny of cloud platform providers is intensifying, making credential hygiene and zero-trust segmentation urgent priorities across the industry.
Why This Matters Now
Developer platforms aggregate secrets, API keys, and environment variables for thousands of tenants simultaneously, making them high-value targets. The Zeabur incident demonstrates that a single unrotated credential set can cascade into a multi-region, multi-tenant catastrophe. With cloud-native deployments growing and attacker tooling increasingly automating credential harvesting at scale, organizations must enforce secret rotation, eliminate plaintext credential storage, and restrict admin portal exposure immediately—before a second breach becomes a permanent shutdown.
Attack Path Analysis
An attacker leveraged plaintext internal credentials stolen during Zeabur's August 2026 breach to authenticate directly into shared cluster infrastructure and GCP servers, bypassing all perimeter controls due to publicly exposed administrator portals and non-expiring admin tokens. The attacker escalated privileges using stolen cloud access keys and administrator tokens, moved laterally across nine regions and 101 GCP servers, and ultimately exfiltrated over 3.2 million environment variable records and 321,810 account records from the production database, forcing the company to shut down.
Kill Chain Progression
This analysis maps confirmed threat intelligence to the full cloud kill chain to show where defensive gaps would emerge as an attack progresses.
Initial Compromise
Description
The attacker used plaintext Zeabur internal credentials obtained during the August 2026 breach to authenticate into Zeabur's shared cluster and internal systems. Administrator portals were publicly internet-accessible with no MFA or access restriction, and admin tokens had not been rotated since January 2024, providing a direct entry path requiring no exploitation of new vulnerabilities.
MITRE ATT&CK® Techniques
Valid Accounts
Unsecured Credentials: Credentials In Files
Account Manipulation: SSH Authorized Keys
Data from Cloud Storage
Cloud Storage Object Discovery
Transfer Data to Cloud Account
Cloud Infrastructure Discovery
Domain or Tenant Policy Modification
Potential Compliance Exposure
Mapping incident impact across multiple compliance frameworks.
NIST SP 800-53 Rev 5 – Authenticator Management
Control ID: IA-5
PCI DSS 4.0 – Manage System and Application Accounts / Credential Rotation
Control ID: Requirement 8.3.9 / 8.6.1
DORA (Digital Operational Resilience Act) – ICT-Related Incident Management / ICT Third-Party Risk
Control ID: Article 10 / Article 17
NIS2 Directive – Policies on Risk Analysis and Information System Security / Access Control
Control ID: Article 21(2)(a) / Article 21(2)(i)
CISA Zero Trust Maturity Model 2.0 – Privileged Credential Lifecycle Management and Micro-Segmentation
Control ID: Identity Pillar — Credential Management / Network Pillar — Segmentation
GDPR (General Data Protection Regulation) – Security of Processing / Notification of Personal Data Breach
Control ID: Article 32 / Article 33
Sector Implications
Industry-specific impact of the vulnerabilities, including operational, regulatory, and cloud security risks.
Information Technology/IT
Developer hosting platforms like Zeabur face critical cloud misconfiguration and credential theft risks, exposing 3.2M environment variables and 321,810 accounts due to plaintext secrets and unrotated admin tokens.
Computer Software/Engineering
Software teams relying on deployment pipelines face severe lateral movement and exfiltration risk when shared cluster credentials remain unrotated, enabling attackers to pivot across nine regions and attach customer disk copies.
Internet
Cloud-native hosting services lacking Zero Trust segmentation and egress policy enforcement allow attackers with valid stolen credentials to traverse workloads, compromise GCP servers, and exfiltrate production database records at scale.
Computer/Network Security
Security vendors must address post-initial-access gaps where valid credential abuse bypasses prevention controls, as validated multicloud visibility and east-west traffic segmentation failures enabled unchecked attacker movement across infrastructure.
Sources
- Zeabur shutting down after second security breach in two monthshttps://www.bleepingcomputer.com/news/security/zeabur-shutting-down-after-second-security-breach-in-two-months/Verified
- Zeabur October 2026 Security Incident Disclosurehttps://zeabur.com/blogs/october-2026-security-incidentVerified
- Zeabur August 2026 Security Incident Disclosurehttps://zeabur.com/blogs/august-2026-security-incidentVerified
- Zeabur Shutdown Announcementhttps://zeabur.com/blogs/zeabur-is-shutting-downVerified
- CISA Known Exploited Vulnerabilities Cataloghttps://www.cisa.gov/known-exploited-vulnerabilities-catalogVerified
Frequently Asked Questions
Cloud Native Security Fabric Mitigations and ControlsCNSF
Based on the attack progression modeled above, these are the defensive controls that would constrain each stage.
Aviatrix Zero Trust CNSF is directly relevant to this incident because the attacker exploited flat network architecture, publicly exposed portals, and unconstrained east-west access to move freely across 101 GCP servers and nine regions. Identity-aware segmentation and controlled egress enforcement would likely have reduced the attacker's reachability and contained the blast radius before mass exfiltration was possible.
Control: Cloud Native Security Fabric (CNSF)
Mitigation: CNSF-enforced perimeter policy would likely constrain direct internet reachability of administrator portals, reducing the attacker's ability to authenticate into internal systems from unapproved external sources using stale credentials.
Control: Zero Trust Segmentation
Mitigation: Zero Trust segmentation would likely reduce the operational scope of over-privileged credentials by constraining which workloads and cloud resources a given identity is permitted to reach, even after authentication succeeds.
Control: East-West Traffic Security
Mitigation: East-west traffic enforcement would likely constrain the attacker's ability to pivot freely across regional clusters and shared servers, reducing the number of workloads reachable from any single compromised node.
Control: Multicloud Visibility & Control
Mitigation: Centralized multicloud visibility would likely surface the unusual pattern of root sign-ins and SSH key injection events across regions, reducing how long the attacker could maintain undetected interactive control over compromised infrastructure.
Control: Egress Security & Policy Enforcement
Mitigation: Egress policy enforcement would likely constrain the attacker's ability to move staged data out of the cloud environment to unrecognized destinations, reducing the volume of secrets and account records that could be successfully exfiltrated.
Had earlier segmentation and egress controls reduced attacker reachability, the scope of exposed customer secrets and the number of compromised servers would likely have been meaningfully smaller, constraining the breadth of data at risk and potentially preserving enough operational integrity to avoid a full platform shutdown.
Impact at a Glance
Affected Business Functions
- Developer Hosting and Continuous Deployment Pipelines
- Environment Variable and Secrets Management
- Cloud Infrastructure Provisioning (GCP and AWS)
- Customer Account and API Key Management
Estimated downtime: 78 days
Estimated loss: N/A
Approximately 3.2 million environment variable records were exfiltrated, exposing application secrets, API keys, database connection strings, and other sensitive configuration data belonging to developers and their downstream applications. Account information for 321,810 users was accessed from the production database. Attackers confirmed root-level sign-ins on 101 GCP servers across 92 users, added SSH keys to 50 servers, and attached 16 customer disk copies to attacker-controlled virtual machines, enabling potential full extraction of customer workload data. The August 2026 breach additionally exposed AWS credentials and API keys. The combined exposure affects downstream customer applications and services that relied on Zeabur for secret storage, representing a broad third-party supply chain risk for the developer community using the platform.
Recommended Actions
Key Takeaways & Next Steps
- • Enforce Zero Trust Segmentation across shared cloud infrastructure: Zeabur's flat shared cluster architecture allowed unchecked east-west movement across nine regions. Deploying identity-based microsegmentation with least-privilege workload-to-workload policies (CNSF Zero Trust Segmentation) would have contained the breach to the initially compromised node, blocking lateral movement to 101 GCP servers and preventing cross-region pivot.
- • Apply Egress Security and Policy Enforcement to block unauthorized data exfiltration: The absence of outbound traffic controls allowed the attacker to attach customer disk volumes to external VMs and exfiltrate 3.2 million records undetected. CNSF Egress Security with FQDN filtering and data loss prevention policies would have blocked unauthorized outbound transfers and flagged anomalous cloud storage copy operations before exfiltration completed.
- • Implement Multicloud Visibility and Control for anomaly detection across all regions: Root sign-ins on 101 servers by 92 users and mass SSH key injection events would have been detectable as high-severity anomalies under centralized traffic observability and behavioral baselining. CNSF Multicloud Visibility enables real-time alerting on suspicious cross-region administrative actions and control plane abuse patterns.
- • Secure East-West Traffic with workload identity enforcement: The attacker moved freely between shared clusters and dedicated servers because internal service-to-service communication was not authenticated or inspected. Enforcing east-west traffic security with workload identity verification would have required cryptographic proof of identity for every internal connection, limiting the blast radius of the stolen credentials to authorized communication paths only.
- • Deploy Cloud Firewall with inline IPS to restrict administrative surface and detect exploit traffic: Public internet exposure of administrator portals with non-expiring tokens created an indefinitely open attack surface. A Cloud Firewall with Inline IPS (Suricata) would have restricted admin portal access to verified sources, detected anomalous login volumes, and provided the signature-based inspection layer needed to identify malicious payload delivery and unauthorized administrative automation across the multi-cloud environment.
