Railway 環境變數可能外洩（2026 年 10 月，所有工作區中最多 1.85%）：該輪替哪些密鑰、使用者該怎麼做

公司要求你撤銷並重新設定 10 月 21 日之前儲存在 Railway 上的每一個敏感環境變數，包括 API 金鑰與私有映像檔倉庫憑證。

請依以下順序進行：

• 列出你的環境變數。打開每個服務的 Variables 分頁，標出屬於密鑰的值（API 金鑰、權杖、密碼、簽章金鑰、連線字串）
• 在各來源的儀表板核發新值：AI API、支付服務商、GitHub、雲端、外部資料庫等
• 更新 Railway 變數並重新部署服務。容器只在啟動時讀取變數，所以在重新部署之前會繼續使用舊值執行（公司指南）
• 新值確認可用後，在來源端撤銷或刪除舊值

只在 Railway 內更改數值，已外洩的值在你於來源端撤銷之前仍然可用（本站註記）。

公司建議所有使用者移除資料庫的公開網路存取。其指南指出，啟用公開存取（TCP proxy）的資料庫，在你輪替之前，任何人都能從網際網路上任何地方憑其憑證連線。

• PostgreSQL、MySQL、Redis 與 MongoDB 請在資料庫檢視中使用 Regenerate。它會一次更改資料庫內的密碼與變數，並中斷現有連線（公司指南）
• 不要手動編輯 POSTGRES_PASSWORD 等密碼變數，也不要直接在資料庫中更改密碼，否則變數與資料庫會不同步（公司指南）
• 重新部署所有引用這些變數的服務（例如 ${{ Postgres.DATABASE_URL }}）。請將貼上的連線字串改成引用
• 若專案以外沒有需要，請在 Settings、Networking 中關閉 Public Access。外部用途（本機開發、CI、BI 工具）需要手動貼上新的 DATABASE_PUBLIC_URL

公司建議檢查 GitHub 稽核紀錄與應用程式存取，以及 Docker Hub 等映像檔倉庫的稽核紀錄。其指南列出以下檢查項目：

• 個人帳號：GitHub 安全紀錄（90 天）、已授權的 OAuth 應用程式與 GitHub Apps、SSH 與 GPG 金鑰，以及個人存取權杖。撤銷任何你不認得的項目，並重新產生權杖
• 組織：組織稽核紀錄（180 天）。在撤銷任何項目之前，請先匯出紀錄。逐一檢視每個儲存庫的 deploy key、secrets、webhook 與協作者
• GitHub Container Registry（ghcr.io）：Railway 已移除它儲存的 GitHub 權杖，但這些權杖在 GitHub 上撤銷之前仍然有效。請在 GitHub 刪除舊權杖，建立具 read:packages 範圍的新權杖，並設定到每個服務

指南也警告，擁有推送權限的攻擊者可以新增 webhook 或 secret，即使重設密碼也仍會留存。

根據公司的初步報告，攻擊者似乎在尋找 AI 供應商的 API 金鑰。公司已發布針對 OpenAI、Anthropic、OpenRouter、Grok、Stripe、AWS 與 GCP 的用量檢查指南。例如 OpenAI 指南說明要：

• 刪除可能外洩的金鑰，並在同一個專案中建立新金鑰
• 開啟用量，依 API 金鑰分組，將暴露期間的 token 量、請求數與模型組合，與你的正常流量比較
• 檢查該期間的帳單支出，以及被消耗的額度贈與
• 檢視成員與專案成員，找出你沒有邀請的人
• 保留用量明細，若發現濫用，請聯絡供應商的支援

至少檢查從攻擊時間窗開始（10 月 20 日 13:58 UTC）到你輪替金鑰為止的期間（本站註記）。

公司在應變期間撤銷了所有登入工作階段、Railway 存取權杖、GitHub 連結與儲存空間（bucket）憑證。暫停部署期間推送的 commit 並未部署。

• 使用你註冊時的同一個 Gmail、GitHub 帳號或電子郵件登入。用不同身分登入會建立一個全新的空帳號（公司指南）
• 在帳號設定中重新連結 GitHub，在服務的 Settings 中重新連結儲存庫，並部署最新的 commit
• CLI：執行 railway logout，再執行 railway login。CI：重新建立專案權杖（RAILWAY_TOKEN）或帳號／工作區權杖（RAILWAY_API_TOKEN），並在 CI 密鑰中取代
• 重新部署使用 bucket 的服務，使其取得新憑證。同時檢查 bucket 中是否有你沒有上傳的檔案，或你沒有進行的刪除（公司表示 bucket 沒有自動備份）
• 在工作區稽核紀錄中，找出暴露期間內不是由你的團隊或 Railway（顯示為「Railway Staff」）進行的變數讀取、映像檔倉庫憑證變更與部署

Railway 的環境變數是加密的，但根據初步報告，攻擊者利用多組遭入侵憑證的組合解密了一部分。代管平台必須把變數還原成明文才能執行你的應用程式，所以一旦平台內部的權限被奪取，光靠加密無法完全保護（本站註記）。

除了平台加密之外，請用能讓外洩損害有限的方式保存密鑰。第一步，請在 AI API 與支付服務商設定花費上限與警示。為正式、測試與開發環境使用不同的金鑰，也能縮小需要輪替的範圍。密鑰的保存方式請見.env 與 API 金鑰究竟危險在哪裡。

依公司指南，啟用公開存取的資料庫，只要連線字串外洩，就能從網際網路上任何地方連線。只透過專案私有網路使用的資料庫，即使連線字串外洩，也無法從外部直接連線。

外部存取通常只有本機開發、CI 或 BI 工具需要。即使如此，也可考慮只在需要時開啟，或改用另一個唯讀使用者（本站註記）。

公司指南建議，連線字串與金鑰以 ${{ Postgres.DATABASE_URL }} 這類引用變數共用，而不是貼到每個服務中。使用引用時，更改來源值並重新部署就能涵蓋所有服務，也不會有被遺忘的貼上副本。

基於同樣的想法，請隨時維護一份清單，記錄每個服務使用哪些密鑰，以及在哪裡重新核發（本站註記）。像這次需要全部輪替時，這份清單會決定作業要花多久。在類似的案例Vercel 資安事件中，關鍵在於密鑰是否存放在事後無法顯示其值的類別中。

本次事件中，公司撤銷了它持有的 GitHub 權杖，並建議檢視 GitHub 稽核紀錄與應用程式存取。請將授予代管平台的 GitHub 存取限縮在它要部署的儲存庫，並讓容器映像檔倉庫權杖只有讀取權限（read:packages），這樣外洩時波及範圍較小（本站註記）。外洩的憑證仍然有效的問題，請見仍然有效的外洩憑證。