The Token That Never Rotated: Lessons from the Zeabur Breach for SaaS Teams

One Token, 3.2 Million Environment Variables

The Zeabur breach sounds like a typical ops oversight, but the problem it exposes is far more alarming for SaaS teams than "forgot to rotate a key": a cluster-admin token created in 2024 that was never rotated ultimately led to the exposure of 3.2 million customer environment variables.

This wasn't an external attacker breaking through some sophisticated defense line—it was a high-privilege key left sitting untouched in plain sight for an extended period. For any product that holds credentials on behalf of customers, the core question raised by this incident is simple: when what you store is someone else's secrets, do your internal ops practices live up to that trust?

Why "Never Rotated" Is a Structural Risk

What makes a cluster-admin token special is that it typically isn't bound to a single service—it spans permissions across the entire cluster. Once such a token exists long-term, it transforms from an "ops tool" into a "permanent backdoor"—no need for an attacker to plant it; it's already there.

Tokens that go unrotated for long periods create three overlapping layers of risk. First, an infinitely extended exposure window: as long as the token exists, any log leak, misdirected configuration, or accidental repo commit could let it escape—and once out, it remains valid for a long time. Second, ambiguous ownership: a token created two years ago often has no one who remembers why it exists, who uses it, or whether it can be deleted—so it's kept by default. Third, excessive permissions: a single leak of an admin-level token is equivalent to handing over control of the entire cluster.

These three factors compound to make "not rotated" no longer a small matter that can be deferred, but a continuously accumulating liability.

Cluster-admin token is one of the highest-privilege credential types in container orchestration systems like Kubernetes. It is typically bound to the cluster-admin ClusterRole and can perform arbitrary operations on all namespaces and all resources in the cluster, including reading Secrets, creating Pods, and modifying RBAC policies. Unlike namespace-scoped ServiceAccount tokens, it is not constrained by tenant boundaries—once leaked, an attacker can laterally read all customer data within the same cluster. For this reason, industry best practices require such tokens to either not exist long-term at all (use short-lived projected tokens or on-demand privilege escalation instead), or to strictly limit who can issue them and enforce short rotation cycles. The "permanent backdoor" mentioned in the article refers precisely to the fact that once such a high-privilege credential resides long-term, its very existence constitutes a persistent attack surface.

Three Blind Spots in How SaaS Teams Store Customer Secrets

What was actually read in this incident were customer environment variables. What goes into environment variables? Database connection strings, third-party API keys, payment credentials, internal service addresses. They are the lifeblood of customer businesses, yet they are often stored in plaintext in a centralized manner and managed uniformly by the platform.

The first blind spot is the single-point value created by centralization. To facilitate unified orchestration, the platform gathers the environment variables of tens of thousands of customers into the same infrastructure, which amplifies the payoff of a single privilege failure to the extreme—the number 3.2 million is itself a product of centralization.

The second blind spot is no one owns the credential lifecycle. When customers manage their own keys, there is at least some motivation to rotate; once handed to the platform, rotation responsibility becomes ambiguous—the platform doesn't proactively do it, and customers have no way of knowing.

The third blind spot is the normalization of high-privilege accounts. Admin tokens are used for daily operations and, over time, are regarded as "normal tools," losing the sensitivity label they deserve.

Environment variables are a key-value mechanism through which operating systems and container runtimes pass configuration to processes, originally intended to let applications read runtime parameters conveniently. But in modern SaaS architectures, they are often used as lightweight secret storage—database connection strings, API keys, and payment credentials are all injected into containers directly as environment variables. The problem is that environment variables exist in plaintext by default in process memory, container configuration manifests, and the orchestration system's Secret objects, with neither encryption protection nor fine-grained access auditing. For platform operators, the environment variables of tens of thousands of tenants are often concentrated in a handful of Secret stores or configuration centers—once a read interface is called by a high-privilege token, they can be exported in bulk. This is why "3.2 million" became the direct result of a single read operation—centralized storage amplifies the payoff of a single point of failure.

Actionable Defense Strategies

For incidents like this, defense should not stop at the slogan "remember to rotate"—it must be implemented at the mechanism level.

Give every token clear ownership and an expiration time. Long-lived tokens with no owner and no expiration date should be prohibited by default, not allowed by default. Admin-level credentials in particular should be short-lived and traceable.

Replace privilege convenience with least privilege. Daily operations should not directly hold cluster-admin permissions. On-demand temporary privilege escalation, revoked immediately after use, can downgrade "one token compromised = total compromise" to localized impact.

Treat customer secrets as encrypted assets, not configuration text. If centrally stored environment variables exist in searchable plaintext, a leak equals plaintext delivery. Layered encryption and access auditing add a barrier between "read" and "understood."

Build detection capability for anomalous reads. If 3.2 million environment variables were read without triggering any alert, it shows the platform lacks basic awareness of "who is reading customer credentials in bulk."

Least privilege and just-in-time elevation are the core mechanisms for limiting the blast radius of high-privilege credentials. Specific practices include: using read-only or namespace-scoped accounts for daily operations; when high-risk operations are needed, temporarily obtaining short-lived admin credentials through an approval process and revoking them immediately after completion; recording and reviewing grants of cluster-admin permissions to avoid long-term binding. Complementing these is credential rotation—setting a mandatory expiration time for every token, automatically invalidating it on expiry and requiring reissuance, so that "forgotten tokens" cannot persist long-term at the mechanism level. The common goal of these measures is to downgrade "one token compromised = total compromise" to a localized, controllable scope of impact.

A Reminder for the Industry

According to the original disclosure, the cause of this incident was remarkably plain: a cluster-admin token created in 2024 that was never rotated. No zero-day vulnerability, no advanced persistent threat—just one forgotten high-privilege credential.

This is precisely the hardest class of problem to defend against, because it doesn't depend on the attacker's skill—it depends on the defender's discipline. For SaaS products that hold credentials on behalf of customers, the real security baseline isn't "do we encrypt" but "can we clearly state the origin, purpose, and lifespan of every high-privilege token." If you can't, then the number 3.2 million could easily recur with a different subject at any time.

When customers hand you their secrets, it is fundamentally a delegation of trust. Tokens expire; trust does not renew automatically.