Railway与LiteLLM接连失守 开发者的Key怎么办

作者：Biteye 核心贡献者 Alan 来源：Biteye

短短一天里，AI 开发者圈连着炸了两个雷。

10 月 21 日，云部署平台 Railway 发了紧急公告：存客户环境变量的系统遭到了未授权访问，一部分敏感数据可能已经泄露。

几乎同一时间，很多人常用的开源工具 LiteLLM 也确认遭遇供应链投毒。攻击者往 1.107.0 版本里塞了恶意程序，不仅能偷走 API Key、云服务凭证和 SSH 私钥，还留了个远程执行代码的后门。

一个是平时托管应用的地方，一个是调大模型最顺手的工具。我们每天写代码都在用的基础设施，成了别人手摸走密钥的入口。

你手里的 API Key，现在还安全吗？

一、Railway 出事：放进环境变量的 Key 也不保险了

做独立开发或者写 AI 小工具的人，对 Railway 应该不陌生。写好网站、Bot 或者后端服务，代码往上一推，服务器运行、数据库连接全由平台托管，图的就是省事，不用自己去折腾复杂的运维配置。

但只要跑 AI 应用，就绕不开一堆密钥。调模型要用 OPENAI_API_KEY，连数据库要填密码，接第三方服务还得配各种 Token。按常规的安全习惯，大家不会把这些东西硬编码在代码里，而是放进 Railway 的「环境变量」里托管。

这次出事的，偏偏就是管环境变量的这套系统。

10 月 21 日，Railway 在安全公告里承认，后台检测到了针对客户环境变量存储系统的异常活动。初步调查显示，未授权的第三方可能接触到了加密的环境变量，并拿到了其中一部分数据的明文。

换句话说，你存在 Railway 上的 OpenAI、Anthropic、OpenRouter 密钥，连同数据库密码、云平台凭证，都有可能已经裸奔了。

出事之后，Railway 一度停掉了全平台的构建和部署，提醒所有用户赶紧轮换存在平台上的密钥，并去查查相关服务的调用记录。截至 10 月 22 日上午，官方还没公布具体波及了多少用户，调查还在继续。社区里已经有人发帖说自己的 Key 被盗刷，不过目前还只是零星的个人说法，暂时没法当成确凿的定论。

但看 Railway 官方给出的建议，事情的严重程度已经不需要多解释了：哪怕后台看着一切正常，也得把可能暴露的旧密钥全部作废，重新生成。

这里有个新手很容易踩的坑：只去 Railway 后台把环境变量删掉，是没用的。Key 一旦流出去，只要没在源头注销就依然能调通。你必须去 OpenAI、OpenRouter 这些服务商自己的后台，把旧 Key 彻底撤销（Revoke），才算真正掐断风险。

二、LiteLLM 投毒：连 import 都不用，装上就中招

Railway 这边是托管平台被摸了底，LiteLLM 那边的情况则更让人后背发凉：你正经敲命令装下来的软件包，本身就已经带毒了。

平时写 AI Agent、需要同时接好几家模型的人，大多用过 LiteLLM。它把 OpenAI、Claude、Gemini、DeepSeek 等各家的接口包了一层，一套代码就能来回切换，省去了挨个对齐接口格式的麻烦。但也正因为干的是这个活，你配的各家大模型 API Key，它全都摸得着。

10 月 21 日，LiteLLM 官方确认发布流程被入侵，攻击者往 PyPI 和 Docker 镜像仓库推了带毒的 1.107.0 版本。中招的范围包括 PyPI 上的 7 个 Wheel 包，以及 Docker 的 v1.107.0 镜像和当时那段时间的几个浮动标签。

这次投毒最阴险的地方，在于它的触发方式。按常理，装了一个 Python 包，总得在代码里 import 并调用它，里面的逻辑才会跑起来。但攻击者这次卡了 Python 启动时自动处理特定文件的机制，把恶意逻辑藏在了启动加载环节。

结果就是，在装了毒包的 Python 环境里，哪怕你一行 LiteLLM 的代码都没调，只要启动 Python，恶意代码就可能直接跑起来。

根据安全研究人员拆解的结果，这段程序会顺手搜刮机器上的不少东西：

• OpenAI、Anthropic 等各家 AI 服务的 API Key

• AWS、GCP、Azure 等云服务凭证

• 本机的 SSH 私钥和开发者认证文件

• 环境变量，以及部分浏览器保存的凭证和 Cookie

除此之外，包里还埋了一个远程代码加载器，攻击者随时可以往已经中招的机器里继续下发新指令。

而且这次不是那种外部仿冒包名的低级钓鱼。LiteLLM 官方顺着排查下去发现，攻击者是先拿到了开发者的 GitHub CLI 凭证，篡改了发布工作流，让正规的发布流水线转头去一个高仿仓库拉代码打包。

官方仓库叫 BerriAI/litellm，攻击者建的仓库叫 Berri-AI/litellm。中间就多了一根短横线。

这就是供应链攻击最难防的地方：你走的是官方渠道，敲的是平时敲了无数遍的安装命令，但接进来的东西已经被人掉包了。

目前 LiteLLM 已经撤下了问题版本，之前的旧版本确认不受影响。但如果你恰好在那个时间窗口装过 1.107.0，千万别觉得敲一行卸载命令就万事大吉了。软件能卸掉，已经被传走的密钥可收不回来。

三、为什么受伤的总是 AI 开发者？

把这两件事放一起看，出事的环节完全不同：一个是云平台失守，一个是开源供应链被篡改。但攻击者冲着去拿的东西是一样的，都是开发者手里的各种 Key。

早几年写个普通网站，兜里揣着的无非是服务器密码和数据库账号。但现在搭一个 AI 应用，一个项目里往往要同时塞进好几家大模型的 API Key，外加 GitHub、AWS、数据库、支付接口和各种自动化工具的 Token。一个本地环境或者一个容器里，顺着环境变量摸过去，几乎能掏出半个公司的家底。

更要命的是，API Key 跟平时的账号密码不是一个逻辑。拿走账号密码，往往还可能被二次验证拦一下；拿走一个有效的 API Key，连登录界面都不用见，直接发请求就能调接口。

放在大模型平台上，最直接的后果就是额度被瞬间刷爆、账单飙升；放在云服务和数据库上，就是算力被拿去挖矿、业务数据被拖库；要是有人图省事，把链上钱包的私钥也放在同一套环境里，那损失的就是真金白银了。

现在的 AI 应用接的工具越多、攒在一起的凭证越全，一旦某个环节漏风，被一锅端的范围就越大。而大家平时最容易忘在脑后的，偏偏就是那些第一次跑通项目时配好、之后再也没看过的老密钥。

四、自查清单：现在该干什么？

如果你手头在写 AI 项目，或者最近用过 Railway 和 LiteLLM，建议直接照着下面这几步过一遍。

1. 用过 Railway 的：马上换 Key

• 登录 Railway 后台，看一眼项目里配过哪些敏感环境变量。

• 直接去 OpenAI、Anthropic、OpenRouter 等服务商自己的后台，把旧 Key 撤销（Revoke），重新生成新的。记住，只删 Railway 里的变量没用，必须在发卡方后台作废。

• 顺手把数据库密码、云服务凭证和其他第三方 Token 一并换掉。

• 把账单上限锁死。在大模型后台设好每月硬性消费限额（Hard Limit）和预算告警，就算 Key 真漏了，最多也就亏掉设定的那点额度，不至于一觉醒来背上天价账单。

• 一个项目一套 Key。别拿同一把 Key 走天下，项目之间做好隔离，哪个出事掐哪个，不会牵连其他线上业务。

• 锁死生产环境的依赖版本。别在部署脚本里不带版本号直接拉最新版（latest），给第三方包留一点社区验证的缓冲期。

• 控制权限颗粒度。只给应用开通它必须用到的最小权限，高权限的云账号密钥、钱包私钥，绝不跟普通业务代码混放。

2. 装过 LiteLLM 1.107.0 的：按这个顺序处理

先在安全干净的环境里查一下依赖记录或锁文件，看有没有装过 litellm==1.107.0，或者拉取过对应时间段的 Docker 镜像。如果确实撞上了，按下面的顺序来：

• 先把这台开发机或服务器断网隔离。

• 别直接在可能中招的 Python 环境里跑 pip uninstall 或升级，因为只要唤醒 Python，恶意脚本就可能再次触发。

• 直接从干净的系统环境重新拉起虚拟环境、容器或重装实例。

• 把这台机器能摸到的所有凭证全换一遍，包括模型 Key、云平台 Token、Git 凭证和本机 SSH 私钥。

• 退回官方确认安全的旧版本，等后续修复彻底明朗后再升级。

当然，如果你平时只是在网页或手机 App 上用用 ChatGPT、Claude，压根没碰过上面说的部署平台和开发包，那这两起事件跟你的账号安全没关系，正常用就行。

五、写在最后

回头看这两天的事，最让人感慨的一点在于：中招的开发者，其实没做错什么。

把密钥放进环境变量，是教科书级的标准操作；用 pip 装个高星开源库，也是再正常不过的日常。可一旦上游的托管平台或发包流水线失守，这些最熟练、最常规的动作，突然就成了引狼入室的通道。

Railway 和 LiteLLM 的调查结果还会陆陆续续出来，但我们手里的 Key 没必要等调查报告。

现在的 API Key，连着你的信用卡额度、业务数据库，还有整套系统的运转权限。

AI 让写代码、搭应用变得越来越省事，但管钥匙这件事，真的省不得。下次往配置框里粘贴那串 sk- 开头的字符前，不妨先多想一步：要是这个工具明天被黑了，我能不能在五分钟之内，把它碰过的所有权限全部掐断？