- Zeabur says an attacker used internal credentials that its August clean-up did not rotate, and read its platform database on October 14–15, 2026.
- The report shows that a partial key rotation leaves real exposure, and that a replacement key can be copied into backups.
- Customers should list every secret a platform holds, rotate on a schedule, and keep an exit plan for each vendor.
"We rotated everything" is an easy sentence to write after a security incident. It is a hard one to prove. Zeabur's own report on its October incident shows what happens when that sentence is almost true.
What happened
Zeabur is a developer hosting platform. On October 14–15, 2026, Zeabur says, an attacker used leaked internal credentials to get into its shared cluster, some Dedicated Servers and internal systems. The attacker then read the platform database.
This was Zeabur's second incident in under two months. BleepingComputer reports that the August incident began with a flaw in a customer's NextChat application. From there, attackers moved through internal systems that were poorly separated from each other.
BleepingComputer gives the scale of the October exposure as 321,810 user accounts and about 3.2 million stored settings records. These settings, called environment variables, often hold passwords and API keys. BleepingComputer adds that Zeabur plans to shut down, with services ending by December 31, 2026.
The keys the clean-up missed
Zeabur's August clean-up skipped two sets of secrets. One was the cluster's administrator tokens. The other was a set of AWS keys. Both sat as readable text in a private configuration repository. Root passwords in the setup files for its Google Cloud servers had also not been fixed. The attacker used exactly these credentials in October.
The August report had said "all internal admin keys have been disabled or rotated." Zeabur now calls that statement incomplete and corrects it.
The admin tokens never expired. They had not been changed since January 2024. Anyone on the internet could reach the shared cluster's management interface.
Zeabur cannot confirm how the attacker first got the credentials. It offers a hypothesis that this is linked to the August incident, and it says the hypothesis should not be cited as fact.
How the attack worked
Zeabur describes two paths that met inside its internal network. On the first, the attacker used the AWS keys from 01:36 UTC on October 14 and the cluster admin tokens from 01:40. By 12:39 the attacker was reading settings and secrets for all services. Later it ran read commands inside 865 database containers.
Zeabur says that among n8n instances using PostgreSQL, 602 of the 607 it checked kept their encryption key in an environment variable. So the third-party credentials stored in those n8n instances were effectively exposed as plain text.
The second path ran through Google Cloud. From 13:40 on October 14, the attacker logged in with full root rights to 101 Dedicated Servers that Zeabur managed there. The root passwords sat in plain text in server setup settings. On 50 servers the attacker added its own SSH keys. According to Zeabur, it also attached 16 copies of customer disks to virtual machines it created.
On October 15, the attacker added a node to Zeabur's internal network. Network rules let that node reach the platform database. Between 16:10 and 16:47, it read the database through 29 connections. Zeabur traced 8,903 operations.
Rotation that was copied into backups
One detail is worth a close read. Zeabur's daily cluster backups store all secrets. At 15:04 on October 15, the attacker read the access key for those backups.
Zeabur issued a fresh key at 15:40. The backup job that ran at 16:00 then stored that fresh key along with everything else. Zeabur confirms the attacker later used it, at 20:30. Whether the attacker actually downloaded that backup is Zeabur's own assessment, not a direct log entry.
The lesson here is that rotation is a process, not an event. If a new key lands in the same place as the old one, the clean-up can carry the exposure forward.
What the attacker was after
Zeabur says the attacker's commands point to a search for API keys it could use directly, especially for AI services. Commands went to stored logins in n8n and new-api/one-api across many instances. The attacker also tried Zeabur's AWS keys against Amazon Bedrock. Zeabur reports that all of those calls failed and nothing was billed.
Zeabur calls this an observation of intent only. Still, it shows why a stored AI key is a usable asset the moment it is exposed.
Who carries the cost
Customers carry it. Zeabur tells them to replace every credential stored on the platform, even ones changed after August. GitHub users should check audit logs for Zeabur app activity between 15:05 and 18:54 UTC on October 15.
One decision paid off. Zeabur says projects that had moved their settings onto servers they own after August were not part of what the attacker read in the platform database. A compromised host could still expose them.
Detection was the weak point. Zeabur says the attacker worked for more than 16 hours on October 14 without setting off a single alert. A user report led the team to the incident the following day.
BleepingComputer reports that Zeabur will disable renewals and pause shared-cluster services on December 1. Customers now face a migration on top of a clean-up. No concrete extension timeline has been given.
Questions for your team
Ask which secrets each hosting vendor holds for you, and whether any can be moved onto infrastructure you control. Ask whether your vendors' admin credentials expire, and whether your own do.
Ask where rotated keys end up, including backups. Ask how long an intruder could work in your systems before an alert fires. And ask whether you have a tested exit plan for each platform you depend on.
A clean-up is only as complete as the list it works from. Check the list before you trust the claim.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Zeabur.
