Railway 确认遭黑客攻击，约10万个 workspace 密钥或泄露

面向开发者的云部署平台 Railway 已确认，其内部系统自2026年10月20日起遭到攻击。攻击者读取了客户加密存储的环境变量，并解密了其中一部分，最多1.85%的 workspace（约10万个）可能受影响。

Railway 在初步报告中称，攻击者寻找的是 AI 服务商的 API 密钥，用于蒸馏模型。公司已请 GitHub、GitLab、Anthropic、OpenAI、OpenRouter、Stripe 和 Google 等服务商吊销密钥，并建议所有用户轮换存放在平台上的敏感变量。

从告警到清除约37小时

按 Railway 初步报告的时间线，最初的信号出现在 10 月 20 日 UTC 13:58，监控系统因延迟升高呼叫值班工程师。14:03 至 16:51 的排查才识别出，基础设施的构建环节有人在尝试权限提升。公司随即停掉流水线，17:03 在状态页开启事件公告，并在近两个小时里认为漏洞已堵上，因为相关利用看起来已被修复且无法复现。19:53 出现相反证据：攻击者可以并行把访问权限扩展到系统的多个部分。

次日情况进一步恶化。10 月 21 日 04:24 至 05:23，攻击者从数据库中提取仍处于加密状态的机密；05:27 至 07:25 取得 CI 凭据，并解密了可打开其他 API 访问通道的文件；07:25 至 09:18，数据库日志显示有人未经授权查询环境变量，其中一部分已用被盗凭据解密。09:25，Railway 请各服务商吊销密钥，自 09:28 起控制台、API 和 CLI 停止可用，构建功能被关闭。

10 月 22 日 03:32，攻击者的访问权限被清除；17:00 至 22:49，所有套餐的 API 和部署恢复正常。从首次告警到访问被清除前后约 37 小时。公司表示，已经上线的服务全程保持运行，停下来的是新的部署，因此暂停期间推送的提交没有发布出去。至于攻击者最初如何进入构建基础设施，报告没有说明。

受影响范围与通知口径

Railway 表示无法说清具体是哪些：密钥采用信封加密，一把密钥保管其他密钥，仅凭日志查询无法分辨单个密钥。公司给出的关键数字是 1.85%，即最多这一比例的 workspace 存在环境变量可能被泄露的情况，换算成绝对数量约为 10 万个。

通知范围大于确认范围。Railway 会通知已确认受影响的客户，以及一个范围更大、被认定有风险的群体；公司还让服务商为并未显示受影响的用户一并重置密钥，因此重置请求涉及的用户超过 10 万人。报告提到收到通知的服务商包括 GitHub、GitLab、Anthropic、OpenAI、OpenRouter、Stripe 和 Google，同时提醒，收到吊销通知并不意味着自己的凭据已经被盗。

公司保证 Railway 用户账户没有被攻破。至于客户的源代码，则并未被排除在受影响范围之外，是否被读取要等最终报告确认。报告也承认，1.85% 是公司自己测算的上限，没收到邮件不等于安全。

攻击动机与蒸馏

蒸馏是一种训练专用模型的技术：用更大模型的回答作为训练数据，这些回答通过海量 API 请求收集而来。若用的是被盗密钥，每一次请求的费用都由受害者承担，服务商也很难识别滥用。报告 FAQ 进一步说明，目的是蒸馏模型权重。

公司还提到，攻击者手里有 abliterated 模型（被移除拒答机制的开放模型）和大量算力；据报告，攻击者锁定的是价值最高的目标，也就是环境变量多、或持有大量 AI 服务商密钥的 workspace。

这一套路与近期其他事件相似。开源终端编程智能体 OpenCode 把 10 月中旬针对其 Console 的入侵称为大规模蒸馏攻击，Console 有 1.4% 的用户受到影响。10 月 14 日和 15 日，另一个云部署平台 Zeabur 被攻击者读取了 3,218,965 条环境变量记录，创始人随后宣布将在 12 月 31 日前关闭服务。Railway 把自己的事件归入针对平台类公司、意在攻击 AI 推理服务商的一系列攻击，但没有点出其他受害者；三起事件之间有无关联，目前没有人给出证据。

报告没有点名攻击者，没有展示密钥被如何使用，大部分技术性入侵指标也未公开。因此无论攻击者意图如何，用户面临的实际风险仍是 AI 账单被刷高。这份文件只是初步报告，最终报告的发布日期尚未给出。

赔偿条款与钱包传闻

10 月 21 日 UTC 19:36，早于报告所称 20:19 至 22:10 之间发出的公开通告，一批加密钱包开始被掏空。安全研究员 Taylor Monahan 怀疑这些钱包的私钥存放在 Railway 上。据 CryptoTicker 报道，Monahan 统计的金额约为 371,000 美元，涉及 200 多个地址的 500 多笔交易，横跨至少 19 条 EVM 区块链，资金疑似通过常见的 sweeper 脚本转走。Onchain Lens 则指出，有一个可疑钱包至少向交易所 HitBTC 和其他地址转移了 369,300 美元，但与 Railway 的联系尚未确认。

损失了钱的人还要面对服务条款。自 2026 年 4 月 20 日起生效的版本排除了间接损失，包括数据丢失和业务中断，并把总赔偿责任限定为 100 美元与客户在索赔前十二个月内已付或应付费用两者中的较高者。Dennis Weidner 在评论中指出，这一条款没有为故意或重大过失设置例外，并认为在德国站不稳脚；不过 Railway 选择了特拉华州法律，在企业之间有效。这些是作者本人的看法，责任上限条款的原文可在服务条款中查见。

与加密货币被盗的关联尚未得到证实。目前流传的两组统计来自不同来源，不能相加；Railway 也没有说过那些密钥存放在它的平台上。

用户应对建议

Railway 建议，即使没有收到通知，也应当采取行动。第一步是吊销并重置存放在 Railway 上的敏感变量，至少是 10 月 21 日之前创建的，数据库里的密钥和机密同样要轮换；同时关闭数据库的公网访问。

第二步是检查 GitHub 审计日志和已安装的应用、Docker Hub 或其他 registry 的日志，以及 GCP 上的异常登录，Railway 为此专门写了一份指南。第三步是重新发布最新一次提交，因为暂停期间推送的提交没有被部署，并重新关联 GitHub、重建 CLI 和 CI 的凭据。若 GitHub 邮箱与 Railway 邮箱不一致，应选择用邮箱登录。

如果在 Railway 上存放过 OpenAI、Anthropic、Google 或 OpenRouter 的密钥，最要紧的一步在服务商一侧：设置消费上限，并查看 10 月 20 日以来的用量。轮换时应先吊销旧密钥，再签发新密钥，使被盗副本立刻失效。对于存放在平台上的加密钱包私钥，应视为已经暴露，只改变量没有用，需要新建钱包并尽快转移资金。Railway 表示取证调查仍在进行，最终报告将回答入侵如何开始、客户代码是否被读取。

要点

• 攻击自2026年10月20日起，22日清除攻击者访问权限
• 最多1.85%的workspace受影响，约合10万个
• 从首次告警到清除访问权限约37小时
• 已上线服务全程运行，暂停的是新部署
• Railway称攻击动机是获取AI密钥用于蒸馏