从构建逃逸到 AI 密钥窃取：Railway“10·21”攻击全链路复盘

原创 威胁情报中心 2026-11-11 17:03 北京

Railway 于 2026 年 11 月 10 日公布详细调查结果：最多 1.85%、约 10 万个工作区的部分环境变量可能被解密，被盗密钥造成的未经授权消费估计约 74 万美元。

01 先看结论：攻击者击穿的是一条“信任链”

Railway 将此次事件称为“10 月 21 日安全攻击”，但成功入侵实际开始于 10 月 20 日 07:28，攻击者创建测试账号的准备工作则可追溯至 10 月 18 日。从首次成功利用到 10 月 21 日 09:24 被完全驱逐，历时约 26 小时。

这起事件最值得关注的，不是某一个漏洞造成了多大破坏，而是多个原本应当彼此隔离的信任关系被逐段打通：

1. 攻击者利用构建基础设施中此前未知的漏洞，局部逃逸文件系统隔离，读取宿主机上的部分文件并取得构建凭据
2. 本应主要用于构建产物推送等任务的凭据，却被内部 Temporal 实例接受为可信客户端，攻击者由此读取其他构建的历史记录和 Railway 内部单体仓库快照
3. 在首个入口被封堵后，攻击者利用已掌握的代码信息寻找新路径，发现云环境中错误定义的 OIDC 绑定配置，取得短期云凭据
4. 短期云凭据进一步暴露内部长期凭据和 CD 系统使用的 SSH 私钥，攻击者登录内部编排节点，又获得可用于解密环境变量的长期凭据
5. 攻击者读取数据库中的加密变量，并通过密钥管理服务完成部分解密，重点筛选 AI 服务厂商凭据

因此，将其简单概括为“构建系统漏洞导致密钥泄露”并不完整。构建逃逸是入口，跨服务信任过宽、CI/CD 身份绑定错误、内部节点长期凭据以及解密权限，共同构成了后续攻击链。

核心影响一览

这里尤其需要正确理解“最多 1.85%”：Railway 的日志能够定位到受影响的环境集合，但不能逐个确认具体哪些变量被解密，因此约 10 万个工作区是可能影响上限，而不是已经逐一证实泄露的变量数量。

02 第一阶段：局部逃逸如何变成内部凭据泄露

10 月 20 日 06:50，攻击者开始探测 Railway 的构建基础设施。当时，该系统采用多租户架构，多个彼此隔离的构建任务可以运行在同一台虚拟机上。

07:28，攻击者利用一个此前未知的漏洞，部分逃逸文件系统隔离。这次突破赋予的能力是读取宿主虚拟机上的部分文件，而不是公开证据所支持的“完全控制宿主机”。Railway 未披露具体 CVE 或底层漏洞细节。

在被读取的文件中，攻击者找到一项构建服务器用于访问部分内部系统的凭据。该凭据原本服务于构建完成后的镜像推送等操作。攻击者最初尝试在多个系统中使用它，但并未立即成功。

真正的检测转折点出现在 13:58：存储已完成构建产物的 registry 服务出现异常 API 调用，值班工程师收到告警。调查人员将异常调用追溯到失陷的构建凭据，再进一步定位到发生局部隔离逃逸的构建任务。

Railway 随后采取并行处置：修复隔离问题、暂停构建、限制攻击者活动，并通过审计日志、链路追踪和其他遥测信号持续观察攻击行为。17:03，构建首次被暂停；17:28，失陷构建凭据被撤销并替换，同时构建服务器可访问的服务范围被收紧。

这一阶段说明，入口漏洞与影响扩大之间还存在一道关键边界：从宿主机文件中取得的凭据，究竟能被多少内部系统接受。

03 第二阶段：Temporal 信任扩大，构建历史与内部源码暴露

Railway 使用 Temporal 调度和执行异步任务，当时的构建系统依靠一个自托管 Temporal 集群驱动部分构建流程。相关任务中包含多类敏感信息：

• 用于克隆单个仓库、仅限只读的 GitHub App token
• 传入构建过程的环境变量和 secrets
• 构建产物及构建执行方式等元数据

失陷构建凭据的设计目的，是完成镜像推送等构建工作，并不应获得任意内部访问能力。但内部 Temporal 实例将该凭据接受为可信客户端。攻击者利用相应客户端 API，读取了有限范围的其他构建历史，其中包括部分构建变量。

调查确认，攻击者在 10 月 20 日 13:50—15:30 共读取 353 个构建的历史记录，其中包括 sealed variables。

影响并未停留在构建元数据。Railway 的许多内部服务从一个内部 monorepo 部署，支持平台 station.railway.com 也在其中。攻击者从 Temporal 中取得了该服务的一次近期构建记录，又利用构建凭据获取用于缓存的仓库状态快照，最终取得一份内部 monorepo 副本。

这份代码副本为攻击者提供了内部架构、接口和潜在攻击面的详细视图。Railway 后来观察到，攻击者开始探测一些已经数周、数月甚至数年未使用、且系统中已无现存引用的端点，才意识到对方已经掌握代码。

这里有一个重要的处置边界：撤销凭据可以切断凭据的后续使用，却无法收回已经泄露的源码及其带来的内部信息优势。Railway 在验证首条提权路径后恢复构建，攻击者再次尝试逃逸构建隔离但未成功，随后便转向从代码中发现的新路径。

Railway 同时表示，没有迹象表明攻击者在这一阶段下载了客户的代码快照或仓库。

04 第三阶段：错误 OIDC 绑定打开第二条入口

10 月 21 日 03:26，攻击者通过 Railway 一个云环境中错误定义的 OIDC 绑定配置，取得了可访问生产基础设施的短期云凭据。

Railway 的内部系统通过 CI/CD 自动构建和部署，CI/CD 系统可以获取短期云凭据，用于向生产环境发布变更。此次问题不是 OIDC 协议本身被攻破，而是身份与访问信任关系被错误配置，使攻击者获得了本不应取得的凭据。

攻击者随后利用这项短期云凭据，从云环境中取得两类关键内部凭据：

• 一项长期凭据：与内部 VPC 网络访问结合后，可读取生产数据库中的加密环境变量
• 一把 SSH 私钥：CD 系统原本使用它向特定机器推送二进制文件

攻击者使用 SSH 私钥连接了一台负责 fleet 编排任务的机器。该节点磁盘中又保存着一项长期凭据，可用于解密加密变量；节点需要这项能力，以便将客户工作负载供应到其他节点。同时，该机器能够访问连接环境变量数据库的内部 VPC。

至此，攻击者完成了第二次关键跃迁：从 CI/CD 身份配置问题，进入内部网络和高权限编排节点，再取得接触加密变量及其解密能力的条件。

05 第四阶段：信封加密没有被“破解”，解密权限被滥用

Railway 的环境变量采用信封加密：

1. 每个环境使用独立的数据加密密钥（DEK）加密变量
2. DEK 再由密钥管理服务中的根密钥加密
3. 根密钥由上游云平台管理，不能离开密钥管理服务

这种设计可以避免单一环境密钥失陷直接暴露整个平台。但在此次事件中，攻击者不是破解加密算法，也不是导出根密钥，而是同时取得了两项能力：读取加密信封，以及使用受信的长期凭据调用密钥管理服务完成部分解密。

10 月 21 日 04:07—05:21，攻击者连接数据库并读取加密信封。数据库日志显示，其查询使用攻击者提供的正则表达式筛选变量名，优先寻找 AI 服务厂商密钥，并重点针对变量数量较多的客户。

04:42，攻击者开始使用编排节点上的长期凭据，通过密钥管理服务解密部分已取得的变量。07:14，Railway 禁用所有活动云凭据、撤销全部静态凭据，并完全关闭密钥解密服务访问；07:22，再次暂停所有客户构建。

因此，更准确的描述是：信封加密仍然界定了数据保护边界，但合法解密路径被失陷凭据滥用。仅保护密文并不足够，谁能在什么网络位置、针对哪些环境调用解密，同样必须受到严格约束和审计。

06 攻击目标与下游滥用：AI 凭据成为直接变现资源

Railway 根据攻击者的数据库查询内容判断，AI 服务厂商凭据是此次行动的主要目标。另一项查询还匹配到云服务、数据库和支付服务凭据，但取证未显示客户数据库被访问。

10 月 21 日 09:25 起，Railway 联系 GitHub、GitLab、Anthropic、OpenAI、OpenRouter、SpaceXSI、Google 和 Stripe，请求撤销可能失陷的密钥。由于当时尚无法确定具体暴露范围，Railway 提供了所持密钥的哈希值，以协助厂商迅速定位并缩小影响范围；部分厂商还自行扩大了撤销范围。

客户事后提供的源 IP、未经授权请求样本和其他指标，帮助 Railway 观察被盗密钥在外部的使用方式。已见负载包括：

• coding agent 请求
• 将 AI agent 行为审查用作训练数据
• 检查训练任务及其评分系统

Railway 认为，这些凭据可能被交给分布式中转站，用于模型蒸馏；相关工作负载也与凭据经由中转或转售服务分发的情形一致。但 Railway 尚未确认最初入侵者是否亲自运营这些服务，或只是将凭据提供给其他方。对入侵者、密钥滥用者和转售服务运营者，不能未经证据直接画等号。

Wiz 将 2026 年 10 月多家 AI 开发者平台的安全事件概括为“Black October”。Wiz 指出，这些事件之间没有单一共同漏洞或依赖，入口也各不相同；其公开报告的共同点，是攻击者明确搜寻存储的环境变量，尤其是能够访问 AI 服务的凭据。Wiz 的研究可用于理解密钥检查、转售和大规模调用等下游模式，但不构成对 Railway 事件的独立归因。

07 关键时间线：从首次探测到全面恢复

时间线中的空白并不代表攻击者或防御方没有活动。Railway 表示，双方都在并行探测、修复和加固，这不是一次“发现单点漏洞—完成单次修复”的线性处置。

08 处置与恢复：Railway 做了哪些关键动作

1. 撤销凭据并重建信任体系

Railway 轮换了工具和基础设施中的凭据，重建 PKI 并设置新的根 CA。内部工具从经过验证的源码重建；凡怀疑被攻击者接触的机器、服务和账号，均从头重新供应，旧机器关闭并保留快照用于取证。

由于 CI 环境本身是攻击路径之一，部分轮换工作在 CI 禁用的情况下手动完成，并逐项重启依赖服务。

2. 加速切换到新一代构建基础设施

Railway 在事件前已经测试新的构建架构。新架构在原有隔离机制之上，为每次构建提供独立的临时虚拟机，攻击者若要突破，需要穿过两层隔离。

新系统还将控制面与计算进一步分离，使用独立的存储和缓存后端。每次构建使用的凭据，只能向 Railway 管理的镜像仓库推送特定的 OCI 镜像，旧架构中被利用的共享系统不再使用。

由于原构建问题修复后，内部加固团队又通过修改原始攻击向量构造出额外利用方式，且无法确保攻击者全部账号均已被清理，Railway 决定提前向全部用户切换新架构。这也带来了短期容量压力：大量客户同时轮换凭据并重新部署，构建需求一度接近正常水平的两个数量级。

3. 收紧内部访问与解密权限

Railway 披露的主要加固措施包括：

• 审核所有服务账号，确保权限仅满足工作负载所需
• 尽可能改用按需签发、范围狭窄的短期凭据
• 完全退役废弃系统，减少残留攻击面
• 重建 CI，敏感组件实施细粒度隔离，关键区域加入 2FA 审批和生物识别，并加强全生命周期日志与告警
• 集中记录所有加密、解密操作审计日志
• 仅允许 secrets service 获取可解包 DEK 的密钥
• 限制每个调用服务只能解密其职责范围内的凭据

4. 构建暂停不等于全部业务停摆

既有部署在构建暂停期间总体上继续运行，用户应用并未因“停止新构建”这一动作本身而全面下线。但部分运行服务因凭据被撤销而停止工作，需要部署新凭据；在构建和重新部署不可用时，部分客户因此遭遇实际业务中断。

这也是本次恢复过程中的现实矛盾：平台需要尽快撤销可能失陷的凭据，同时又必须确保构建系统足够安全，才能允许客户部署替换凭据。

09 给平台方与使用方的防护清单

对构建、CI/CD 与云平台运营方

第一，按“凭据可被哪些服务接受”审计横向信任。不应只检查凭据的名义用途，还要验证其他内部服务是否会因共享认证逻辑而将其视为可信客户端。构建、registry、工作流调度、缓存和源码快照之间应默认隔离。

第二，把构建历史和缓存快照纳入敏感数据边界。构建任务可能同时包含源码快照、只读代码仓库 token、环境变量和部署元数据。即使单项权限看似有限，组合后也可能形成完整的内部攻击知识库。

第三，持续校验 OIDC 联邦绑定。重点检查主体、仓库、分支、环境、工作流和云角色之间的绑定是否符合预期，防止过宽或错误条件让外部身份取得生产云凭据。CI/CD 的短期凭据也不应成为读取长期内部凭据和 SSH 私钥的跳板。

第四，减少编排节点上的长期高权限秘密。对同时具有内部网络访问、工作负载供应能力和秘密解密能力的节点，应重点评估凭据落盘、权限组合及单点失陷影响。

第五，将解密行为本身作为高风险遥测。除记录密钥使用外，还应关注异常调用主体、非常规网络位置、批量环境遍历、按变量名正则筛选，以及数据库读取与 KMS 解密在时间上的关联。

第六，源码泄露后应调整攻击面假设。撤销初始凭据并不意味着攻击者失去全部优势。对历史端点、废弃接口和内部部署逻辑的异常探测，应结合“攻击者可能已读过源码”的情境进行研判。

对使用 Railway 或同类平台的团队

1. 在凭据签发方完成吊销与轮换。 仅在平台中删除或替换变量，不等于旧密钥已在 AI、云或代码仓库厂商侧失效。
2. 优先处理高价值凭据。 包括 AI API Key、云访问密钥、数据库密码、支付密钥、私有 registry 凭据、GitHub OAuth token 和 agent BYOK key。
3. 核查异常调用与费用。 重点检查陌生网络来源、调用量突增、跨区域模型调用、模型与配额枚举，以及非工作时段的持续请求。
4. 完成新凭据部署验证。 确保运行服务已经加载新值，避免只更新平台变量却未重新部署，造成业务继续使用旧凭据或出现中断。
5. 缩小单钥影响范围。 按项目、环境和用途拆分密钥，设置最小权限、用量告警和预算限制，避免一个平台变量失陷影响全部业务。

10 结语

Railway 事件的攻击链并不依赖某一项“万能漏洞”。攻击者先取得局部文件读取能力，再利用凭据被跨系统信任的问题获取构建历史和内部代码；当第一条路径被封锁后，又借助代码信息找到 OIDC 配置错误，最终抵达保存环境变量的数据库与解密服务。

对防御方而言，真正需要复盘的是整条路径：构建凭据为何能访问 Temporal，短期云凭据为何能取得长期内部秘密，编排节点为何同时具备网络、凭据和解密条件，以及异常数据读取与密钥使用为何没有更早形成联合告警。

AI 凭据泄露的风险也不会止于平台边界。旧密钥只要仍然有效，就可能在外部被持续检查、调用或转售。及时吊销、最小授权、用量监测和密钥分域，仍是降低此类事件实际损失的直接手段。

11 技术附录

附录 A：MITRE ATT&CK 技术映射

以下映射依据公开披露的行为进行归类，并非 Railway 官方提供的映射。对未披露的恶意软件、命令与控制、数据外传通道及具体漏洞实现，不作补充推测。

未强行映射的环节：Railway 提到攻击者使用去除安全限制的模型及类似 ARTEX 的 harness，但公开信息不足以据此确定具体恶意软件、自动化框架的 ATT&CK 软件条目或独立攻击技术；同样，Railway 未说明具体 C2 和外传协议，因此不添加对应技术编号。

附录 B：失陷指标与检测线索

B.1 Railway 官方 IOC 状态

Railway 在 2026 年 11 月 10 日的报告中表示，因执法调查安排，当前 IOC 先进行私下共享，待获得许可后再公开。因此，目前没有在该份 Railway 报告中公布可直接用于匹配其入侵来源的 IP、域名或文件哈希清单。

B.2 Wiz 公布的下游密钥滥用相关 IP

以下指标来自 Wiz 的“Black October”研究，涉及被盗密钥测试、使用及疑似转售活动。Wiz 明确表示，没有证据将这些 IP 直接关联到其文章所列的“Black October”入侵。它们不是 Railway 官方入侵 IOC，不能仅凭命中就认定某组织遭遇了 Railway 同源攻击。

使用这些指标时，应结合时间范围、云审计日志、AI 服务调用记录和网络上下文复核，不宜脱离时间窗口进行长期无差别封禁。

B.3 更值得落地到检测规则的行为线索

Wiz 对被盗企业 AI 凭据的下游观察显示，滥用可能呈现以下顺序：

1. 有效性测试： 先出现单次或少量模型调用，验证密钥是否可用。
2. 低频保活检查： 随后以较低频率持续验证密钥状态。
3. 能力与配额枚举： 查询可用模型、跨区域推理配置以及服务配额。
4. 突发高并发调用： 在确认可用模型和网络路径后，短时间产生大量请求。
5. 来源异常： 请求来自住宅代理、共享 VPN、轮换代理池或托管机房，与历史使用网络明显不同。
6. 费用与限流异常： 同时出现调用量激增、异常支出或大量 throttling。

可将上述行为与自身基线结合，重点关联云审计日志、模型调用日志、网络出口、身份主体和账单告警。行为线索用于发现异常，不用于对攻击者身份作单独归因。

参考链接

1. Railway：《Incident Report: October 21st Security Attack》，2026 年 11 月 10 日
https://blog.railway.com/p/incident-report-october-security-incident

2. Railway：《Preliminary Report: Oct 21st Security Incident》，2026 年 10 月 26 日更新
https://blog.railway.com/p/preliminary-report-october-security-incident

3. Wiz：《“Black October” for AI Developer Platforms》，2026 年 10 月 30 日发布，后续持续更新
https://www.wiz.io/blog/black-october-for-ai-developer-platforms

4. MITRE ATT&CK：Enterprise Techniques
https://attack.mitre.org/techniques/enterprise/

阅读原文

跳转微信打开