Zeabur has confirmed yet another security incident, and it came less than seven weeks after the Aug. 27 intrusion. According to the company’s status page and a user notice cited in the report, this latest attack started inside a legacy shared cluster that was already on its way out, then spread into Zeabur’s own operational database.
The company said the leaked data includes environment variables linked to user services, account information, API tokens, and API keys for its mail service zSend. Some dedicated servers hosted on Google Cloud and operated by Zeabur were also accessed without authorization.
Attack window and revised disclosures
Per a user notice obtained by the community and cited in the report, the incident happened between 9 p.m. on Oct. 14 and 1 a.m. on Oct. 15. Zeabur then rewrote its public description of what happened within just a few hours on Oct. 16.
At 00:08, the first status page notice said only self-managed PostgreSQL and MySQL deployments on an old shared cluster had been accessed without authorization. It also said there was no evidence that dedicated servers had been affected.
About 4 hours and 40 minutes later, at 04:48, Zeabur updated the statement and said "the incident is broader than initially reported." The company also said the attacker had read access to its database. Then came another update at 07:33. That one said a large-scale internal credential rotation had briefly disrupted some features, although most had already recovered.
What users are being asked to do
Zeabur said users should take the following steps even if they got a notice saying their services were not accessed:
- Sign in again, because Zeabur has rotated the signing key for login sessions.
- Rotate all secrets stored in environment variables, including API keys and database passwords, and generate new Zeabur API tokens.
- Create new API keys if they use zSend or Zeabur Email. The old keys have all been revoked.
- For Google Cloud dedicated servers, change the root password and delete any unrecognized SSH keys, especially one labeled "zeabur-pentest."
- Redeploy any services whose deployment failed during the incident window.
For affected Google Cloud dedicated servers, external SSH access has been temporarily restricted to web-based SSH, while running services remain unaffected. Zeabur told users to remove the SSH key named "zeabur-pentest" but has not said who put it there.
Why the shared cluster is back in focus
The shared cluster belongs to Zeabur’s older architecture and has already been heading toward retirement. In an offboarding notice dated Feb. 23, the company said users would no longer be able to create new projects on shared clusters starting March 15, and would no longer be able to add services to existing projects starting April 1. Services already running there could keep running.
In its changelog, Zeabur wrote: "Even if you choose not to migrate, we will ensure these services continue to run safely and stably. This is our commitment to existing users, without exception."
The August incident also led back to the shared cluster. That incident report said the attacker got in through a NextChat service deployed by a user on the Tokyo shared cluster, exploited CVE-2026-7644, obtained AWS root keys, and read environment variables from the production database. The report said, "Although the shared cluster and Legacy API Key are already in the retirement phase, we should still ensure sufficient isolation and access restrictions before they are shut down."
On Sept. 7, Zeabur rolled out what it called a major security upgrade. Users got the option to delete SSH passwords and private keys stored by Zeabur, and to move environment variables onto servers so Zeabur’s database would no longer keep a copy. The changelog said those upgrades applied only to dedicated servers. Shared-cluster users were told to move to dedicated servers, and the migration had to be done by users themselves.
Zeabur has not said whether this latest incident followed the same route as the August breach. Its status page said only that known attack vectors had been blocked and the root cause was still being investigated. The user notice said the attacker obtained administrative credentials for the shared cluster.
What seems plain enough so far: both incidents were tied to the shared cluster that was being phased out, and both reached into Zeabur’s own database. This time, some dedicated servers were hit too.
Three questions still unanswered
How many users were affected, and how broad was the leak?
Zeabur has not disclosed how many users were affected. It said only that impacted customers would be contacted directly. And it still has not explained whether the leaked environment variables were limited to projects that had not yet migrated.
Will there be compensation?
After the August incident, Zeabur’s status page said that by the end of that month about 63% of compensation claims had been verified. Those claims covered costs caused by stolen AI API keys, including keys tied to OpenAI, Anthropic, Gemini, and OpenRouter. The company has not said whether the latest case will be handled the same way.
Why did the user notice differ from the status page?
The user notice said: "The currently confirmed impact is limited to the shared cluster, and no related anomalies have been found on dedicated servers." That matched the first public notice on the status page. But not the corrected version posted at 04:48 on Oct. 16, which acknowledged that some Google Cloud dedicated servers had also been accessed.