Developer platform Zeabur has disclosed a new cybersecurity incident and said it plans to shut down after suffering its second breach in two months. According to the company’s disclosure, the attacker used leaked internal credentials that had been stored in plaintext, then accessed internal infrastructure and exfiltrated more than 3.2 million environment variable records as well as information related to 321,810 accounts.

For European businesses using cloud application platforms, the incident is a reminder that third-party developer services can become a single point of failure. When platforms handling deployment, hosting, secrets, and operational access are compromised, the impact can extend well beyond the provider itself.

What happened

Based on the company’s published account, the breach involved internal credentials that were exposed in plaintext. Zeabur said the attacker used those credentials to compromise its infrastructure and access a large volume of sensitive records, including environment variables. In many modern application environments, environment variables may contain API keys, database credentials, tokens, service endpoints, and other operational secrets.

The report is particularly notable because it follows another security incident affecting the same provider within a short period. Zeabur has said it will shut down following this second breach. While the company has disclosed the broad scope of the incident, businesses should rely on official notices from the provider for details on exactly what data or systems in their own accounts may have been affected.

Why it matters for European businesses

This is not only a supplier breach story. It is also a business continuity, access control, and secret management issue.

If a platform stores or processes deployment secrets, the exposure of environment variables can create a wider compromise path into customer systems. Depending on how customers used the platform, leaked secrets could potentially allow access to cloud infrastructure, databases, third-party SaaS tools, payment or messaging services, internal APIs, and production applications.

For European SMEs, startups, software teams, and e-commerce businesses, this matters because many rely on external platforms to simplify hosting and deployment. The convenience of platform-based development can also concentrate operational risk. If a provider is breached or shuts down, customers may face both immediate security work and urgent migration pressure.

The case also raises governance questions for companies that must demonstrate supplier oversight, incident response readiness, and appropriate technical controls around privileged access and secrets. For some regulated businesses, third-party security incidents can trigger contractual, internal governance, or regulatory assessment obligations depending on the nature of the exposed data and services involved.

Who may be affected

• Current Zeabur customers that stored application secrets, API tokens, or operational credentials in environment variables.
• SMEs and startups using developer platforms as a lightweight alternative to managing their own infrastructure.
• E-commerce and SaaS businesses whose production systems depend on hosted deployment pipelines or platform-managed secrets.
• IT and security teams responsible for third-party risk, cloud access, identity, and incident response.
• Regulated organisations that need to assess whether any affected systems processed personal data or supported critical business functions.

What companies should consider

• Identify exposure quickly. Confirm whether your organisation used Zeabur, which projects were hosted there, and whether sensitive environment variables were stored on the platform.
• Rotate secrets as a priority. If there is any possibility that environment variables contained credentials, rotate API keys, database passwords, access tokens, signing secrets, and service-account credentials without delay.
• Review downstream access. Check whether exposed secrets could provide access to cloud consoles, production workloads, source repositories, customer databases, analytics tools, email systems, or payment-related integrations.
• Audit logs and unusual activity. Look for suspicious authentication attempts, configuration changes, unexpected deployments, or abnormal API usage after the suspected exposure window.
• Prepare for platform exit. Because the provider has said it will shut down, customers should review migration plans, backups, deployment pipelines, DNS dependencies, and service continuity arrangements.
• Strengthen secret management. Avoid storing high-value secrets in places with broad internal access where possible. Consider dedicated secret vaults, short-lived credentials, role-based access, and tighter separation between build, deployment, and production privileges.
• Reassess supplier risk. Review whether developer and hosting suppliers have appropriate controls for credential handling, encryption, logging, and incident response. This is especially important for businesses with lean internal IT resources.
• Assess legal and contractual implications. If personal data, customer systems, or critical operations may have been affected, involve legal, compliance, and security stakeholders to determine notification and documentation requirements.

For European businesses, the main lesson is broader than a single provider’s failure: platforms that manage application deployment and secrets should be treated as high-trust suppliers. Their security posture, credential handling practices, and resilience planning can have direct consequences for customer operations, data security, and service continuity.