2026 年 10 月 21 日清晨，Railway 偵測到儲存客戶環境變數的系統出現異常活動。官方在當天深夜才發出公告，承認有第三方在未獲授權的情況下，讀到加密的環境變數。其中一部分的解密內容已被取走。
本文分三部分：官方公告全文翻譯、Hacker News 上 140 則留言的整理、以及一頁懶人包。
官方公告全文翻譯
原文標題：Security Disclosure: Wednesday, October 21st
作者：Jacob Cooper
發布日期：2026 年 10 月 21 日
今天清晨，Railway 偵測到涉及「儲存客戶環境變數之系統」的異常活動。經進一步調查，目前為止的結果顯示：未經授權的第三方，可能已存取加密的環境變數，且其中部分變數在解密後的內容已被取得。環境變數可能包含 API key、資料庫與 registry 憑證等機密資訊。
我方認為，近期有一系列專門針對平台公司的攻擊。這是其中的一環，目標在於入侵 AI 推論服務供應商。我們已主動通知這些上游供應商，請其撤銷所有金鑰；我們對這類事件極為重視。
初步分析顯示影響範圍可能僅限於部分使用者；儘管如此，在我們完成完整檢視之前，仍建議所有使用者採取下列措施作為預防，以保護自身系統。
你應該做的事
我們強烈建議你立即輪替所有儲存於 Railway 的環境變數，包含所有 API key，以及所有私有 registry 憑證，並檢視這些服務的日誌，確認是否有異常活動。
調查期間所有部署均已暫停。在建置功能恢復之前，你無法推出新版本。對造成的不便我們深感抱歉。請追蹤下方的事件頁面，以便在建置恢復時收到通知。
在我們確認哪些帳號受到影響後，會直接以電子郵件聯繫這些客戶，並提供進一步細節。
隨著影響範圍逐步釐清，我們會在本公告以及 status.railway.com 上持續更新。
官方另補發兩篇建議公告，教使用者檢查上游雲端服務的異常存取紀錄：
- 安全揭露建議：檢查 GCP 是否有異常存取（Mykal Machon，2026 年 10 月 22 日）
- 安全揭露建議：檢查 AWS 是否有異常存取（Mykal Machon，2026 年 10 月 22 日）
Hacker News 上的反應
討論串編號 50188228，貼出三小時內累積 289 分、140 則留言。整理下來有七個主軸。
一、這是連環爆的一星期
開場留言只寫了一句「今天對資安來說真是瘋狂的一天」，底下接著補出一長串名單。
| 服務或事件 | 內容 |
|---|---|
| PHP | php2shell 遠端執行漏洞 |
| eMudhra | 憑證機構遭入侵，Cloudflare 發公告 |
| Railway | 本文事件 |
| GitLab | 發布 19.5.1 安全修補版 |
| litellm | 同樣傳出外洩事件 |
| Shopify | 大量 app 無理由下架，疑似供應鏈攻擊 |
| PingCAP | 被駭，官方的說法被網友質疑 |
| opencode | 週末發生，手法被認為與本案類似 |
| Linux kernel | 超過 50 個嚴重度 9 的 CVE |
有人追問來源歸因，認為「這麼多起，不太可能是不同組織做的吧」。整串沒有人給出可信答案，只有猜測。另一位網友提到 PingCAP 的公告寫著「外部應變廠商檢查過生產系統，沒有發現攻擊者執行指令或維持持久存取」，他直接回一句「我不覺得那是真的」。
二、對 Railway 處置的批評
火力集中在兩件事：通知太慢，以及處置自相矛盾。
- 一位網友指出，事件開始十小時後，Discord 上已經有人回報只為 Railway 建立的金鑰正在被拿去衝用量，但官方直到深夜才發信給全體客戶，此時建置已停擺超過 12 小時。
- 另一位直接問：「你停掉部署，我要怎麼輪替金鑰？這等於叫我們把服務下線。」
- 有人實測後回報，改完金鑰直接按部署其實可行；但也有人引用 X 上的說法，指輪替後的新金鑰照樣被使用。
- 已經有人把應用下線，準備搬家到別的平台。
三、已確認的受害回報
不是理論風險。Railway 的 Discord 上多人回報，存於 Railway 的 secrets 已被第三方拿去使用，這代表攻擊者確實讀到了明文。
一位工程師說他整晚在輪替 production secrets，並確認對方已經用掉他好幾把金鑰。Postiz 創辦人在 X 上指出服務被打倒、金鑰早被用掉，官方在他公開發聲前沒有回應。
需要標註的是，「輪替後的新金鑰仍被使用」這點目前只見社群轉述，當事人沒有公開證據。
四、技術主戰場：環境變數該不該存 secrets
這是整串品質最高的一段，兩派正面對撞。
| 主張 A | 主張 B |
|---|---|
| 環境變數不該存 secrets，只該存位置 | 變數本身沒問題，出問題的是 env 檔 |
| 12 Factor 在這一點上就錯了 | 這次是儲存 secrets 的資料庫被打，與注入方式無關 |
| 改用 systemd credentials 之類的機制 | 指針式做法要連開發流程一起改，成本不低 |
主張 B 的代表是 tptacek，他長期投入應用安全。他的說法是：如果環境從來不落地成持久檔案，從環境變數外洩並不比從行程記憶體外洩容易。多數「環境變數不安全」的說法，其實來自把機密寫進 .profile 或 .envrc 的壞習慣。他同時指出，這起事件的標題雖然是環境變數，但真正被打的其實是資料庫，那些變數就存在裡面。
也有人從反面提問：如果祕密放在專屬的憑證服務，應用程式就得自己去讀，開發流程也要跟著改。這正是主張 A 最難推廣的原因。
五、焦慮：這會變成日常
- 「每天都會像今天一樣，無止盡的緊急修補，接下來是難熬的十年。」
- 一位在企業任職的網友說，公司安全團隊正與前沿實驗室合作掃描所有程式與系統，處於近乎恐慌的狀態，連藏在縱深防禦底下的無害問題都要關掉，「可接受風險這個概念已經不存在了」。
- 也有人認為 LLM 加速產生 exploit，會讓現有的漏洞揭露流程撐不住。
對策則互相打架。有人提議把 hot patch 全自動化，被回「那是把更多權力讓給大公司」，也有人嗆「hot patch 本身就是負債」。有人主張少用外部相依套件、需要的部分自己寫，被反駁那只是 security through obscurity，原始程式碼一洩就完蛋。
六、PaaS 模式的檢討
有人問「一家自稱月營收 30 萬美元的公司，為什麼跑在 Railway？」，隨即被別人算出年營收 400 萬美元其實是小生意。後面出現經典酸言：這類平台本質是把 AWS 加價轉賣給怕看儀表板的人，只適合玩具專案。反方則舉客戶頁上的 Tripadvisor、Bilt 為例，說非科技業把基礎設施當玩具很常見。
還有人把矛頭指向招募文化：「那些號稱高門檻的面試流程看來白做了。」
七、一個溫暖的支線
一位網友說他一整年唯一一天休假，正要去機場，結果資安事件在頭上炸開。整串幾乎一致叫他去放假：bus factor 等於 1 是主管的問題，不是他的問題。他最後回覆，筆電沒帶，如果真要他回來，公司得先處理已訂的機票與住宿。
小結
整串的共識只有一條：金鑰要在源頭撤銷重發，不要在 Railway 介面上換個值就好。其餘爭論，包含環境變數該不該存機密、依賴該不該自己養，都還沒有答案。
一頁懶人包
手機版請開直連：Railway 金鑰外洩懶人包
如果你用 Railway，現在該做什麼
- 到每個服務的源頭撤銷舊金鑰，例如 OpenAI、Anthropic、AWS、GCP 的 console。
- 重新簽發新的金鑰。
- 檢查 GCP 的異常存取紀錄。
- 檢查 AWS 的異常存取紀錄。
- 翻 Railway 的服務日誌，找出異常呼叫。
提醒一點：直接在 Railway 介面上改值不算處理完畢。先到上游撤銷，再填入新值。
參考資料
- 原文公告：Security Disclosure: Wednesday, October 21st
- 事件狀態頁：status.railway.com
- Hacker News 討論串：item 50188228
- GCP 異常存取檢查建議：blog.railway.com
- AWS 異常存取檢查建議：blog.railway.com