Development platform Zeabur disclosed that it is shutting down after a second security breach in two months. In the latest incident, an attacker used leaked internal credentials stored in plaintext to compromise the platform’s infrastructure and steal over 3.2 million environment-variable records along with information for 321,810 accounts. According to the company’s preliminary report, the attacker used those credentials around October 14–15, 2026 to reach the shared cluster, some dedicated servers, and internal systems, and eventually read the platform database.
Read that back slowly, because every clause is a lesson. The way in was not a zero-day. It was a credential that was stored in plaintext, that was long-lived enough to still work when it leaked, and that had standing access to the systems holding customer data. The thing the attacker walked away with — 3.2 million environment-variable records — is itself a mountain of other people’s secrets: API keys, database passwords, cloud tokens, and third-party credentials that customers had placed in Zeabur to run their apps.
This is the single most common shape of a breach there is, and it is almost entirely preventable. This post is not a eulogy for one platform. It is a practical guide to the standing-secret problem — why it keeps ending companies, and the concrete steps that make a leaked credential close to worthless.
What Actually Happened
Separate the incident into stages, because the fix lives in the ones most teams underinvest in.
Stage one — credentials stored in plaintext. Internal credentials existed somewhere an attacker could read them without decrypting anything. Plaintext secrets are the oldest unforced error in security, and they persist because they are convenient: a password in a config file, a token in an environment variable, a key in an internal wiki or a shared note. They work on the first try, for everyone, including whoever shouldn’t have them.
Stage two — the credentials were long-lived and still valid. A leaked secret only matters if it still works when someone finds it. These did. There was no short expiry forcing the attacker to race a clock; the credential was a durable key.
Stage three — the credentials had standing access to everything that mattered. Once used, the credentials reached the shared cluster, dedicated servers, internal systems, and ultimately the database. The access was broad and always-on, so a single working credential unlocked the crown jewels.
Stage four — the crown jewels were themselves secrets. A platform that stores customer environment variables is holding a concentrated vault of other people’s credentials. Exfiltrating 3.2 million env-variable records does not just harm Zeabur; it cascades to every customer whose API keys, database URLs, and cloud tokens were in those records — which is why the remediation guidance to affected users is to rotate secrets and migrate before a hard deadline.
Hold those stages apart, because they call for different defenses. You can spend enormous effort trying to ensure no credential ever leaks (stage one) and still occasionally lose one. Stages two and three — how long a credential lives and how much it can reach — are where you actually decide whether a leak becomes a breach.
Why Standing Secrets Keep Ending Companies
If plaintext, long-lived, broadly-scoped credentials are such a well-known problem, why do they keep causing the biggest incidents? Three reasons, all fixable.
1. Secrets sprawl faster than anyone tracks. Credentials multiply across config files, environment variables, CI/CD settings, container images, internal docs, and chat history. Each copy is a new place to leak from, and almost no one has a complete inventory of where their secrets actually live. We have written about this dynamic in what is secrets sprawl — the short version is that the number of places a given secret exists is almost always higher than the team believes.
2. “Temporary” credentials become permanent. A key is created for a migration, a one-off integration, or a debugging session. The task ends; the key does not. Years later it is still valid, still broadly scoped, and still sitting in a file nobody remembers. When one of those leaks, the attacker inherits all of it.
3. Scoping is tedious, so access is granted broadly. Giving a credential narrow, time-boxed access by hand is slow and annoying. Giving it durable, generous access is fast. So teams default to broad grants, and that breadth sits as latent risk until the day a credential leaks — at which point the breadth becomes the blast radius.
Every one of these is the same underlying issue wearing a different hat: a secret that keeps working, scoped to far more than the moment needs, sitting somewhere it can be read. A credential that only worked for the few minutes it was genuinely needed, scoped to one task, would have given the Zeabur attacker almost nothing. A credential that works forever against everything is a standing invitation.
The Immediate Checklist
Whether or not you use the affected platform, these are the steps that directly address the Zeabur pattern. If you are an affected Zeabur customer, start at step one today — the guidance is explicitly to rotate and migrate before the stated deadline.
1. Rotate anything that could have been exposed
If your secrets lived in a platform that was breached, treat every one of them as compromised and rotate it: API keys, database passwords, cloud access keys, third-party tokens, signing keys. Rotate first, investigate second. A credential you think might be fine but cannot prove is a credential you should assume is burned.
2. Find your plaintext secrets
Run secrets detection across the places credentials actually accumulate — repositories, CI/CD configuration, container images, environment files, and internal documentation. Tools like gitleaks and trufflehog, or your code-security scanner’s secret detection, will surface hardcoded tokens and credential files that should not exist. This is the inventory step, and it is almost always more revealing than teams expect. For the method, see our guide to stopping secrets leaking in Git and the broader secret scanning guide to prevent data breaches and leaks.
3. Stop storing secrets in plaintext anywhere
Move credentials out of config files and environment variables that sit on disk, and into a managed secret store or — better — a model that mints credentials on demand so there is no at-rest plaintext secret to steal. Encryption at rest is a floor, not a ceiling: a decryption key stored next to the data it protects buys you nothing.
4. Shorten credential lifetime everywhere you can
This is the highest-leverage single change. A credential that expires in minutes is nearly useless to whoever finds it in a leaked dump weeks later. Replace long-lived access keys with short-lived, auto-expiring credentials wherever your platforms support it — SSO session tokens instead of static keys, instance profiles and managed identities instead of embedded credentials, and brokered short-lived grants for privileged access.
5. Scope every credential to the task, not the person or system
Audit what each remaining credential can actually reach. A key that only needs to read one bucket should not be able to touch the whole account. Narrow scope converts a leaked credential from “keys to the kingdom” into “keys to one small, well-understood thing.”
The Structural Fix: Make the Secret Not Worth Stealing
Notice that most of the checklist is damage control — scanning for leaks, rotating exposed keys, moving plaintext into a vault. Those are necessary, but they all assume the dangerous object (a long-lived, broadly-scoped credential) exists and you are managing its risk. The deeper move is to make sure that object does not exist in the first place.
That is the idea behind just-in-time access. Instead of issuing a standing credential that sits in a config file, in a secret store, and in three backups, you flip the model: the human or system requests access at the moment it is needed, receives a tightly-scoped credential for a short window, and that credential expires on its own.
Walk the Zeabur stages back through that model:
- Stage one (plaintext at rest) mostly disappears. There is no long-lived secret sitting in a file to be stored in plaintext, because the credential is minted on demand and discarded.
- Stage two (still-valid-when-leaked) is neutralized. A credential that auto-revokes in minutes is dead long before it shows up in a dump. The attacker’s clock runs out before they can use it.
- Stage three (standing broad access) is removed. The credential is scoped to the specific task and window, so even a live one opens a small, well-understood door rather than the whole platform.
Here is how Cloud JIT implements this for cloud consoles and roles. The lifecycle is deliberately simple — request → approve → time-boxed grant → auto-revoke — and it applies across every surface where standing access tends to pile up.
Grants expire on their own, so there is nothing durable left behind for an attacker to find later:
The same pattern extends to the surfaces that matter most for a story like this. For the databases that hold the actual records, Database JIT replaces standing database credentials with short-lived, scoped, approval-gated access — directly relevant when the crown jewels are a database full of customer data. For the automated identities that run your pipelines and integrations — the exact category of “internal credential” that leaked here — the same short-lived model applies to service accounts and non-human identities instead of embedding a permanent key in CI/CD. And because JIT runs inside the broader CNAPP+ platform alongside posture and identity, an identity that CIEM flags as over-privileged feeds directly into tightening its access — so “this service account can reach too much” leads straight to “so it should not hold that reach when it is idle.”
Being Honest About What JIT Does and Does Not Do
We would rather you deploy this understanding the boundary.
What JIT genuinely prevents: the standing-secret blast radius. It removes the long-lived, broadly-scoped credential that turns a leak into a breach. A credential that is minted on demand, scoped to one task, and auto-revoked in minutes is close to worthless to whoever exfiltrates it later. This is the single highest-leverage change against the most common breach pattern in existence.
What JIT does not do: it does not magically clean up the secrets already sprawled across your estate, and it does not replace secret scanning or good hygiene. You still need to find and rotate existing plaintext credentials, still need detection on the endpoints and repos where secrets land, and still need encryption and access controls on the stores you keep. Think of secret scanning as finding the leaks you already have, and JIT as making sure you stop manufacturing new long-lived secrets to leak.
Being precise about this is deliberate. We are not promising that no credential will ever leak. We are describing how to make the inevitable leak a non-event instead of a shutdown notice.
Key Takeaways
- Plaintext, long-lived, broadly-scoped credentials are the breach. The Zeabur incident is the textbook shape: a readable secret that still worked and could reach everything.
- A platform that stores customer secrets is a concentrated vault. The 3.2M exfiltrated env-variable records cascade risk to every customer — rotate and migrate if you are affected.
- Scanning and rotating are damage control. Necessary, but they manage the risk of a dangerous object instead of removing it.
- Short-lived, scoped, on-demand access removes the object. JIT makes a leaked credential expired and narrow — worthless to whoever finds it later.
- The same model covers humans, databases, and non-human identities. Standing secrets accumulate everywhere; the fix applies everywhere.
Want to see where standing secrets and over-permissioned identities are accumulating in your environment — and how short-lived access takes them off the table? Book a session and we will map it with you.
People Also Read
- 24,000 Secrets in MCP Config Files: Why AI Agents Need JIT, Not Key Vaulting
- Hackers Are Scanning for Exposed Vite Dev Servers to Steal AWS and Azure Secrets
- Eliminating Standing Cloud Access for SOC 2 and ISO 27001
- A Big List of Popular Data Breaches and What Your CloudOps Team Can Learn
- What is Secrets Sprawl?
- What is IAM Just-In-Time (JIT) Access?
- Cloudanix: Just-in-Time Access
