Zeabur 8/27 网络安全事件懒人包：用户应立即采取的 4 步 + API Key 撤销教程

台湾 PaaS 平台 Zeabur 喺 2026 年 8 月 27 日发生内部服务凭证遭未授权使用嘅资安事件，攻击者通过该组凭证查找存放项目环境变量嘅数据库，导致用户喺 Zeabur 设置嘅OpenAI、Anthropic、OpenRouter、Gemini、GitHub、AWS、Cloudflare、Stripe 等API Key / Token、数据库连接字符串、JWT Secret 等敏感信息外泄。创办人林沅霖已公开声明确认事件，并表示将喺核实个别损失后尽快赔偿。本文整理官方目前公布嘅处置、用户应即时采取嘅补救步骤，以及坊间留意嘅LiteLLM 漏洞时序巧合。

事件时间线：8/27 发现 → 8/28 通知 → 8/29 创办人声明

根据 Zeabur 创办人林沅霖嘅公开声明同官方 status page (https://status.zeabur.com/incident/1037896) 同媒体报导（动区、INSIDE），事件时间线如下：

• 2026-08-27：Zeabur 确认一组内部服务凭证遭未授权使用，攻击者借此查找存放项目环境变量嘅数据库
• 事件当日：Zeabur 团队已完成第一时间控制、撤销凭证并阻断访问
• 2026-08-28：分两批通知受影响用户；官方亦表明即使冇收到信都要自查，因为只要值符合已知凭证格式就可能曾暴露
• 2026-08-29：创办人林沅霖公开道歉声明，表示个别损失经核实后会尽快赔偿

媒体报导亦提到：用户喺 8 月 28 日凌晨先发现帐单异常并向客服查找，下午获回复「无异常」，到下午约 5 点先收到官方通知信。创办人喺声明中表示会持续监控、逐一通知可能受影响嘅用户，并配合上游厂商同执法机关进行进一步调查。

事件 root cause + 创办人技术更新

创办人林沅霖喺事件后发出更详细嘅技术更新，以下为官方确认到嘅情况（创办人公开声明 verbatim）：

「攻击者是取得了我们内部泄漏的一把 AWS 管理密钥，进入我们位于日本东京的 AWS 共享集群后，从集群内部获取到了系统控制面的 VPN 访问权限，得以进入主数据库。」

「从我们目前对主数据库的纪录进行分析，目前仅看到攻击者对用户的环境变量（Variables）进行了目的明确（针对 AI API Key）的定向查找及导出。」

「对于其他敏感数据（例如客户数据、服务器设置等）我们从可获取到的纪录认为攻击者仅进行了『不涉及具体数据』的计算数量、文件大小等操作。」

「目前社群流传的一篇关于『暗网』的截屏，声称攻击者贩售完整的 Zeabur 数据，从我们目前已经搜集的所有证据并不支持这份数据的真实性。」

「我们也已经正在与专业的第三方安全机构进行进一步的调查及分析，有任何进展仍会第一时间向各位同步。」

外泄范围 + 已知实际被盗用嘅服务

已确认外泄嘅系环境变量中嘅密钥，涵盖以下类别：

• AI / LLM API：OpenAI、Anthropic、OpenRouter、Gemini
• 源代码托管：GitHub
• 云端服务：AWS、Cloudflare
• 付款服务：Stripe
• 数据库连接字符串（database connection strings）
• JWT Secret 等应用层密钥

• Anthropic
• OpenAI
• OpenRouter

由于 LiteLLM 出现可疑活动，Zeabur AI Hub 已暂停服务直至另行通知，官方将喺后续公布完整报告同赔偿方案。后续进度可查 [Zeabur Status Page](https://status.zeabur.com)。

LiteLLM 漏洞时序巧合（官方未确认因果）

Zeabur 官方尚未正式确认今次事件同 LiteLLM 有直接关系。但巧合嘅系，事件发生前一日，LiteLLM 官方 GitHub 公开咗一个高风险漏洞：[GHSA-3cv6-jpf6-8222](https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222)。

该漏洞嘅内容：已登录嘅 LiteLLM 用户，可能通过特制请求，令 LiteLLM 将上游 API Key（包括 OpenAI、Claude 等）泄漏出去。

如果你本身有使用 LiteLLM 做 API 中转站：

• 立即将 LiteLLM 升级到修补版本
• 限制 api_base 等可控参数，避免暴露内部 endpoint
• 全面检查同更换上游 API Key（OpenAI / Anthropic / OpenRouter 等）
• 查阅 LiteLLM 嘅访问纪录，留意任何异常调用

⚠️ 注意：Zeabur 官方并未确认 LiteLLM 漏洞系今次事件嘅 root cause。现阶段只能讲两件事喺时间上极接近。Zeabur 表示会喺后续完整报告中交代。

用户应即时采取嘅 4 步

如果你曾经将 API Key 或云端权杖放喺 Zeabur 嘅环境变量，（不论有冇收到 Zeabur 通知信），请即刻做以下步骤：

• 步骤 1 — 撤销旧 Key：到原服务商（OpenAI / Anthropic / OpenRouter / GitHub / AWS / Stripe 等）后台撤销受影响嘅 Key。撤销唔可以只靠喺 Zeabur 删除环境变量，因为旧 Key 仍然有效。
• 步骤 2 — 创建新 Key：喺原服务商后台创建新嘅 Key，再贴返去 Zeabur 嘅环境变量。
• 步骤 3 — 检查用量同帐单：登录原服务商后台，查找过去 7 日嘅 API 用量、token 消耗、账单。留意有冇突然飙升或者陌生 request pattern（例如陌生 prompt、深夜时段用量异常）。
• 步骤 4 — 查访问纪录：原服务商如果提供 request log（例如 OpenAI Usage、Anthropic Console），下载过去 7 日纪录留存证据。
• 步骤 5 — 修改 SSH 密码 + 打开连接纪录：如果你喺 Zeabur 部署嘅服务有用到 SSH 访问，请即刻修改 ssh 密码，并打开并保留连接纪录（login/log audit log），方便日后核实是否曾被可疑登录。

⚠️ 「撤销」系关键：喺大多数 API 服务后台，「创建新 Key」唔会自动令旧 Key 失效。你必须主动去「撤销」旧 Key，否则旧 Key 仍然可能被盗用。

点样向 Zeabur 申请协助同举证

如果你怀疑自己嘅 Key 已经被滥用，请先完成上面嘅撤销同新 Key 进程，然后准备以下数据：

• 滥用发生嘅时间范围（越精确越好）
• 受影响金额或 token 用量数字
• 请求来源 IP、设备号（device fingerprint）等 trace 信息
• 其他能协助执法机关调查嘅证据

将以上数据提交到 Zeabur 技术支持页面。官方表示会以最高优先级处理所有与本次事件相关嘅请求，喺完成必要嘅调查同核实后，尽快进行后续嘅赔偿处理。

创办人 Q&A：赔偿、信用卡、服务器安全

以下是创办人喺声明中提供嘅 5 条常见问题解答（verbatim）：

Q：Zeabur 会赔偿吗？

「我们目前已有初步的赔偿运行办法：因本次事件产生非本人操作的额外费用，我们将通过已上传到技术支持单的数据逐笔核实，并于确认后进行赔偿，目前计划希望最迟于 9 月 30 日前完成款项安排；实际支付方式将依所在地区及个别情况而定。对于大额或情况特殊的案例，我们可能会需要更长的时间进行确认，请您见谅。」

Q：我的信用卡数据是否可能遭到盗刷？

「绝对不会，您的付款信息是保存在 Stripe 系统中，即使是我们内部的成员也无法取得或使用您的信用卡数据。」

Q：我部署喺 Zeabur 上嘅服务内嘅数据是否可能曾被攻击者访问？

「从我们目前掌握到的攻击方式，攻击者是存在可能性、可行性进入客户所部署的服务中访问数据。然而，如同上面所提到，我们目前没有搜集到直接证据证明攻击者对环境变量以外的数据。」

「如果您在环境变量内填写了可以直接使用的数据库凭证，且该数据库是可以被公网直接访问，攻击者有可能会使用脚本工具进行尝试访问，这是为什么我们第一时间通知客户轮换。」

Q：目前 Zeabur 系安全嘅吗？

「我们在第一时间完成所有密钥的轮换、全方位加强系统监控记录，目前并未检测到任何除了本次攻击以外的可疑活动。然而，由于攻击方式及影响范围等因素，我们目前无法完全保证系统目前是绝对安全的。」

Q：攻击者会入侵我喺 Zeabur 买嘅主机吗？

「从我们目前已经确定的证据中，攻击者并没有访问服务器设置相关的数据。然而，从技术上来说攻击者当时是有查找到主机连接方式的能力，因此仍建议您修改主机的 ssh 密码并打开连接纪录。」

用户自保 — 预防同类事件嘅最佳实践

今次事件揭示咗 PaaS 平台「集中式管理环境变量」嘅固有风险：一旦平台嘅内部凭证被入侵，所有用户嘅密钥都可能同时暴露。以下系可即时采用嘅自我保护措施：

• 密钥唔好长期放喺单一平台：能够喺本机或自己嘅 secret manager（例如 1Password、AWS Secrets Manager、GCP Secret Manager）就唔好放平台
• 为每个服务设扣款上限：OpenAI 同 Anthropic 都支持硬性 budget cap，发现用量异常可以即时 cut off
• 定期轮换 Key：每 90 日轮换一次 API Key，减低单次外泄嘅暴露窗口
• 喺 AI 厂商后台激活 IP 白名单：限制 API Key 只能从指定 IP range 访问
• 为每个服务创建独立 Key：唔好用同一个 Key 行晒所有服务，方便出事时快速 revoke
• 设置用量 alert：用量超过阈值时自动 email / SMS 通知

对开发团队嚟讲，更进一步嘅做法：短期 — 环境变量嘅 Key 加密保存（Zeabur 之类嘅平台应该原生支持 KMS-style encryption）。中期 — 采用 zero-trust secret retrieval，例如 HashiCorp Vault、AWS Secrets Manager。长期 — 推动 SaaS 供应商将 API Key 改成 short-lived token（例如 OAuth-style），减少静态密钥嘅暴露风险。

创办人林沅霖公开声明

以下是创办人林沅霖喺 8 月 29 日发出嘅声明原文（节录）：

「大家好，我是 Zeabur 的创办人 Yuanlin 林沅霖。关于昨日发现的 Zeabur 环境变量泄漏资安事件，目前我们已经完成以下处置：在侦测到异常的当天即完成第一时间的控制；持续监控是否有进一步异常；逐一通知所有可能受影响的用户并发布公告；正在配合上游厂商及执法机关进行进一步调查。」

「若您已经收到我们的通知信，或您目前在 Zeabur 上仍存有OpenAI、Anthropic、OpenRouter 等第三方 AI 服务的 API Key，敬请尽快根据下方轮换教学进行操作，并立即检查您的用量及帐单。」

「如果您发现凭证已遭滥用，请先立即完成凭证轮替，并检查相关服务的用量与帐单，并请协助我们从 AI 厂商后台取得滥用请求的：发生时间、金额或 token 用量、请求来源 ip、设备号等信息，以及其他能协助我们与执法机关调查的证据数据。」

「请将所有能协助我们配合执法机关调查及核实您损失情况的数据提交至 Zeabur 技术支持页面，我们会以最高优先级处理所有与本次事件相关的请求，并在完成必要的调查与核实后，尽快进行后续的赔偿处理。」

结论：后续发展同官方 status link

今次事件再次提醒我哗：将 API Key 放喺第三方 PaaS 平台嘅环境变量，本质上等于将所有密钥放喺同一个保险箱。保险箱一旦被攻破，所有用户同时受影响。

Zeabur 事件嘅完整根因、受影响人数、赔偿时程同最终事故报告，官方表示会喺后续公布。读者可以通过以下渠道追踪最新进度：

• Zeabur 官方 Status Page：[status.zeabur.com](https://status.zeabur.com)
• Zeabur 事件编号：[incident/1037896](https://status.zeabur.com/incident/1037896)
• LiteLLM 漏洞详情：[GHSA-3cv6-jpf6-8222](https://github.com/BerriAI/litellm/security/advisories/GHSA-3cv6-jpf6-8222)
• 媒体报导：动区、INSIDE

如发现可疑用量或需要就损失个案提交数据，请尽快到 Zeabur 技术支持页面联系官方团队。