Back to blog

Zeabur breach: why credential rotation needs an attack-path review

3 min read
Zeabur breach: why credential rotation needs an attack-path review

Sources checked: . FailSafe Research.

Replacing the credential you know about is only the start of recovery. Zeabur’s October disclosure describes a broader problem: connected administrative identities, stored secrets and infrastructure access can let an intruder keep moving.

What the preliminary report establishes

Zeabur’s preliminary report describes unauthorized access on 14–15 October using leaked internal credentials. It reports access to shared clusters, some dedicated servers and the platform database, including approximately 3.2 million environment-variable records and 321,810 accounts. The company identifies long-lived plaintext administrative credentials and public administrative access as root-cause factors. It also says the earlier rotation did not cover credentials used in this incident.

The report distinguishes logged observations from assessments and gaps in telemetry. An account count is not a count of independently verified downstream compromises. This article follows the vendor’s evidence categories rather than converting every potentially exposed record into a confirmed victim.

Draw the credential dependency graph

For your environment, list each credential’s issuer, storage locations, privileges and consumers. Include backups, deployment settings, administrative tools and recovery systems. A key may authorize access to another secret store, which can reveal a second credential with a different lifetime.

That graph changes the rotation plan. If an untrusted host can still read the replacement, issuing a new key there may repeat the exposure. Identify the systems that must first be isolated or rebuilt, then revoke old access and introduce replacements through a trusted path.

What a cloud assessment should demonstrate

  • A revoked administrative identity cannot authenticate through an overlooked region or interface.
  • A low-privilege service cannot read unrelated tenants’ secrets or infrastructure backups.
  • Administrative endpoints enforce the intended network and identity restrictions.
  • Changes to access are recorded in a log an intruder cannot quietly rewrite.

Exercise these controls with synthetic credentials in a designated environment. Preserve the expected policy, observed result and any exception. Do not test a provider’s live infrastructure without its authorization.

The FailSafe assessment angle

SWARM can investigate agreed cloud, application and identity boundaries as a connected workflow. The question for an enterprise buyer is whether a finding demonstrates a reachable privilege transition and identifies its owner. Ask for a retest of the original path after remediation, alongside proof that old credentials have been revoked.

Our Railway analysis covers a separate secrets incident. Together they make a useful review agenda, without implying that the incidents share an attacker or cause.

Explore the October incident collection for related cases and existing FailSafe coverage. Incident descriptions are attributed to the linked sources; assessment recommendations are FailSafe’s analysis. We have not conducted forensic investigations of these incidents.

Questions & answers

Questions about this topic

Direct answers to common questions about this page.

No. Revocation must happen at the issuer. Replacement also requires updating legitimate consumers and checking that the new credential is not exposed through an untrusted system.

No. Exposure of records and demonstrated misuse in a customer system are different evidence states.

Put this guidance to work

Discuss a scoped FailSafe SWARM assessment with reproduced findings, engineering handoff and remediation retesting. Containment and forensic investigation remain separate workstreams.

Test the boundary that matters