2026-11-01 01:35:24 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

梅开二度！LiteLLM再遭投毒！！！

零日手记
零日手记

随笔漫记安全路

2026年10月27日 08:53
北京

去阅读

10月21日，GitHub 30k+星、PyPI周下载2300万的AI网关LiteLLM被投毒——v1.107.0的全部7个wheel（Linux/macOS/Windows）都带上了凭证窃取器和远程后门，连Docker官方镜像也中招。

这不是LiteLLM第一次出事：今年3月它就遭遇过一次PyPI供应链攻击，波及2488个组织。同一个项目，一年两次。

顺带说一句：上周安全圈很热闹，PHP核心爆了php2shell未认证RCE、GitLab出了满分正则编译漏洞——大家都盯着这几个漏洞补，投毒事件就在同一时间窗口里发生了。漏洞有补丁可打，供应链投毒防的是\"你主动拉下来的东西\"，后者更容易被忽略。

更讽刺的是：LiteLLM是AI应用的\"总闸门\"——所有LLM的API Key都汇聚在它这里。偷它等于偷走一家公司全部的AI资产钥匙。

先说结论：中了怎么自查

只要装过1.107.0且Python进程启动过，按\"凭证已泄露\"处理。

这次攻击有多精准：三条 Payload 链

Payload 1：cook.py——无处不在的凭证窃取器

投毒者往wheel里塞了一个cook.pth，内容只有一行import cook。Python的.pth文件机制会让这台机器上每一个Python进程启动时都执行它——你的应用、pip、IDE的语言服务器，全部跑一遍窃取逻辑。

窃取范围堪称\"开发者机器全扫描\"：

云凭证：~/.aws/credentials、Azure/GCP token、~/.kube/config、~/.docker/config.json、rclone配置
CI/CD机密：GitLab runner配置、Jenkins初始密码、Ansible vault-token、Terraform凭证
AI开发工具token：Claude Code、Claude Desktop、Cursor、Windsurf、Copilot、Gemini CLI、Codex、Aider、Zed、Hugging Face——主流AI编程工具一网打尽
LiteLLM自己的数据库：直接dump LiteLLM_CredentialsTable表，里面是所有LLM提供商的API Key
浏览器：Chromium保存的密码（用DPAPI主密钥解密）、浏览器历史
还会翻/proc/<pid>/environ偷其他进程的环境变量，连云主机的IMDS元数据服务（拿AWS临时角色凭证）都试一遍

数据用AES-256加密+RSA-OAEP封装公钥，打包成tar.gz POST到 www.litellm[.]dev/healthcheck——C2域名伪装成LiteLLM的官方健康检查。传完写标记文件，每台主机只传一次，不重复触发告警。

Payload 2：sitecustomize.py——每小时拉取一次的远程后门

Python启动时自动import sitecustomize，这个文件启动一个守护进程，每小时：

从 raw.githubusercontent.com/letters9813/pythonclient-test/main/domain.txt 读C2地址
再跑一遍窃取器（这个副本没有\"只传一次\"标记）
下载 http://<C2>/codepy并直接执行——攻击者改一下GitHub上的domain.txt，所有感染主机就换新服务器跑新代码

也就是说：即使你当天发现异常断网，只要守护进程在你断网前跑过一轮，二阶段载荷可能已经落了地。

发布链路：偷来的合法权限+影子仓库

这是本次事件最值得复盘的部分——投毒走的是官方发布通道：

攻击者持有LiteLLM 三名开发者的GitHub CLI凭证。LiteLLM官方报告认为：这些token来自一个暴露在公网的内部LiteLLM部署的日志
攻击者拿到组织owner权限后绕过分支保护，把私有release workflow指向一个影子仓库 Berri-AI/litellm——与官方 BerriAI/litellm 只差一个连字符
用第二名开发者的凭证通过了人工审批门
官方构建流水线完成构建、签名、发布——产物是\"官方签名\"的恶意包

时间的详细对账（UTC，10月21日）：

Socket的AI扫描器在发布后7分钟就标记了全部七个wheel——从技术 detection 上其实很快，但1小时43分的窗口足够23M周下载量级的包被大量拉取（liteLLM官方2026年3月那次攻击中，\"不锁版本拉最新\"的部署是重灾区，这次同样）。

给AI团队的应急清单

如果你或你的团队用过LiteLLM：

立即锁版本：litellm==1.106.2（或最新的1.108.x+），绝不裸写litellm
全量轮换凭证——按这个优先级：云厂商密钥（AWS/Azure/GCP）→ LiteLLM proxy数据库里的LLM API Key → CI/CD凭证（Jenkins/Ansible vault/GitLab）→ AI编程工具token（Claude Code/Cursor等）→ 浏览器保存的密码（改密+开启二次验证）
排查横向移动：守护进程可能已执行过二阶段代码——查异常外联、新增的systemd/cron项、~/.ssh/authorized_keys变更
CI runner 和 LiteLLM proxy 容器重点查——这两个地方是窃取器的主食
自建LiteLLM网关的团队：这次的入口就是你暴露的内部部署日志。内网服务绝不能裸奔公网，日志里的token要当密码管理

给所有Python项目的三道防线（老生常谈但这次全是血的教训）：

锁版本+hash校验：pip install --require-hashes，CI里禁用\"always latest\"
依赖冷却期：新版本发布后等24-48小时再升级——等安全社区先趟雷
发布通道最小权限：release workflow的审批人、组织owner、CI凭证三者绝不复用；sitecustomize/.pth这类\"Python启动即执行\"的机制要纳入供应链审计清单

结语

一年两次供应链攻击，攻击手法从\"直接投毒\"进化到\"偷开发者凭证+影子仓库+官方通道发布\"。LiteLLM官方报告的归因也很直白：入口是他们自己暴露在公网的内部部署。

AI基础设施项目正在成为供应链攻击的头号目标——因为它们天然汇聚了所有LLM的API Key、云凭证和开发者token，一台机器失守等于整个AI资产库失守。

你的依赖清单里，还有多少个\"23M周下载\"级别的组件？