双雷引爆：Railway 与 LiteLLM 遭入侵，开发者密钥如何自救

据 Woofun AI 消息，10 月 21 日 AI 基础设施领域遭遇双重安全危机，云部署平台 环境变量系统遭未授权访问，开源工具 确认遭受供应链投毒，大量 API Key 及敏感凭证面临泄露风险。这两起事件分别击穿了应用托管层与代码依赖层，暴露出开发者在密钥管理上的系统性脆弱性。攻击者通过窃取凭证获取了对 AI 模型、云服务及数据库的直接控制权，导致用户面临额度刷爆、数据拖库甚至资金损失的多重威胁。此次危机不仅关乎单一平台的安危，更揭示了现代 AI 开发环境中权限集中化带来的巨大隐患，迫使开发者重新审视从密钥生成到撤销的全生命周期管理策略。

Railway 作为广受独立开发者青睐的云部署平台，其核心价值在于简化运维流程，允许用户将代码推送后由平台托管服务器运行与数据库连接。然而，这种便利性建立在将敏感信息存入平台"环境变量"系统的基础之上。10 月 21 日，Railway 发布紧急安全公告，承认后台检测到针对客户环境变量存储系统的异常活动。初步调查显示，未授权的第三方可能接触到了加密的环境变量，并成功获取了其中一部分数据的明文。

这意味着存储在 Railway 上的 、、 密钥，连同数据库密码、云平台凭证等核心资产，均可能已处于裸露状态。为控制事态，Railway 一度暂停全平台的构建和部署功能，并敦促用户立即轮换密钥及核查调用记录。截至 10 月 22 日上午，官方尚未公布具体受波及的用户数量，调查工作仍在进行中，但社区内已出现零星关于 Key 被盗刷的报告，尽管这些个案尚不足以构成普遍性定论，但官方建议的严厉程度已暗示了事态的严重性：无论后台显示是否异常，所有可能暴露的旧密钥必须全部作废并重新生成。

值得注意的是，许多开发者在应对此类泄露时存在认知误区，认为仅在 Railway 后台删除环境变量即可消除风险。然而，密钥一旦流出，只要未在源头注销，攻击者仍可凭旧 Key 正常调用服务。因此，真正的止损关键在于"源头撤销"。用户必须登录 OpenAI、OpenRouter 等服务商的官方后台，执行 Revoke（撤销）操作，彻底废除旧 Key 的有效性。

这一过程强调了权限管理的最终控制权始终归属于发卡方，而非托管平台。Railway 的失守虽然切断了平台内部的访问路径，但无法阻止外部已泄露凭证的持续使用。只有通过在源头切断权限，才能有效掐断攻击者的访问链路，防止进一步的资源滥用。

这一逻辑适用于所有依赖第三方平台托管密钥的场景，提醒开发者必须建立"平台不可信"的安全假设，始终保留对核心凭证的直接控制能力。

与此同时，LiteLLM 遭遇的供应链攻击则呈现出更隐蔽且致命的特征。LiteLLM 是一款广泛用于 AI Agent 开发的开源工具，通过统一接口封装 OpenAI、Claude、Gemini、DeepSeek 等多家模型的 API，极大简化了多模型切换的开发流程。10 月 21 日，LiteLLM 官方确认其发布流程被入侵，攻击者向 和 Docker 镜像仓库推送了带有恶意程序的 1.107.0 版本。中招范围涵盖 PyPI 上的 7 个 Wheel 包，以及 Docker 的 v1.107.0 镜像和特定时间段的浮动标签。此次投毒的阴险之处在于其触发机制：攻击者利用 Python 启动时自动处理特定文件的机制，将恶意逻辑嵌入启动加载环节。

这意味着，即使在安装了毒包的 Python 环境中，用户无需显式调用 LiteLLM 代码，仅需启动 Python 解释器，恶意脚本便可能自动执行。这种设计使得攻击无需用户主动触发，极大降低了受害门槛，增加了检测难度。