On October 14 and 15, 2026, an attacker used internal credentials belonging to the cloud platform Zeabur to move through its shared cluster, some dedicated servers, and its internal systems. According to BleepingComputer, those credentials were stored in plaintext. The attacker eventually read the production database.
The exposure covered 321,810 accounts and more than 3.2 million environment-variable records. Environment variables are where developers keep the keys to everything else: API tokens, database passwords, signing keys. Days later, Zeabur announced it will shut down.
This was the platform's second breach in two months, and the two are connected. The real lesson is not about one company's mistakes. It is about what happens when secrets sit in readable form, because a secret is data too, and it unlocks all the other data.
What Happened
Based on Zeabur's own disclosures and press coverage, the sequence looks like this:
- August 27: According to Zeabur's incident report, an attacker exploited a vulnerability (CVE-2026-7644) in a customer's NextChat service running on a shared cluster. That gave them code execution inside one container.
- Lateral movement: From that container, the attacker reached a routing cache over the cluster's internal network. The cache held legacy API keys, one of which belonged to a team administrator. That key exposed the environment variables of an internal management service, including AWS keys and a long-lived root key.
- The database: With AWS access, the attacker took control of a shared cluster and used a maintenance job's database credential to reach the production database. Zeabur lists account information and the names and values of project environment variables among the exposed data, including third-party AI API keys, cloud credentials, database connection details, and application signing keys.
- October 14 to 15: A second intrusion used leaked internal credentials. Zeabur says the attacker likely obtained them during the August breach, but has not confirmed that.
BleepingComputer reports that in the second incident Zeabur confirmed root sign-ins on 101 Google Cloud Platform (GCP) servers belonging to 92 users. The attacker also added SSH keys to 50 servers and attached 16 customer disk copies to virtual machines they controlled.
Why Plaintext Credentials Change the Outcome
BleepingComputer's account lists several failures, all described in Zeabur's own statement. Credentials were not stored in encrypted form. Not all administrator credentials were rotated after August. Administrator portals were reachable from the public internet. And in Zeabur's words, "the admin tokens had no expiry" and "had not been rotated since they were created in January 2024."
None of these is exotic. Each one is common in fast-growing engineering teams, where credentials are added to make something work and never revisited. Taken together, they meant that the August intruder's loot kept its value for weeks. A stolen key that never expires and never rotates is not a one-time loss. It is a standing invitation.
We should be fair here. Zeabur published a detailed account of both incidents, which is more than many organizations do. Reports also show that the company took response steps, such as disabling legacy API keys. The point of studying it is to see how a single exposed secret can compound, not to assign blame.
Secrets Are the Most Valuable Data You Hold
Teams often classify data by what it describes: a customer record, a patient file, a payment card. Secrets rarely appear in that classification. Yet a database connection string or a cloud access key is worth more to an attacker than any single record, because it is a master key to many records.
That is why the customer impact here extends well past Zeabur. Zeabur told users to replace every credential that was ever stored in a Zeabur environment variable and is still valid, even those not named in notices. Each customer then had to work through their own list: AI provider keys, cloud credentials, databases. One platform's breach became hundreds of thousands of separate cleanup projects.
We described the same pattern in The Sensitive Data Supply Chain. Every copy of sensitive data is another place for it to leak. Copies of secrets are no different, and they tend to be scattered across more places than anyone has counted: environment settings, backups, caches, build logs, and tickets.
There is also a detail worth noting. Zeabur's August report does not say whether environment variables were encrypted in its database, and BleepingComputer's coverage does not either. We do not know. But the question is the right one to ask of any platform that holds your secrets: if someone reads the database, what do they see?
Where the Chain Could Have Been Broken
The August attack crossed four system boundaries, by Zeabur's own count, moving from a customer container to a routing cache, an internal management service, and the production database. Each hop depended on something readable at the previous one. This is the useful way to read the incident. At every step, a protected secret would have stopped the next step, or at least made it noisy.
Perimeter thinking says to harden the first door. That matters, and the NextChat flaw was the first door. But the plan has to assume the first door will eventually open. The questions that follow are about what the attacker finds on the other side.
Five Questions to Ask About Your Secrets
- Where do secrets actually live? Inventory environment variables, caches, config files, backups, and CI systems. You cannot protect what you have not found.
- Are they encrypted where they are stored? A secret in a database or cache should not be readable by anyone who can read the storage layer.
- Do they expire? Zeabur recommends scoped access tokens with expiry dates in place of long-lived legacy keys. Short lifetimes shrink the value of any theft.
- Is rotation complete? After an incident, rotation has to cover every credential, not most. Zeabur has said that not all administrator credentials were rotated after August.
- Can a vendor's breach spread to you? If a platform holds your keys, assume a breach there is a breach of your systems, and plan the replacement steps ahead of time.
OnData's Take
The Zeabur incident shows how little it takes for one readable credential to turn a contained flaw into a platform-wide breach. Encryption of the network or the disk would not have changed what a logged-in attacker could see. What matters is whether the data, including the keys and the records they open, stays protected when a running system is compromised.
This is the idea behind data-centric security. OnData SecureDB applies runtime encryption and identity-based access control at the data layer, so reading a database is not the same as reading what is in it. OnData SecureFile does the same for files such as exported configurations, backups, and credential stores, and OnData SecureAI limits what analytics and AI workloads can see to what they need to know. For related thinking on agents and credentials, see Access Control Best Practices for Agentic AI.
A secret is only as safe as the weakest place it is stored. Protect the data, and the keys, so that a breach of the system is not a breach of everything it touched.
To see how this works in practice, you can book a demo.
