Zeabur

Risks & limits

Shutdown timeline. The October 17 notice says purchases of new dedicated servers and domains stopped at once; from December 1, dedicated servers stop renewing and shut down on their own expiry dates, and all running services on shared clusters are suspended but can be restarted by hand to back up data; on December 31 all dedicated servers and shared clusters stop; the data deletion date, final data export deadline and Zeabur Support closing date "have not yet been finalized" and will be announced once confirmed. The October 22 notice instead says that paid plans also stop renewing from December 1, that on December 31 all services stop and service data is deleted, and that dedicated server data is deleted on each server's expiry date, which may come before December 31. The two official notices disagree on when data is deleted. The migration guide says servers rented through Zeabur belong to Zeabur's cloud account and are deleted at expiry, disks included.

Deadlines and refunds. The October 22 notice gives November 30 as the recommended migration date, in its words "Recommended deadline: complete all migration by November 30", to leave time to confirm the new environment works. The same day is a hard deadline: balance refund requests and security incident claims must each be filed through Zeabur Support by then; after that, balance refunds can only be requested by email and claims are no longer accepted. The refund is the remaining balance after final settlement, capped at the cash actually paid, so promotional credit is not refunded; accounts that run through the end of December should be paid by January 10, 2027. If the original payment method cannot be used, payment goes through the partner Tremendous.

The August incident. A report on September 7 says that on August 27 an attacker used CVE-2026-7644 in a NextChat v2.16.1 service a user had deployed on the shared cluster to gain code execution, reached a Legacy API Key in the routing cache over the shared cluster's internal network, read an AWS root key from an internal management service's environment variables, and finally used a maintenance job's private network link and database credential to read project environment variables in the production database, including third-party API keys, cloud credentials and database passwords. Zeabur sent the first notice on August 28 16:53 (UTC+8), asking affected users to rotate credentials; all Legacy API Keys have been disabled.

The October incident. A preliminary report on October 19 says the attacker used internal credentials that were stored in plaintext and never expired to enter the shared cluster, some GCP dedicated servers and internal systems; activity began on October 14 09:36 (UTC+8) and the last record is October 16 05:05 (UTC+8). The report's table of data involved lists as confirmed, in the platform database, 3,218,965 service environment variable records (names and values); account data such as email, username and phone number, plus project, environment and service data, for 321,810 accounts; and 566 zSend API keys stored in plaintext, since revoked; the attacker ran commands in 865 database services, not all of which succeeded, and logged in as root to 101 GCP dedicated servers, and the tokens that manage Hetzner and DigitalOcean servers leaked with the database. The report places the root cause with Zeabur: long-lived admin credentials stored in plaintext and usable from the public internet. Zeabur asks users to replace every password and key stored on Zeabur, including ones already replaced in August.

Gap between documents and events. The security practices page (updated May 15, 2026) says Zeabur is pursuing SOC 2 Type II and that production database access is limited to devices on Tailscale; the two incident reports record the attacker reading the production database twice, the second time after adding a node of its own to the internal network. The terms of service restrict use in some regions and for some purposes; the wording of the terms governs.