10 月 21 日 20:44（UTC），Railway 在博客里承认：有人可能读到了客户存在平台上的加密环境变量，其中一部分拿到了解密后的内容。它建议所有用户立刻轮换，并在同一段里宣布所有部署暂停。1 一小时五十三分钟后，状态页补上了这份建议的另一半：部署停着，新凭证送不进去。2
这份页面改过一次，值得先把改动说清。Wayback 对它只有两张快照：10 月 21 日 21:59:37 和 23:52:30。前者抓取时页面记的修改时刻是 21:49:17，两张快照的正文逐字相同，都已经包含「目标是拿下 AI 推理供应商」和「已通知上游吊销全部密钥」两段。3 页面上记的最后一次修改是 22:12:53，而那次修改没有改动正文一个字。至于这两段是不是从 20:44 的首版就在，21:49 之前没有快照，只能到此为止。
真正值得看的是两条官方通道在这十几个小时里怎么说话。
两条通道，两种说法
状态页的事件叫「Railway Platform Outage」，07:24（UTC）开出，第一条是「We are currently investigating this issue」。2 从这一刻到 20:44，十三个小时二十分里，状态页一次都没有提安全：09:28 说「我们已经定位问题」，13:40 说 API 恢复但构建仍停，19:55 说「今天早些时候一个影响多个系统的问题让我们暂停了构建」。这一段读起来是一次普通的平台故障。
20:44，博客发出安全披露。接下来的时间线是这一期里最值得记的一段：
- 21:01，状态页写「We are validating builds for Enterprise workspaces and should be re-enabling for Enterprises broadly very soon」。这是披露上线后十七分钟。
- 21:51，Railway 官方 X 发出唯一一条通告，比博客晚六十七分钟。
- 21:59，状态页改口「We do not yet have additional information to provide about the availability of builds」。
- 22:10，状态页第一次贴上那份安全披露的链接，并说明部署对 Enterprise 客户同样暂停。
- 22:37，开始轮换全站存储桶凭证，并写下「Because deployments are paused, you will not be able to redeploy your services to pick up the new credentials until builds are restored」。2
- 22:45，状态页预告：客户会在自己的审计日志里看到撤销记录，执行人写着一名 Railway 员工的名字。
到这里，两条通道的性质才对齐。但在 21:01 那一刻，一边是「有人读到了你的解密凭证」，另一边是「构建马上要恢复了」。
为什么一个部署平台里会有推理密钥
Railway 自己的解释是一句话：「We believe this is part of a series of attacks recently targeting platform companies with the aim of compromising AI inference providers.」1
一个部署平台被盯上，原因可以很朴素：客户把调用模型的密钥和环境变量一起存在这里，因为「服务跑在这里」和「在这里调模型」已经是同一件事。攻击者要的不是数据库里的业务数据，是能拿去向模型厂商计费的那串字符。
四天前有一件同形的。10 月 17 日 17:56（UTC），OpenCode 在 X 上承认 Console 被入侵，措辞是「a large scale distillation attack that impacted 1.4% of OpenCode Console users」，并说正在与 Anthropic、OpenAI、Google 一起处理。4 官方给的比例只到「Console 用户的 1.4%」，没有给绝对人数；它明确说范围限于 Console，不是 OpenCode 本体。5 之后三家的动作各不相同：Anthropic 的 Lydia Hallie 在 17 日 21:04 说已吊销受影响的 Claude key，6 OpenAI 的 Tibo 在 19 日 04:12 说已让受影响用户恢复并把攻击期间消耗的 credits 退还，7 Google 的动作由 TechCrunch 转述为封禁相关 key。8
就在同一天晚上，LiteLLM 1.107.0 的载荷里也分出一组模块，专门去收 AI 编程工具的 token。三条入口分别在包、在 Console、在 PaaS 的环境变量里，取的是同一类东西。
要说清一点：没有任何一方把这几起归到同一个攻击者。 Railway 用的是「we believe」，没有点名任何受害平台，也没有给技术同源的证据；网络安全公司 Cyera 在分析 OpenCode 那件时写得很直接：「No one has publicly attributed the OpenCode attack.」9 所以能说的是「同一类资产被反复盯上」，不是「同一批人干的」。
一串字符在平台上要走三段路
Railway 的披露里有一句话把机制说完了：被读到的是「加密的」环境变量，其中一部分，攻击者拿到了「解密后的内容」。1 加密和明文之间那一步，不在磁盘上。
第一段是存放。Railway 的文档写着所有变量都加密存放，私有镜像仓库的凭证用信封加密，「Credentials are only decrypted at deployment time when pulling your image.」10 这句话本身就把第二段交代了：解密发生在部署那一刻。
第二段是取出。平台必须在部署时把明文交给你的进程，否则注入不了。所以「谁能站到部署那一刻」，就等于「谁能读到明文」。这也解释了为什么更严的那一档保护并不解决问题——Railway 有个叫封存（seal）的功能，文档写得很诚实：「When a variable is sealed, its value is provided to builds and deployments but is never visible in the UI nor can it be retrieved via the API.」同一节里还有一句更短的：「Sealing changes visibility, not availability」。11 封存挡的是界面和 API，不是那条把值送出去的通道。
第三段是远端。平台拿着这把钥匙，可以在你的上游说话。这次它做的是反过来的一件事：通知上游把所有密钥主动吊销。1
还有第四笔，多数人不会注意：22:45 状态页说，客户会在自己的审计日志或活动面板里看到撤销存储桶凭证的记录，执行人写着一名 Railway 员工的名字，并且「This is expected」。2 这句话的意思是，一个第三方可以在你另一个账号的账本上留名——对于做审计的人来说，这比泄漏本身更难解释。
客户侧的证词也来了，但要打折看。10 月 21 日 21:04，YC F25 公司 Lapis 的创始人 Varunram Ganesh 写「Attackers are draining keys in real time, we didn't lose much but can confirm this is still an active attack」。12 21:11，Postiz 创始人 Nevo David 宣布关停全部客户服务，理由是「We have received emails from Anthropic and Stripe that our keys have been compromised」。13 两帖都没有贴用量或账单截图，属于具名用户的说法，不是证据链；但它们指向同一个方向：先动的是上游和支付方，不是平台。
一份执行不了的处置建议
回到 22:37 那句话。它建议所有人立刻轮换，同时承认新凭证在构建恢复前送不进服务。这两句话放在一起，处置就成了一件做不到的事：
you will not be able to redeploy your services to pick up the new credentials until builds are restored
这不是措辞问题，是结构问题。托管平台的价值在于把「值」和「用」连起来：你在控制台写一个变量，它在下次部署时替你注入。这条链路既是便利，也是轮换的唯一通道。通道在平台手里，而这一次，通道被平台自己关了。
用户那晚的实测还分成两派。22:45 有人问「How is it possible rotate keys if you disable deployments?」，14 23:27 另一位说自己换完 key 却部署不了、站点已经下线，14 23:40 又有人说「I rotated mine. If you just change the keys and hit deploy it works」。14 官方的边界写在状态页上，用户的边界写在自己的项目里，两者当晚并不一致——这条分歧只能留给实测，不能替它下结论。
还有一个更早的口径差：博客说「Earlier this morning, Railway detected anomalous activity」，把 07:24 起的停摆回溯成一次入侵；状态页在同一时段写的却是故障。同一件事，两条通道给了两种性质，中间隔了十三个小时二十分。
托管交出去的是什么
把这一夜拆开，托管平台对一把密钥实际握着三样东西：
一是取出。它必须解密才能注入，所以它在设计上就有明文的那一瞬间。加密保护的是磁盘，封存保护的是界面，两者都不覆盖这一瞬间。
二是作废。它可以在你的上游把钥匙吊销。这次它做了，动作比你快——你还没决定要不要换，你的 key 可能已经失效了。
三是署名。它可以在你别的账号里留下记录，替你撤销、替你操作。
这三样加起来，「把密钥存在托管平台」不是一次保管，是一次授权。授权的代价不在平时，在出事的那一小时：你打算按它说的做，却发现做这件事的路由它管着。
所以判断一家托管平台，问的不是「它会不会泄漏」——都会——而是出事之后，你能不能不经过它把这把钥匙换掉。顺着这个问法，有四句话可以照着问：
- 出事时，我能不经过这家平台完成轮换吗？Railway 这次：不能。
- 明文会在哪一层出现？能让它只在我控制的那一层解密吗？Railway：部署那一刻，由平台取出、注入。
- 这家平台能让上游吊销我的密钥吗？能，而且这次它做了。
- 它的两条通道说的是同一件事吗？20:44 的披露，与 21:01 的「很快恢复」，隔 17 分钟。
边界
上游供应商一家都没有被点名，也没有任何一家公开表示因这次事件吊销过 Railway 客户的密钥：OpenAI、Anthropic、Google Cloud、Mistral、Cohere 的状态页截至 10 月 22 日 00:05（UTC）都没有相关条目1516，xAI 的状态页被 Cloudflare 拦住，未能核验。 Railway 说的是「通知上游去吊销」，那是它的动作，不是上游的声明。
受影响账号数没有公布，官方只写「may be limited to a subset of users」，同时建议所有人按最坏情况处置。1 截至同一时刻，状态页仍是 Identified / Major Outage，构建未恢复，也还没有出现 Railway 惯常会发的事后报告。
还有一件可以留意的旁证：截至 10 月 22 日 00:05（UTC），The Register、TechCrunch、The Verge、Ars Technica、The Hacker News 的头条流里都没有这件事的自有稿件。一条当时 231 分的 Hacker News 主贴、一家主要 PaaS 的凭证事故，在英文科技媒体上过了一夜还是空白。14
今晚能做的三件事
一，先在上游吊销，不要在平台上改。 平台的界面此刻可能既改不了也发不出去；上游的吊销是立刻生效的，而且它决定的是这段窗口里别人还能不能花你的钱。
二，把「哪里能部署」写进轮换预案。 轮换不是一个按钮，是一条路径：生成新值、写进配置、重启进程、验证。这次断在第三步。选平台的时候，这条路径里有多少段必须经过它，是一个可以事先数清楚的数量。
三，给每一把放在平台里的推理密钥设消费上限和告警。 泄漏这件事你控制不了；泄漏之后被用掉多少，你还有一点控制权——而账单通常是唯一会在事后留下痕迹的那一层。
References
- 1Security Disclosure: Wednesday October 21st · Railway Blog
blog.railway.com
- 2Railway Platform Outage · Railway Status
status.railway.com
- 3Wayback 21:59:37 快照 · Railway Blog
web.archive.org
- 4OpenCode 官方声明 · X
x.com
- 5
- 6Lydia Hallie · X
x.com
- 7Tibo · X
x.com
- 8TechCrunch · OpenCode 入侵
techcrunch.com
- 9Cyera · OpenCode 事件分析
cyera.com
- 10Build-time vs runtime secrets · Railway Docs
docs.railway.com
- 11Using Variables · Railway Docs
docs.railway.com
- 12Varunram Ganesh · X
x.com
- 13Nevo David · X
x.com
- 14Hacker News · Railway Security Disclosure
news.ycombinator.com
- 15OpenAI Status · 历史事件
status.openai.com
- 16Claude Status · 历史事件
status.claude.com
Comments