10个恶意提交，把LiteLLM的API密钥送进了攻击者服务器

10月21日，一个恶意版本的LiteLLM被上传到了PyPI。版本号是1.107.0，上传时间是当天11:39 UTC，到1:20 UTC被PyPI隔离。最近的安全版本是v1.106.2。

问题不止在PyPI。GHCR和Docker Hub上的LiteLLM容器镜像也包含了被植入木马的版本，涉及v1.107.0、latest、main-latest和main-stable这几个标签，这些镜像在约13:53 UTC被移除。

恶意包安装后，会把三个文件直接释放到site-packages根目录：cook.pth、cook.py和sitecustomize.py。这三个文件的设计目标是：只要Python解释器启动，它们就会被执行。

启动时，解释器先处理cook.pth，其中包含一条导入cook的命令，进而加载cook.py。cook.py会自我解混淆，运行窃取程序，并向/tmp/.pc_once_72129118c59f5636c0bb写入一个标记文件——这一步在Windows上会失败，因为该路径通常不存在。

窃取程序收集系统、浏览器、开发者、云和AI工具的密钥，加密后通过POST请求外传到www.litellm.dev/healthcheck。这个域名由攻击者控制，伪装成LiteLLM的基础设施。

sitecustomize.py只在Linux和macOS上运行。它会尝试从一个GitHub死信箱（letters9813/pythonclient-test/main/domain.txt）获取domain.txt，如果拿到响应，就从http:///codepy下载第二阶段Python脚本并执行。分析期间，domain.txt从未被填充过，该仓库在13:30 UTC已被下架。

内嵌的凭据窃取模块内部名为privcollect，横跨16个模块收集敏感数据：

• Chrome、Firefox、Edge、Safari的浏览器凭据与Cookie
• ~/.aws/下的AWS凭据、环境变量，以及EC2/ECS实例元数据（IMDS）
• GCP服务账号密钥与应用默认凭据
• Azure CLI缓存中的令牌
• 环境变量或配置文件中存放的OpenAI、Anthropic、Cohere等LLM厂商API密钥
• SSH私钥、GPG密钥和shell历史文件

LiteLLM Proxy把上游API密钥存在PostgreSQL数据库里。窃取程序直接查询这个库，执行SELECT * FROM "LiteLLM_CredentialsTable" LIMIT 500，把配置过的所有厂商凭据取走。

收集到的数据用AES-256-CBC加密，密钥以RSA-4096封装，再通过HTTP外传，请求头里带着硬编码的X-Token和一个Internet Explorer 7的User-Agent字符串。

载荷来自github.com/Berri-AI/litellm上的恶意提交。注意这个带连字符的写法，它和合法的BerriAI组织不是同一个。这个仓库在GitHub上不可见，被用来把载荷注入发布流水线。

10月21日08:56到10:46 UTC之间，攻击者用邮箱ckdi82fkoos@proton.me推送了10个提交。前九个在GitHub.com上创建，因此带有GitHub的已验证签名。

前三个提交在两分钟内完成，加入了持久化文件cook.pth、cook.py和sitecustomize.py。随后四个提交把版本号推到1.107.0。间隔39分钟后，两个提交细化了载荷，并向pyproject.toml加入关键指令data = "cook"，让构建工具把恶意代码打进wheel包。

最后一个提交在58分钟后完成，用的是另一个邮箱（Berri-AI@users.noreply.github.com），且没有签名，暗示来自不同环境。它向Dockerfile加入了COPY cook ./cook。

Berri-AI仓库虽然已不可用，但由于Git的fork对象共享机制，所有提交仍可通过父仓库访问。完整diff在github.com/BerriAI/litellm/compare/a8113b0d...20535d8f。

对使用LiteLLM的团队来说，眼下最直接的动作是核对版本：确认没有装过1.107.0，容器镜像没有拉过上述四个标签，并检查环境变量和配置文件中存放的各家API密钥是否需要轮换。