Zeabur 两次被入侵后宣布停运
Zeabur 在 2026-10-17 宣布停止运营，10 月的第二起安全事件是原因之一。服务从 12-01 起分批停止，12-31 全部停止。
段子原句段子未提及，用户补充
- 编号
- 无 CVE 或 GHSA 编号
- 严重度
- 无 CVE；平台停运并伴随数据泄漏
- 利用状态
- 确认被入侵确认被入侵：官方事故报告确认，攻击者在 10-14 至 10-15 进入共享集群、部分独立服务器和内部系统。
- 对段子公司
- 段子里的公司没有提到 Zeabur。只有部署在 Zeabur 上的服务受影响。
- 影响范围
- BleepingComputer 根据官方报告列出 321,810 个账户和约 320 万条环境变量记录。攻击者在 865 个数据库服务中执行过命令，并登录了 101 台 GCP 服务器。
- 修复版本
- →无修复版本：平台将于 2026-12-31 全部停止
- →可通过 Zeabur Support 申请迁移帮助、余额退款和损失赔偿
结论
Zeabur 已于 2026 年 10 月 17 日宣布逐步停止平台运营，传闻属实。[1] 官方称，10 月发生的第二起安全事件加重了安全与运维问题，但停运决定也考虑业务增长受限、系统复杂度和团队可承担责任。[1] 服务将于 2026 年 12 月 1 日起分批停止，并于 12 月 31 日全部停止；日期均为 2026 年。[1] 此事件不是 CVE 漏洞通告，因此没有 CVE 编号、CVSS 分数或修复版本。
事件经过
创办人 Yuanlin Lin 于 2026 年 10 月 17 日发布停止运营公告。[1] 公告将决定与第二起安全事件、系统复杂度及团队能力联系起来。[1]
官方称，攻击者在 10 月 14 日至 15 日入侵内部系统及部分客户服务。[2] 官方报告指出，攻击者使用已有的内部凭据进入共享集群、部分独立服务器及平台内部系统。[2]
10 月 20 日，BleepingComputer 报道了停运决定及数据影响数字。[4] 这次关停是业务停止运营，不是证书或某个软件版本的漏洞修复行动。[1]
技术细节
本事件不适用 CVE、GHSA、CVSS、受影响软件版本或安全补丁版本。[1] 事故主体是 Zeabur 云部署服务及其内部基础设施。
官方事故报告称，内部 AWS 密钥、共享集群管理令牌及部分 GCP 初始化设置中的 root 密码以明文保存。[2] 共享集群管理界面当时可从公网访问，管理令牌没有到期时间。[2]
Zeabur 报告称，攻击者读取共享集群服务设置与密钥，并在数据库容器中执行读取命令。[2] 攻击者也登录了由 Zeabur 管理的 GCP 独立服务器，并取得平台数据库的读取权限。[2]
官方将凭据可能在 8 月事件期间泄露列为假设，尚未确认两次事件之间的凭据来源关系。[2] 官方报告记录了攻击者行为，但没有给出恶意软件或公开 CVE 漏洞的证据。[2]
影响范围
BleepingComputer 根据 Zeabur 报告列出 321,810 个账户及约 320 万条环境变量记录。[4] 官方报告称，攻击者在 865 个数据库服务中执行了命令，但并非每条命令都成功。[2]
媒体报道提到攻击者登录 101 台 GCP 服务器，涉及 92 名用户；攻击者向 50 台服务器添加 SSH 密钥，并将 16 份客户磁盘副本挂载到其虚拟机。[4] 官方报告也记录过 101 台服务器的 root 登录及攻击者添加 SSH 密钥等活动。[2]
官方尚未公布完整用户损失、实际被读取的数据条数、资金损失或赔偿总额。[1] 报告指出，部分云平台、存储和 GitHub 访问日志不完整，因此某些访问范围仍无法确认。[2]
时间线
- 2026-08-27（UTC）官方事故时间线称，攻击者在 8 月事件期间读取 GitHub App 私钥。[2]
- 2026-10-14 01:36（UTC）攻击者首次使用 Zeabur AWS 密钥。[2]
- 2026-10-14 01:40（UTC）攻击者使用共享集群管理令牌。[2]
- 2026-10-14 12:39（UTC）攻击者读取共享集群服务设置及密钥。[2]
- 2026-10-15 13:56（UTC）官方称在用户报告后开始调查。[2]
- 2026-10-15 17:58（UTC）官方移除了攻击者加入内部网络的节点。[2]
- 2026-10-17（公告未标具体时刻及时区）创办人宣布逐步停止运营。[1]
- 2026-10-20（报道未标时区）BleepingComputer 报道 321,810 个账户及约 320 万条环境变量记录。[4]
- 2026-12-01（日期未另标时区）计划独立服务器停续费并按到期日关闭，共享集群服务暂停。[1]
- 2026-12-31（日期未另标时区）计划所有独立服务器和共享集群停止运行。[1]
修复与缓解
官方称已控制已知攻击路径，并继续监控异常活动；调查仍在进行。[1] 官方事故报告记录的处置包括限制共享集群管理界面的来源、轮换登录签名密钥、封锁 GCP 独立服务器的公网 SSH，并撤销部分云服务令牌。[2]
官方建议受影响用户立即轮换暴露的凭据和密钥、撤销有效会话，并重建受影响的 GCP 服务器。[4] 用户应先备份数据库、配置、环境变量和部署映像，再迁移到新平台。[3]
Zeabur 的迁移指南建议先盘点服务、域名、数据及映像，再选择托管平台或自建环境，完成备份恢复测试后切换 DNS。[3] 官方称可通过 Zeabur Support 申请迁移帮助、账户余额退款及安全事件损失赔偿。[1]
官方已开放 Zeabur 购买域名的自助转出。[1] 数据删除日期、最终数据导出截止日及 Support 关闭日期，在公告发布时尚未确定。[1]
对段子中公司的影响
段子中的配置没有指出 Zeabur 组件，因此不能据此认定那家公司直接受 Zeabur 停运影响。若该公司把生产服务部署在 Zeabur，共享集群服务将于 12 月 1 日暂停，独立服务器则可能按各自到期日提前关闭。[1]
该公司还需迁移映像、部署流水线、域名、TLS 证书、服务发现、环境变量、数据库备份、监控和团队权限。[3] NGINX、PHP-FPM、TiDB、Node.js、Go、Python、Linux、Docker、Kubernetes、Traefik、ASP.NET Core 与证书信任库本身，并不会仅因 Zeabur 停运而自动受影响。
若公司账户在 Zeabur 托管项目，需根据官方泄露范围判断是否轮换密钥，并审查相关数据库与服务器访问记录。[2] 公司应在实际服务器到期日前完成迁移，不应把 12 月 31 日当作所有服务仍可运行的保证。[1]
存疑与未验证
- 事件关闭平台已由创办人正式公告确认；平台截至 2026 年 12 月 31 日才全部停止，属于计划而非已完成事实。[1]
- 官方报告仍在调查，日志不完整；完整受影响账户、数据及凭据清单未验证。[2]
- 攻击者是否利用 8 月事件窃取本次凭据，官方只列为推测，未验证。[2]
- 公司用户、开发者社区中的中文用户人数及实际迁移比例，未找到可靠统计。
- 该事件没有 CVE、GHSA、CVSS 或修复版本；将其描述成特定组件漏洞不准确。
参考资料
调研截止 2026-10-22 UTC+8 · 未验证的内容已在正文中标注 · 数字以原始来源为准