For: developers and operators who deploy apps or databases on Zeabur, the app deployment platform (PaaS), especially those who keep API keys for AI services, payment, cloud or database credentials in environment variables. This article is based on Zeabur's official preliminary report and its shutdown announcement, and does not cover attack techniques.
Developing: this article will be updated as the organisation publishes more
- Who is affected
developers and operators who deploy apps or databases on Zeabur, the app deployment platform (PaaS), especially those who keep API keys for AI services, payment, cloud or database credentials in environment variables.
- Confirmed so farSee the table ↓
- Environment variables in the platform database
- Account data
- zSend API keys
2 more
- Platform Access Tokens
- What the company calls GCP Dedicated Servers
- Not yet confirmed
- How the attacker obtained the initial credentials
- How much data was actually taken from shared cluster databases
- Whether backups and other stored objects were downloaded
1 more
- Whether the leaked tokens for what the company calls Hetzner and DigitalOcean Dedicated Servers were used
- What to do nowSee the steps ↓
- Revoke every secret in your environment variables at the issuing service
- Shared cluster users: change passwords inside the database too
- Recreate Zeabur Access Tokens and zSend API keys
4 more
- If you connected GitHub, check its audit log for October 15
- Check usage and bills from October 14 onward
- If you lost money, file a claim by November 30, 2026
- Dedicated Server users: treat the server as compromised if it is in scope
- Where to verify (source)All sources ↓
- Zeabur, "Zeabur October 2026 security incident (preliminary report)" (October 19, 2026)
- Last checked
- As of October 31, 2026
Follow-up plans and what we checked
The October 19 report says: "The investigation is ongoing, and we will update this article as it progresses." On October 31 the page still showed October 19 as its date. The only later notice on the company's blog is an October 22 post on refunds and incident claims, which does not update the investigation.
What Zeabur users should do today
Revoke every secret in your environment variables at the issuing service
This covers API keys (AI services, payment, email), cloud keys, database passwords, and signing and encryption keys. The company's order is: revoke the old value with the service provider first, then create a new one, set it on Zeabur and redeploy.
Deleting or editing the variable on Zeabur alone does not stop a copy someone already has. This applies even if you replaced the value after the August incident, because the company says the August rotation did not cover the credentials used this time.
Shared cluster users: change passwords inside the database too
The company says changing environment variables on Zeabur does not change the passwords inside the database. Changing passwords also does not undo data that has already leaked. If your database stores your own users' password hashes, login sessions or tokens, revoke and regenerate them as well.
The company also asks users to:
- n8n: replace the n8n encryption key and recreate all third-party credentials stored in n8n
- new-api/one-api: revoke the upstream AI service keys and regenerate access tokens
- PostgreSQL: look for roles, functions, triggers, scheduled jobs or extensions you do not recognise; if in doubt, create a new database and import only the data
- Taipei (tpe1) and Hong Kong (hkg1) regions: treat data in database backups as leaked
Recreate Zeabur Access Tokens and zSend API keys
The company says all users were signed out and all platform Access Tokens were revoked. Sign in again, create new tokens on the Access Token page, and check for requests you do not recognise. zSend users need to recreate their zSend API keys (all 566 have been revoked).
If you connected GitHub, check its audit log for October 15
The company says the private key of the Zeabur GitHub App was read and was replaced at 18:54 UTC on October 15, and that it has found no use of it so far. It asks users to check their GitHub audit log for actions by the Zeabur GitHub App from 15:05 to 18:54 UTC on October 15: unexpected clones or pushes, new deploy keys and modified webhooks.
Check usage and bills from October 14 onward
Review usage and bills for each service whose keys you stored, from October 14, 2026. The company says that is the earliest known use of the credentials, not proof that nothing leaked before. Users of the Dedicated Servers labelled "GCP Dedicated Servers" should go back to September 1. For why stolen AI keys turn into bills quickly, see stolen API keys and account bans.
If you lost money, file a claim by November 30, 2026
The company's October 22 notice says claims for losses from the October incident must be submitted as a separate Zeabur Support ticket by November 30, 2026, and only claims submitted by then will be accepted. It asks for the affected accounts and services, the types of leaked keys or credentials, and the third-party invoices or usage records covering the incident period. Claims are handled separately from account balance refunds.
Dedicated Server users: treat the server as compromised if it is in scope
For the Dedicated Servers labelled "GCP Dedicated Servers", the company says to treat the server as compromised. Back up your data and rebuild the server; this is the most reliable way to remove anything left behind. If you cannot rebuild right away, the company's minimum steps are to remove SSH keys you do not recognise, check accounts, scheduled jobs and services, change the root password and turn off password login for SSH, and replace every credential on the server. The company's report lists the signs to look for; check them on the official page.
For the servers the company calls "Hetzner and DigitalOcean Dedicated Servers", it asks you to check in the provider's console whether the root password was reset or the system was reinstalled after October 14.
What happened (from Zeabur's report)
The following is based on Zeabur's preliminary report of October 19, 2026 (also published in Japanese and four other languages). All times are UTC.
August 2026
A separate security incident at Zeabur. The company says the rotation afterwards did not cover the credentials used in October.October 14, 01:36
First known use of a Zeabur internal cloud key by the attacker, followed by access to the shared cluster.October 15, 13:56
Zeabur starts its investigation after a user report.October 15, 16:10–16:47
The attacker reads the platform database (confirmed by the company).October 15, 20:25
Zeabur rotates its login signing key; all users are signed out.October 15, 21:05
Last attacker activity observed so far.October 17
Zeabur announces it will shut down on December 31, 2026.October 19
Zeabur publishes its preliminary report on the incident.October 22
Zeabur sets November 30, 2026 as the deadline for incident claims and says service data will be deleted on December 31.
Stored on Zeabur: read
Environment variables kept in the Zeabur platform database, including projects that never moved them
Moved to your own Dedicated Server after August
Outside the platform database read. If the server itself was in scope, its secrets still need replacing
The company asks every user to replace secrets either way. The split only tells you how certain the exposure is.
- What happened
- An attacker used leaked Zeabur internal credentials to break into the shared cluster, some Dedicated Servers and internal systems, and read the platform database
- Data read
- Environment variables (3,218,965 records), account data (321,810 accounts), zSend API keys (566), plus platform Access Tokens stored as irreversible hashes (11,536, all revoked)
- Other systems
- Commands were run inside 865 database containers on the shared cluster; root sign-ins were confirmed on 101 of the servers the company calls GCP Dedicated Servers
- Cause (company)
- Long-lived admin credentials stored in plaintext and usable from the public internet. The company says the root cause lies with Zeabur
- Response
- Used credentials revoked, public SSH to admin interfaces and servers blocked, all users signed out, all Access Tokens revoked
- Compensation
- Extra charges on third-party API keys or cloud accounts caused by the incident can be claimed through a support ticket, by November 30, 2026 (October 22 notice)
What is known and what is not
The state as of October 31, 2026. The company's own terms are "confirmed" (a log directly records it), "assessed" (timing and content match, but no direct record) "cannot be confirmed" (no records to check; treated as leaked) and "hypothesis" (a possible explanation supported only by indirect evidence). The status column follows those terms. When there is a follow-up, it will be updated.
| Item | What the report says | Status |
|---|---|---|
| Environment variables in the platform database | 3,218,965 records (names and values) read | Confirmed (company) |
| Account data | 321,810 accounts: email, username, phone number and more, plus project data | Confirmed (company) |
| zSend API keys | 566 keys stored in plaintext, all revoked | Confirmed (company) |
| Platform Access Tokens | 11,536 tokens stored only as irreversible hashes, all revoked | Confirmed (company) |
| Shared cluster environment variables and secrets | 9 regions; part confirmed, the rest treated as leaked | Partly confirmed; rest cannot be confirmed (company) |
| Shared cluster database contents | Commands run in 865 database services; how much was taken cannot be confirmed | Assessed (company) |
| What the company calls GCP Dedicated Servers | Root sign-ins confirmed on 101 servers (92 users) | Confirmed (company) |
| Database backups (Taipei tpe1, Hong Kong hkg1) | Whether they were downloaded cannot be confirmed. Separately, the company says evidence on a compromised host confirms that at 15:42 UTC on October 15 the attacker obtained a customer database backup | Cannot be confirmed (company) |
| What the company calls Hetzner and DigitalOcean Dedicated Servers | Admin tokens leaked; whether they were used cannot be confirmed | Cannot be confirmed (company) |
| Two-factor authentication and passkey data | Only statistics were queried; no record of contents being read | No record of contents read (company) |
| How the initial credentials were obtained | Cannot be confirmed; a link to August is an unconfirmed hypothesis | Cannot be confirmed (company) |
| Misuse of leaked keys | One user's AI service key was used for about 1,107 requests on October 16; the company says it is a hypothesis that it came from this leak | Hypothesis (company) |
How to read this: 'cannot be confirmed' still means rotate
The company says that where unauthorised access cannot be ruled out, it assumes the data may have been exposed. For your own secrets, the practical difference between "confirmed", "assessed" and "cannot be confirmed" is small: all of them mean revoke and replace.
What leaked environment variables can lead to
In general, secrets taken from environment variables can be misused as follows. This does not mean all of it has happened here.
- AI service API keys: someone else sends requests on your account and you receive the bill. The company observed that the attacker was mainly looking for keys it could use directly, especially keys for AI services
- Database passwords and connection strings: reading or changing your app's data, including your own users' records
- Signing and encryption keys: forging session tokens or decrypting data your app protects
- Cloud and payment keys: creating resources or making calls that cost money
A past example: after the Railway environment variable incident, the hosting company sent lists of possibly exposed keys to the issuing services so they could be revoked. This case may not follow the same course, so revoke your keys yourself.
For operators: lessons from what the company disclosed
These points come from the cause and gaps the company itself listed. They are not a further judgement of Zeabur.
- Give admin tokens an expiry and keep admin interfaces off the public internet. The company says its cluster admin tokens had no expiry, had not been rotated since January 2024, and the admin interface was reachable from the internet.
- After an incident, rotate every credential that could have been read, not only the ones confirmed as leaked. The company says the August rotation did not cover the credentials used in October.
- Keep plaintext secrets out of backups and keep backup keys apart. The company says cluster backups contained all secrets, and a key rotated during the response was captured by a later backup.
- Alert on bulk reads of secrets. The company says more than 16 hours of activity on October 14 triggered no alerts and the incident was found after a user report.
For your own apps, the safest secret is one the platform never stores: short-lived credentials, or a separate secrets store your app reads at runtime (see what's actually dangerous about .env and API keys).
Sources (public records)
The facts in this article are based on the public information below. Intrusion routes that the company has not confirmed are not speculated about, and indicators of compromise are not reproduced here.
- Zeabur, "Zeabur October 2026 security incident (preliminary report)" (October 19, 2026) — zeabur.com
- Zeabur, "Zeabur service migration, refunds, and security incident claims" (October 22, 2026) — zeabur.com
- Zeabur, "Zeabur is shutting down: what happens next" (October 17, 2026) — zeabur.com
Update history
2026-10-31: First version. Based on Zeabur's October 19 preliminary report, its October 17 shutdown announcement and its October 22 notice on incident claims. As of October 31, no further investigation report appears on the company's blog. This article will be updated when there is a follow-up.
Read next
- Same type of incident: Railway environment variables possibly exposed (October 2026) / OpenCode Console breach (October 2026)
- Why AI keys are targeted: defending against AI-driven cyberattacks / stolen API keys and account bans
- Leaked keys that stay valid: leaked credentials that stay valid
- Other 2026 incidents: Data breaches and cyberattacks of 2026