Railway 环境变量可能已暴露（2026年10月，最多占全部工作区 1.85% 的工作区）：哪些密钥需要轮换，用户该怎么做

公司要求你吊销并重新设置 10 月 21 日之前存储在 Railway 上的所有敏感环境变量，包括 API 密钥和私有镜像仓库凭据。

请按以下顺序操作：

• 列出你的环境变量。打开每个服务的 Variables 标签页，标记出密钥类的值（API 密钥、令牌、密码、签名密钥、连接字符串）
• 在各来源的控制台中签发新值：AI API、支付服务商、GitHub、云、外部数据库等
• 更新 Railway 变量并重新部署服务。容器只在启动时读取变量，因此在重新部署之前会继续使用旧值运行（公司指南）
• 新值验证可用后，在来源处吊销或删除旧值

只在 Railway 内修改值，而不在来源处吊销，已暴露的值仍然可用（本站说明）。

公司建议所有用户移除数据库的公网访问。其指南指出，启用了公网访问（TCP 代理）的数据库，在你轮换之前，任何人都可以从互联网上凭凭据访问。

• 对于 PostgreSQL、MySQL、Redis 和 MongoDB，请在数据库视图中使用 Regenerate。它会一次性修改数据库内的密码和相关变量，并断开已打开的会话（公司指南）
• 不要手动编辑 POSTGRES_PASSWORD 等密码变量，也不要直接在数据库中修改密码。否则变量与数据库会不同步（公司指南）
• 重新部署所有引用这些变量的服务（例如 ${{ Postgres.DATABASE_URL }}）。将粘贴的连接字符串替换为引用
• 如果项目之外没有需要访问的对象，请在 Settings、Networking 下关闭 Public Access。项目之外的访问（本地开发、CI、BI 工具）需要手动粘贴新的 DATABASE_PUBLIC_URL

公司建议检查 GitHub 审计日志和应用访问权限，以及 Docker Hub 等镜像仓库的审计日志。其指南列出了以下检查项：

• 个人账户：GitHub 安全日志（90 天）、已授权的 OAuth 应用和 GitHub Apps、SSH 和 GPG 密钥以及个人访问令牌。撤销所有你不认识的项目，并重新生成令牌
• 组织：组织审计日志（180 天）。在吊销任何内容之前先导出日志。对每个仓库，检查部署密钥、密钥（secrets）、webhook 和协作者
• GitHub Container Registry（ghcr.io）：Railway 已删除其存储的 GitHub 令牌，但这些令牌在 GitHub 上吊销之前仍然有效。请在 GitHub 上删除旧令牌，创建一个具有 read:packages 权限范围的新令牌，并在每个服务中设置

指南还警告说，拥有推送权限的攻击者可以添加在密码重置后仍然存在的 webhook 或密钥。

根据公司的初步报告，攻击者似乎在寻找 AI 服务商的 API 密钥。公司已发布针对 OpenAI、Anthropic、OpenRouter、Grok、Stripe、AWS 和 GCP 的用量检查指南。例如，OpenAI 指南建议：

• 删除可能已暴露的密钥，并在同一项目中创建新密钥
• 打开用量页面，按 API 密钥分组，将暴露窗口期内的 token 量、请求数和模型组合与你的正常流量进行比较
• 检查该期间的计费支出和已消耗的赠送额度
• 检查成员和项目成员中是否有你没有邀请的人
• 保留用量详情，如发现被滥用，请联系服务商的支持团队

至少应检查从攻击窗口开始（10 月 20 日 13:58 UTC）到你轮换密钥为止的时间段（本站说明）。

在应对过程中，公司吊销了所有登录会话、Railway 访问令牌、GitHub 连接和存储桶凭据。部署暂停期间推送的提交没有被部署。

• 使用注册时所用的同一个 Gmail、GitHub 账户或邮箱登录。使用其他身份登录会创建一个新的空账户（公司指南）
• 在账户设置中重新连接 GitHub，在服务的 Settings 中重新连接仓库，并部署最新提交
• CLI：运行 railway logout，然后运行 railway login。CI：重新创建项目令牌（RAILWAY_TOKEN）或账户/工作区令牌（RAILWAY_API_TOKEN），并在 CI 密钥中替换
• 重新部署使用存储桶的服务，使其获取新凭据。同时检查存储桶中是否有你没有上传的文件或你没有进行的删除（公司称存储桶没有自动备份）
• 在工作区审计日志中，查找暴露窗口期内并非由你的团队或 Railway（显示为 "Railway Staff"）进行的变量读取、镜像仓库凭据更改和部署

Railway 的环境变量是加密的，但根据初步报告，攻击者利用多个已泄露凭据的组合解密了其中一部分。托管平台为了运行你的应用，必须把变量还原为明文，因此一旦平台内部的权限被夺取，仅靠加密无法完全保护它们（本站说明）。

除平台加密之外，还应以泄露后损失有限的方式存放密钥。第一步，请在 AI API 和支付服务商处设置支出上限和提醒。将生产、预发布和开发环境的密钥分开，也能缩小需要轮换的范围。关于密钥的存放，请参阅 .env 和 API 密钥究竟危险在哪里。

根据公司的指南，启用了公网访问的数据库，在连接字符串泄露后，任何人都可以从互联网上访问。只通过项目私有网络使用的数据库，即使连接字符串泄露，也无法从外部直接访问。

通常只有本地开发、CI 或 BI 工具才需要外部访问。即便如此，也可以考虑仅在需要时开放，或使用单独的只读用户（本站说明）。

公司的指南建议通过 ${{ Postgres.DATABASE_URL }} 这样的引用变量来共享连接字符串和密钥，而不是把它们粘贴到每个服务中。使用引用后，修改来源值并重新部署就会覆盖所有服务，不会遗漏任何粘贴的副本。

出于同样的思路，请持续维护一份清单，记录每个服务使用哪些密钥以及在哪里重新签发（本站说明）。像现在这样需要轮换全部密钥时，这份清单决定了工作要花多长时间。在类似的案例 Vercel 安全事件中，关键在于密钥是否存放在之后无法显示其值的类别中。

在本次事件中，公司吊销了其持有的 GitHub 令牌，并建议检查 GitHub 审计日志和应用访问权限。请将授予托管平台的 GitHub 访问权限限制在其所部署的仓库，并只给容器镜像仓库令牌读取权限（read:packages），这样泄露时波及的范围更小（本站说明）。关于泄露后仍然有效的凭据问题，请参阅仍然有效的泄露凭据。