2026年10月21日（星期三）上午，Railway（Railway）检测到存储客户环境变量的系统异常，调查发现未授权第三方可能已访问加密环境变量并获取部分解密内容，其中或有 API 密钥等机密。Railway 认为这属于针对平台公司、以攻陷 AI 推理服务商的系列攻击，已通知上游服务商主动吊销全部密钥，并建议所有用户立即轮换 Railway 内全部环境变量（含 API 密钥）与私有注册表凭据，检查相关日志。

今天早上，Railway 检测到存储客户环境变量的系统出现异常活动。进一步调查后，目前的调查结果显示，未经授权的第三方可能已访问加密的环境变量，其中一部分的解密内容可能已被获取。环境变量可能包含 API 密钥、数据库凭证和镜像仓库凭证等机密。

我们认为，这是近期一系列针对平台公司的攻击的一部分，目的是入侵 AI 推理服务商。我们已通知这些上游服务商主动吊销所有密钥，因为我们对此类事件极为重视。

初步分析显示，影响可能只限于部分用户；但在我们完成审查期间，仍建议所有用户采取以下措施，作为保护系统的预防手段。

你应该做的事： 因此，我们强烈建议你立即轮换存储在 Railway 中的所有环境变量，包括任何 API 密钥，以及所有私有镜像仓库凭证，并检查这些服务的日志是否有异常活动。

调查期间，所有部署已暂停。在构建功能恢复前，你将无法发布新版本。我们对此造成的不便表示歉意。请关注此事件，以便在构建恢复时收到通知。

随着我们确认哪些账户受到影响，我们将直接通过电子邮件联系这些客户，提供更多详情。

随着影响范围的缩小，我们将在本公告以及 status.railway.com 上发布新的更新。

讨论气氛疲惫而焦虑：多数人确认 Railway 存储的解密环境变量与密钥已被第三方实际使用，并对平台响应迟缓、沟通不透明极为不满。分歧主轴是“必须立刻在源头轮换密钥”和“部署已被禁用、轮换等于停机”之间的两难，也有人怀疑这是针对 AI 推理供应商的更大攻击，甚至暗指大厂竞争。

确认解密后的环境变量与密钥已被第三方实际使用

• 多名用户在 Railway 的 Discord 反馈存储的密钥已被第三方使用，攻击者似乎能读取已解密的环境变量；原本以为密钥会放在 Vault 并由 sidecar 注入，但现实并非如此，Postiz 创始人也称密钥已被使用且在公开喊话前 Railway 一直沉默。（认可度：高赞）
• 需要引用时，只用一句中文意译： > 我看到 Railway Discord 里多人确认，存在 Railway 的密钥已被第三方使用，攻击者应该能读取解密后的环境变量。（@MattIPv4）

批评 Railway 响应迟缓、沟通不透明且事故期间仍在发生盗用

• 事故开始约 10 小时后，Discord 上仍有人报告专为 Railway 创建的密钥在被消耗额度；构建与部署中断超过 12 小时，面向所有客户的邮件却迟迟才发出，许多用户只能靠刷 Discord 才知情，有人因此追问云厂商是否该提供一键停止所有支出的“锁死”模式。（认可度：较多人）
• 需要引用时，只用一句中文意译： > 一团乱：事故发生 10 小时后在 Discord 上还有人在说，专为 Railway 建的密钥正在被消耗额度；构建中断已超过 12 小时，直到现在才给所有客户发邮件。（@alpineman）

主张立即在源头轮换所有 API 密钥

• Railway 仍未被认定为安全，用户不应等待，要在密钥来源处吊销并轮换所有 API 密钥；在平台恢复前不要设置新的环境变量值，否则等于继续暴露给攻击者。（认可度：少数人）
• 需要引用时，只用一句中文意译： > 别等了，在源头轮换每一个 API 密钥；Railway 还没加固，不要写入新值。（@sergiotapia）

指出部署被禁用使轮换无法落地，等效于停机

• Railway 已禁用部署与构建，用户即便在源头吊销旧密钥并生成新密钥，也无法通过平台部署来更新环境变量；有用户换了新密钥后应用仍因不允许部署而下线，这使“立刻轮换”的建议在现实中变成了被迫停机或迁移。（认可度：较多人）
• 需要引用时，只用一句中文意译： > 如果部署被禁用，怎么轮换密钥？你等于让我们把服务下线。（@fbrncci）

嘲讽把“攻击者使用 AI”当作安全失职的挡箭牌

• 有人认为现在每次泄露通报都要加一句“攻击者用了 AI”，好像这样就能免除维护安全系统的责任；反而更糟——如果 AI 真能用来发现漏洞，自家红队本应比攻击者更早就发现。（认可度：少数人）
• 需要引用时，只用一句中文意译： > 现在每次泄露都非要加一句“攻击者用了 AI”，好像这样就能免除维护安全系统的责任；如果 AI 真能找到漏洞，自家红队本该更早发现。（@paxy）

怀疑这是针对 AI 推理供应商的更大攻击，甚至暗指大厂竞争

• 有人抓住官方“这是一系列针对平台公司、意在攻陷 AI 推理供应商的攻击”的表述，质疑这是不是一种指控，怀疑背后可能是大型 AI 公司在清除竞争对手。（认可度：少数人）
• 需要引用时，只用一句中文意译： > 这算指控吗？像是在说大型 AI 玩家在干掉竞争对手？（@torben-friis）

对近期安全事件连发感到疲惫，认为更大浪潮才刚开始

• 评论者把 Railway 事件与同期的 PHP 远程代码执行漏洞、eMudhra 证书泄露并列，称过去 24 小时或两天对安全从业者非常难熬；有人预感每天都会是紧急补丁和泄露，甚至认为这才刚开始，需要重新雇佣靠谱程序员来应对即将展开的大规模漏洞。（认可度：高赞）
• 需要引用时，只用一句中文意译： > 网络安全疯狂的一天：PHP 远程代码执行漏洞、eMudhra 证书，现在又是 Railway；在我看来这一切才刚开始。（@vldszn）

对 Railway 失去信任，考虑迁到自托管或虚拟专用服务器

• 有人庆幸已迁走、用 Coolify 自托管数据库；也有人宣布要把项目迁离 Railway，认为如今借助 AI 完全可以直接用真正的虚拟专用服务器，并在问 Hetzner 还是 OVH 更合适。极端批评称 Railway 是自己注册过最差的服务。（认可度：少数人）
• 需要引用时，只用一句中文意译： > 我要把项目迁离 Railway；如今有 AI，没理由不敢直接用真正的虚拟专用服务器。（@sergiotapia）

有价值的补充

• 有用户指出，原本以为 Railway 的密钥会存放在 Vault 中，并通过 sidecar 注入到运行环境；但攻击者能读取解密后的环境变量，说明实际存储与注入方式可能并非这种隔离架构，密钥管理显得很粗糙，甚至被吐槽像是在凭感觉写代码。
• 社区借 Railway 与“铁路、火车”的字面意思玩双关：把这次事故形容为列车脱轨般的灾难，也有人点进讨论前以为是在聊火车。这类文字游戏把平台名和失控的列车事故联系在一起，代表了无奈和调侃。