Railway 安全披露：环境变量遭泄露，所有部署已暂停

Railway 于10月21日披露，未经授权的第三方可能访问了客户的环境变量，并且对于其中一些变量，已获取解密后的内容——平台在告知所有客户轮换所有密钥的同时，暂停了所有部署。Hacker News 上关于此披露的讨论帖（547 分，318 条评论）中，开发者们主要报告被盗密钥已被使用，以及一个操作上的矛盾：用户被告知要轮换凭据，但在构建被禁用期间无法重新部署以获取新值。

Railway 实际披露的内容

Railway 表示，他们在10月21日上午检测到存储客户环境变量的系统出现异常活动，并且迄今为止的调查表明，未经授权的第三方可能访问了加密的环境变量，并且对于其中一些变量，已获取解密后的内容。

披露内容如下：

今天早上早些时候，Railway 检测到涉及存储客户环境变量的系统的异常活动。经过进一步调查，我们迄今为止的调查表明，未经授权的第三方可能访问了加密的环境变量，并且对于其中一些变量，已获取解密后的内容。环境变量可能包含诸如 API 密钥或数据库和注册表凭据等机密信息。

Railway 陈述的关键点：

Railway 上的环境变量可能包含 API 密钥、数据库凭据和私有注册表凭据等机密信息。
Railway 认为此次入侵是“最近针对平台公司的一系列攻击的一部分，旨在入侵 AI 推理提供商。”
Railway 表示已通知这些上游提供商，以便他们主动撤销密钥。
Railway 的初步分析表明，影响可能仅限于部分用户，但建议所有用户采取预防措施。
建议操作：“立即轮换存储在 Railway 中的所有环境变量，包括任何 API 密钥，以及任何私有注册表凭据，并检查这些服务的日志是否有异常活动。”
在 Railway 调查期间，所有部署均已暂停，因此在构建恢复之前，用户无法推出新版本。
Railway 表示将直接通过电子邮件联系确认受影响的账户，并将在其博客公告和 status.railway.com 上发布更新，引用事件编号 QH8L8B3E。

核心矛盾：轮换你的密钥，但无法重新部署

讨论帖中最常被重复的抱怨是，Railway 的两条指示对许多用户来说是相互排斥的：在 Railway 内部轮换密钥对正在运行的服务没有影响，直到该服务被重新部署，而部署已被暂停。

“如果禁用部署，怎么可能轮换密钥？你基本上是在告诉我们让服务下线……” — fyzix

“你能解释一下我们如何在不宕机的情况下轮换密钥吗？” — fmvilas

“我更改了环境变量中的 API 密钥，因为 OpenRouter 基于此事件撤销了之前的密钥。但是，由于我所在地区无法重新部署，环境变量无法更新，现在产品无法使用。” — averrous

几位评论者描述说，遵循建议后情况比以前更糟。一位在当地时间凌晨 5：20 轮换密钥的开发者写道，日志显示没有错误使用的迹象，如果他们不采取行动，他们的服务“至少会保持在线”。另一位表示，他们在撤销密钥后应用宕机，且无法重新部署。rdm_blackhole 报告说，Railway 重新生成了存储桶凭据，但部署仍然停止，因此服务根本无法连接到存储桶，称这种顺序“完全愚蠢”。

rdm_blackhole 还在讨论帖中稍后报告说，截至欧洲中部时间上午 11：43，构建仍卡在队列中，没有重新部署就无法有效轮换密钥，Discord 验证不可能完成，仪表板中的支持链接指向 404 页面。

开发者报告称泄露的密钥已被使用

讨论帖中包含多个第一手报告，称被盗凭据在披露之前或之后不久就被第三方使用——尤其是 LLM API 密钥。

“我整晚都在轮换生产密钥……太糟糕了。我确认他们已经使用了我许多密钥。” — dylanz

“看到 Railway Discord 中有多人确认他们存储在 Railway 中的密钥已被第三方使用，所以听起来攻击者确实能够读取解密后的环境变量。” — MattIPv4

讨论帖中的具体报告：

一位评论者说，在收到 Railway 通知大约三小时后，由于存在未经授权滥用的证据，他们在 Railway 部署中使用的 Anthropic API 密钥被禁用，在检测到滥用之前产生了约 20 美元的令牌消费。
另一位说他们的 OpenRouter 密钥被盗，并被用来产生了约 2 美元的费用。
第三位说他们的 OpenRouter 仪表板显示了对他们没有发起的 Anthropic 模型的 API 调用，日志显示使用 Go HTTP 客户端，并且仅将 Anthropic 作为提供商。他们写道：“很确定主要目标是 LLM API 密钥……”
cowlby 发布了审计日志条目，显示 Railway 工作人员于 10 月 21 日 CDT 下午 5：54：13 三次执行了 BucketInstanceCredential.regenerated，并推断如果数据库和存储桶凭据存在于环境变量中，攻击者可能也访问了数据库和存储桶的内容。

另一位评论者询问被盗的 LLM 密钥如何变现，推测有一个可疑的 AI 多路复用器在转售基于受损密钥的廉价推理——讨论帖中没有回答这个问题。

“针对 AI 推理提供商的攻击”框架引发怀疑

Railway 关于该活动旨在入侵 AI 推理提供商的声明并未被普遍接受为背景信息，一些评论者认为这种框架本身是在转移话题。

“有趣的是，每次安全漏洞披露现在都必须包含一个强制性的‘攻击者使用了 AI！’部分，好像这就能免除你维护安全系统的责任。如果有什么不同的话，这反而让情况更糟。如果有可能使用 AI 找到漏洞，那么你自己的红队应该在攻击者之前就发现它们。” — paxy

其他人则提出了披露中未回答的基本架构问题：加密的密钥是如何被解密的。

“密钥是如何被解密的，我希望得到一些解释，以便我能有所了解……环境变量密钥是如何泄露给所有人的……” — minraws

“有人设法获取了环境变量以及这些变量的加密密钥？我现在为那里的安全运维工程师感到难过。太残酷了” — ksajadi

披露中未说明解密是如何发生的，也未说明有多少账户受到影响。

沟通和时机方面的抱怨

一个反复出现的主题是，用户早在收到电子邮件之前，就从 Discord 服务器或状态页面得知了该事件。

“人们 3 小时前就在 Discord 上写道，事件开始 10 小时后，仅为 Railway 创建的密钥正在产生使用量。与此同时，构建已经宕机超过 12 小时。直到现在他们才向所有客户发送电子邮件。” — alpineman

一位评论者说他们在 23：36 收到了电子邮件，一位欧洲开发者说当他们醒来看到消息时，部署已经宕机了 24 小时，并补充说“他们等到凌晨 2 点才说这件事，感觉太疯狂了。”另一位指出，披露信息位于博客子域上，而营销主页仍然写着“安心交付软件”，没有提及该事件。

另外，一位评论者声称：“Railway 对他们上次重大宕机的原因并不诚实，”另一位说他们在今年早些时候发生的一起泄露客户数据的事件后，已经将主要客户从 Railway 迁移走了。

同一天更广泛的背景

评论者将 Railway 事件视为安全团队糟糕的 24 小时的一部分。

“网络安全疯狂的一天：PHP RCE、eMudhra 证书，现在又是 Railway。而且在我看来，这才刚刚开始。” — vldszn

该评论链接到 Cloudflare 关于 eMudhra 证书泄露的帖子，以及 Wiz 关于 PHP RCE 的帖子。另一位评论者将 Railway 事件与 opencode 周末遭受的黑客攻击进行了比较，还有人开玩笑说他们预计接下来会“醒来看到 Vercel 出问题”。

迁移讨论：VPS、Cloud Run、fly.io、自托管

几位评论者表示，该事件加上多天的部署暂停，正在促使他们离开该平台。

一位开发者表示，在 Railway 上次宕机后，他们曾考虑迁移到 Cloud Run，给了该平台另一次机会，现在认为留下来的可能性不大。
另一位表示，他们紧急迁移到了 fly.io，中断最小，并建议其他人立即迁移，以便可以更改环境变量，并补充说：“永远不要再给 Railway 一分钱。”
另一位表示，他们使用 Coolify 将数据库迁移到了自托管。
有人问 Hetzner 或 OVH 目前是否是直接托管项目的最佳 VPS 选择。

另一位评论者则完全反对环境变量这种模式，推荐了一个开源嵌入式密钥存储库，该库将密钥与代码一起在 git 中进行版本控制，适用于 Rust、Go、PHP、Python、JS/TS、C#/.NET、PowerShell 和 bash。

Railway 用户的实际情况

截至讨论帖中捕捉到的讨论，情况是：构建已暂停，因此在受影响的账户上无法重新部署以获取轮换后的凭据；据报道，包括 OpenRouter 在内的上游提供商已主动使密钥失效；Railway 表示将通过电子邮件联系确认受影响的账户。

根据披露和讨论帖直接得出的步骤：

将存储在 Railway 环境变量中的每个密钥都视为可能已泄露，包括数据库凭据、存储桶凭据、私有注册表凭据和 API 密钥。
检查提供商仪表板和服务日志中是否有未经授权的使用。多位评论者在提供商仪表板中发现了使用证据，而不是在他们自己的应用程序日志中。
预计轮换后需要重新部署，因此预计在构建暂停期间会持续宕机；关注 status.railway.com 上的事件 QH8L8B3E 以了解恢复情况。
检查 Railway 的审计日志，查看是否有工作人员发起的凭据重新生成事件。

仍未解答的问题

披露和讨论帖留下了几个未解决的问题，材料中没有来源能解答这些问题：

加密的环境变量是如何被解密的，以及加密密钥本身是否被获取。
受影响账户的确切数量或比例。
构建何时恢复。
攻击者如何将被入侵的 API 密钥变现。
Railway 是否会在构建恢复后自动重新部署客户服务，一位评论者明确希望如此，同时担心他们不会测试结果。

一位评论者对实际权衡的总结捕捉了讨论帖的情绪：在部署暂停的情况下，“哪个更糟：被盗的密钥还是损坏的产品？”