Railway：你的 .env 搭上了别人的车

Railway 是一个很流行的 PaaS 平台。最初通知称在 2026年10月21日上午，存放客户环境变量的系统中出现了异常活动。通知还称，未经授权的一方可能访问了加密后的变量，而且其中一部分的解密内容也被拿到了。在 Railway 上，应用的 API 密钥、数据库密码和镜像仓库凭据都放在环境变量里，所以这实际上就是一个密钥库。

Railway 认为这次入侵属于最近一系列针对平台公司的攻击，攻击者的最终目标是 AI 推理服务商。Railway 说已经请这些上游服务商主动吊销密钥。最初通知未点名，初步报告现已列出 GitHub、GitLab、Anthropic、OpenAI、OpenRouter、SpaceXSI 和 Stripe 等收到通知的服务商。用量检查指南也覆盖 Grok。

Railway 在自己这边做了什么

• 在处置期间暂停新构建和部署，也包括更早的 10月20日中断。Enterprise 的构建在 10月22日 03:30 UTC 左右恢复，其他套餐随后分批恢复。
• 让 OAuth 会话失效（用户会被登出）。
• 重置了每个存储桶的 S3 凭据，以及 Railway 为账号关联持有的 GitHub 令牌，并删除了作为镜像仓库凭据存储的 GitHub 令牌。这些重置操作会以“Railway Staff”的名义出现在工作区审计日志里。
• 请上游服务商吊销密钥；最初通知未点名，初步报告现已列出其中多家。

你的第三方密钥，Railway 没法替你轮换：变量里的 Stripe 密钥、OpenAI 密钥和数据库密码，都得你自己换。而且容器只在启动时读取变量，所以换完密钥必须重新部署，可构建暂停期间偏偏部署不了。

为什么是 L4

Railway 说影响“可能仅限于部分用户”，却要求所有用户都去轮换。它确认至少有一部分客户的密钥被拿到了解密后的值。大型 PaaS 的多租户密钥库被攻破，就是一次大规模凭据泄露，而每一把泄露的密钥都能打开下游的另一个系统。所以定为 L4。如果确认被盗密钥遭到大规模滥用，级别还会上调。

还不清楚的地方

• 最初入口及具体漏洞细节仍未公开。初步报告说明了提权和 CI 凭据失陷，并补充了此前缺失的时间线。
• 具体哪些变量被解密仍未知，工作区上限不能回答这一点。服务商大范围吊销凭据，不代表每个被重置的凭据都已失陷。
• Railway 称未访问单个用户账号；尚不能排除源代码访问。
• 滥用情况。 Railway 现已给出针对 AI 欺诈费用的退款申诉流程，但该指引没有公布已核实的滥用数量，也没有将每笔可疑费用都归因于本次入侵；应检查自己各服务商的日志。

10月24日更正： Railway 10月22日初步报告取代了此前范围未知的说法：最多 1.85% 工作区（约 10 万个）的部分变量可能受影响。这是上限，不是已确认受害者总数。报告将攻击窗口设为 10月20日 13:58 UTC 至 10月22日 03:32 UTC，并称现有工作负载始终在线。所有套餐已重新接受构建。10月23日指南说明了如何补发错过的部署及替换被吊销的访问凭据；项目不见时，应使用原有登录身份。

10月27日更新： Railway 在 10月26日的更新中称，现有用户的服务已全面恢复，新用户注册仍暂停。服务恢复不能替代上述凭据轮换及部署恢复步骤。若怀疑产生 AI 欺诈费用，应先联系 AI 服务商，再通过 Railway Station 提交时间戳、提示词及支持证据，请 Railway 协助升级处理。Railway 无法退还第三方 AI 费用，愿意协助处理也不保证退款。本次更新没有给出已核实的下游滥用总量，也未证实更广泛的受害者数量。