你的 API Key 還安全嗎？Zeabur、Railway、LiteLLM 接連外洩，開發者自查與金鑰輪替清單
2026 年 10 月中旬，短短一週內，Zeabur、Railway、OpenCode 等開發與部署平台接連傳出環境變數或 API Key 外洩，熱門的 LLM 代理套件 LiteLLM 也在 PyPI 與 Docker Hub 被植入竊密程式。這些事件有一個共同目標：你放在平台上的 API Key，特別是 AI 服務的金鑰。這篇整理各事件的重點，以及開發者現在就該做的自查清單。
如果你有使用以下任一服務，請先跳到「現在就該做的事」：Zeabur、Railway、OpenCode Console，或在 2026/10/21 安裝過 LiteLLM 1.107.0。
事件總覽
| 事件 | 時間（UTC） | 外洩內容 | 狀態 |
|---|---|---|---|
| Zeabur 平台入侵 | 10/14～10/15 | 約 321 萬筆環境變數、約 32 萬個帳號資料 | 已確認讀取，調查中 |
| Railway | 10/21 | 部分客戶加密環境變數，部分已被解密 | 暫停部署，調查中 |
| OpenCode Console | 10/17～10/18 | 約 1.4% 使用者綁定的模型 API Key | 已有使用者回報異常扣款 |
| LiteLLM 1.107.0 | 10/21 約 11:39～14:20 | 安裝或啟動該版本主機上可存取的所有憑證 | 惡意版本已下架 |
Zeabur：一個沒有過期日的管理 Token
Zeabur 公布的初步報告非常詳細，根因也很典型：
- 一組 2024 年建立、永不過期的共享叢集管理 Token，被以明文存放在設定檔儲存庫中，8 月的上一次事件後也沒有輪替
- 共享叢集的管理介面可以從公開網路存取
- 叢集備份包含所有機密，而備份的存取金鑰就放在旁邊
- 權限過大，例如只該存取單一儲存桶的金鑰可以讀整個 AWS 帳號
- 10 月 14 日長達 16 小時以上的異常活動，沒有觸發任何告警
攻擊者最後讀取了平台資料庫，包含 3,218,965 筆環境變數與 321,810 個帳號的 Email、使用者名稱、電話等資料。使用 n8n 的服務因為加密金鑰也放在環境變數中，存在其中的第三方憑證應視為明文外洩。
Zeabur 已宣布將在 2026 年 12 月 31 日結束服務，在那之前會持續處理這起事件，還在使用的人也要開始規劃搬遷。
Railway：部分加密環境變數被解密
Railway 在 10 月 21 日偵測到存放客戶環境變數的系統有異常活動，未授權的第三方可能存取了加密的環境變數，其中部分已取得解密內容。Railway 當天暫停了所有部署，並表示這看起來是一連串鎖定平台業者、目標是取得 AI 推論服務金鑰的攻擊之一，已通知上游 AI 服務商主動撤銷金鑰。
LiteLLM 1.107.0：供應鏈投毒
LiteLLM 是許多團隊用來統一管理多家 LLM API 的代理服務，本身就保管大量 AI 金鑰，是攻擊者眼中的高價值目標。10 月 21 日，攻擊者發布了惡意的 1.107.0 版本到 PyPI、Docker Hub 與 GHCR，這些套件不是從官方 GitHub 原始碼建置的。
- 惡意程式透過
cook.pth與sitecustomize.py，在 Python 每次啟動時自動執行 - 竊取雲端、密碼與 AI 服務憑證，並能載入遠端程式碼
- 受影響的 Docker 標籤包含
v1.107.0、latest、main-latest、main-stable，沒有鎖定版本的部署也可能中招
檢查方式：
pip show litellm
# 搜尋惡意檔案（找不到不代表一定安全）
find / -name "cook.pth" -o -name "litellm-1.107.0.dist-info" 2>/dev/null官方提醒：不要先執行 pip install，因為任何 Python 啟動都會再次觸發惡意程式。應先從 shell 刪除 cook.pth、cook.py、sitecustomize.py，終止持有 /tmp/remote_code_loader.lock 的程序，再重建環境並鎖定 1.106.2。
為什麼攻擊者都在搶 AI API Key？
- 可以直接變現：偷來的 Key 可以轉賣、架成「低價 API」，或直接拿來大量呼叫模型，帳單由受害者買單
- 額度通常很高：為了跑 Agent 或批次任務，很多團隊的 Key 沒有設定花費上限
- 集中在少數地方：部署平台的環境變數、LLM 代理服務、n8n 這類自動化工具，一次就能拿到大量金鑰
現在就該做的事
- 先撤銷，再換新：到各服務商後台撤銷舊 Key，產生新 Key，再更新環境變數並重新部署。順序反過來，舊 Key 在你換完前仍然有效
- 連資料庫密碼一起換：要在資料庫內部改密碼，不只是改平台上的環境變數
- 檢查帳單與用量：從 10 月 14 日起（Zeabur GCP 專用主機用戶從 9 月 1 日起）的異常用量
- 檢查 GitHub 稽核紀錄：陌生的 clone、push、deploy key 與 webhook 變更
- n8n 使用者：更換加密金鑰，並重新建立所有第三方憑證
長期該改掉的習慣
- 替每把 Key 設定花費上限與用量警示，被盜用時損失有上限
- 一個用途一把 Key，權限最小化，外洩時可以只撤銷那一把
- 能用短效憑證就不要用長期金鑰，例如 CI/CD 改用 OIDC 取得臨時雲端權限
- 鎖定套件版本與雜湊：使用 lockfile 與
--require-hashes，Docker 映像以 digest 而非latest標籤部署 - 機密不要進 Git：用 Secret Manager 集中管理，並開啟 GitHub Secret Scanning