一个被下架得很快、影响面很广的版本
10 月 22 日，安全社区确认广泛使用的 LLM 网关 LiteLLM 在 PyPI 发布的 1.107.0 版本携带凭据窃取后门。LiteLLM 是大量团队用来把多家模型接进应用的统一网关，一旦被污染，下游的调用方可能在毫无察觉的情况下把密钥交出去。PyPI 在数小时内下架了问题版本，维护者 Krrish 随后发布了事件复盘，但这段窗口已经足够让部分环境装上有毒的包。
值得注意的细节是，这次并非代码库本身被攻破：攻击方用的是窃得的开发者 GitHub 凭据，绕过分支保护后把恶意文件塞进 wheel 构建流程，公开仓库的源码里看不到异常。也就是说，肉眼 review 源码的人发现不了，真正带毒的是发布产物。这类「源码干净、制品有毒」的投毒，比直接改源码更难被社区及时抓到。
后门偷什么：从 SSH 到 LLM 密钥
被窃取的目标覆盖了一支工程团队最敏感的那一类凭据：SSH 私钥、云厂商凭据、CI/CD 流水线密钥、浏览器保存的密码，以及各家 LLM 提供方的 API 密钥。对把 LiteLLM 当作统一入口的团队而言，最后这一类尤其致命——网关本就握着通往多家模型的密钥，后门等于把整张密钥表一次性外传。
多名开发者同时失陷，被解读为某个内部部署环境暴露所致，而不是三路人各自中招。这恰恰指向一个结构性隐患：当构建与发布依赖少数几个人的凭据，且内部环境防护不足时，单点失守就会污染对外发布的制品。
为什么 LLM 网关成了高价值目标
LiteLLM 这类网关处在模型的「前方」：它集中持有路由配置、各家模型的密钥与调用日志，是比单个应用更肥的攻击面。拿下网关，攻击者拿到的不是某一个密钥，而是一整支团队的密钥全景。过去一年围绕 AI 工具链的供应链攻击明显增多，从 RubyGems 上的智能体依赖到各类 SDK，逻辑一致：攻击者不再硬碰模型，而是去污染模型被集成进生产的方式。
对使用 LiteLLM 的团队，当务之急是核对 1.107.0 是否被装过、对应环境的密钥是否应作废并重发，并把依赖锁到已确认干净的版本。更长期的动作是把构建与发布从个人凭据里解耦，改用短时效、带审计的发布凭据，并对接入网关的密钥做隔离与轮换。
与既有漏洞区分：这是投毒，不是代码缺陷
需要把这次事件和 LiteLLM 此前被点名的 CVE（如 API 密钥集中类问题）区分开：那些是代码层面的缺陷，可通过升级修复；这次是发布制品被人主动植入后门，属于供应链投毒。两者性质不同，处置也不同——前者改代码，后者要追发布链路与凭据管理。
这也是为什么「一年来第二起重大安全事件」这个说法值得重视：连续出事说明问题不在某一次疏忽，而在发布与凭据的薄弱处。对把开源组件接进关键链路的团队，重复出事的组件理应进入更高的审查层级，而不是等下一次爆雷再救火。
冷静看：下架快，但窗口已经存在
PyPI 数小时下架、维护者快速复盘，响应速度算快；但「数小时」对自动化部署环境已经足够——CI 流水线可能在这段时间里拉到有毒版本并完成构建。真正要紧的是，凡是这段窗口内装过 1.107.0 的环境，都应默认密钥已暴露，按泄露处理，而不是等官方确认影响范围。
对开源供应链更宏观的启示是：源码可审计不等于制品可信。当发布环节依赖少数人凭据、且内部环境防护不足，社区 review 源码的安全感会成为一种错觉。把发布凭据短时效化、把制品做签名与来源校验，才是把「源码干净」变成「装到手里的也干净」的实在一步。