别只盯着PHP和NodeJS，还有LiteLLM

原创

星宇Sec
星宇Sec

星宇Sec

2026年10月21日 23:40
山东

去阅读

想象一下你有一个用 Go + PHP + NodeJS + nginx 的网站在 Linux（内核提交c6e50df8之前）上运行，通过 HTTPS 提供服务，使用了LiteLLM和由 eMuhdra 签发的 TLS 证书......

最主要的php就不说了，一搜一大堆。nodejs的可以参考极御安全的文章

【漏洞通报】CVE-2026-111497：Node.js Brotli解压组件越界写入漏洞，可导致远程代码执行

极御安全，公众号：极御安全【漏洞通报】CVE-2026-111497：Node.js Brotli 解压组件越界写入漏洞，可导致远程代码执行

LiteLLM1.107.0供应链投毒事件安全通告

摘要

2026年10月21日，LiteLLM1.107.0在PyPI发布的7个平台wheel及同期构建的Docker镜像中被发现植入恶意启动钩子。载荷能够随Python解释器启动自动执行，收集云平台、开发者工具、浏览器及LiteLLM数据库中的凭据，并通过GitHub死信箱维持远程代码加载能力。Socket完成检测并发布分析报告，LiteLLM维护者在公开Issue中将事件定为SEV-0，随后确认PyPI版本已被隔离、恶意容器镜像已被移除[1][2]。

同日，PHP与Node.js亦发布高风险安全更新。PHP修复两个可导致未认证远程代码执行的关键漏洞，Node.js修复多项高危漏洞，其中CVE-2026-111497可由Brotli解码器越界写导致远程代码执行[4][5]。两类事件均需处置，但风险模型不同：运行时漏洞通常依赖恶意请求触发，LiteLLM事件则在依赖安装和进程启动阶段执行恶意代码。

Socket对LiteLLM1.107.0的恶意包告警

图1 LiteLLM1.107.0被Socket标记为Known malware，供应链安全评分为0。资料来源：[1]。

一、事件概述

根据Socket的分析记录，LiteLLM1.107.0的PyPI产物于2026年10月21日11:39:51UTC完成上传，Socket于11:46:40UTC检测到恶意内容[1]。受影响wheel包含以下三个额外文件：

cook.pth
cook.py
sitecustomize.py

其中cook.pth包含import cook，使cook.py在Python初始化site模块时执行。sitecustomize.py亦会在解释器启动阶段自动导入。因此，受影响环境无需在业务代码中显式执行import litellm，恶意载荷仍可能运行。

GitHubv1.107.0标签本身不包含上述文件。公开溯源显示，容器构建来源指向形似官方仓库的Berri-AI/litellm，恶意代码位于标签之后的未打标签提交中。该细节说明源码标签的完整性不能替代发布产物完整性验证[1][2]。

PHP与Node.js运行时漏洞和LiteLLM供应链风险的比较

图2 PHP、Node.js运行时漏洞与LiteLLM供应链投毒的风险模型对比。本文整理。

二、受影响范围

2.1 PyPI产物

7个受影响wheel覆盖macOS、glibc Linux、musl Linux和Windows平台：

源代码分发包sdist不包含三个载荷文件，但其pyproject.toml已被修改，加入data = \"cook\"构建配置。根据公开报告，1.106.2及1.107.0rc1、1.107.0rc2未发现相同载荷[2][3]。

2.2 容器镜像

受影响的容器标签包括：

ghcr.io/berriai/litellm:v1.107.0
ghcr.io/berriai/litellm:latest
ghcr.io/berriai/litellm:main-latest
ghcr.io/berriai/litellm:main-stable

相同问题亦涉及litellm-database、litellm-non_root及Docker Hub的litellm/litellm对应标签。维护者于14:32UTC确认恶意Docker镜像已移除[2]。

截至本文信息截止时间，PyPI与Docker Hub的1.107.0版本均返回404。已经下载至本地缓存、CI缓存或容器仓库中的历史产物不会因上游删除而自动消失，仍需在内部环境中单独排查。

三、技术分析

3.1 构建来源

容器SLSA溯源记录将源代码标识为：

github.com/Berri-AI/litellm

该仓库名称与官方github.com/BerriAI/litellm高度相似，但多出一个连字符。恶意提交依次加入启动钩子、调整版本号、修改Maturin打包配置，并在多个Dockerfile中加入COPY cook ./cook。公开报告中列出的关键提交包括：

LiteLLM恶意包从伪装仓库到凭据外传的攻击链

图3 LiteLLM恶意产物的构建、发布、安装与执行路径。本文依据[1][2][3]整理。

3.2 启动执行机制

Python在初始化site模块时处理site-packages目录中的.pth文件。cook.pth中的import cook因此会在常见Python运行环境中自动触发cook.py。同时，sitecustomize.py由Python启动流程自动导入，构成第二个执行入口。

恶意载荷在首次运行后启动后台线程，并检查标记文件：

/tmp/.pc_once_72129118c59f5636c0bb

sitecustomize.py还会创建脱离终端的后台进程，持有/tmp/remote_code_loader.lock，按固定周期从GitHub仓库letters9813/pythonclient-test读取域名配置，再从http://<domain>/codepy下载Python代码并交给exec()执行。远程内容未配置签名校验或完整性校验[1][3]。

Socket扫描器识别出的恶意启动钩子与远程加载行为

图4 Socket检测结果中的启动钩子、进程驻留和远程代码加载行为。资料来源：[1]。

3.3 凭据收集与外传

载荷内部名称为privcollect，收集范围包括：

收集结果使用AES-256-CBC加密，随机会话密钥使用RSA-4096-OAEP封装，并通过HTTP POST发送至：

http://www.litellm.dev/healthcheck

litellm.dev并非项目使用的litellm.ai。公开情报显示，该域名于2026年10月13日注册，外传请求使用固定HTTP头和不加密的传输协议[1][2]。

四、证据核验与时间线

4.1 证据核验

Socket报告将“7个wheel”和“约7分钟检出”作为检测结果记录。PyPI上传时间与恶意告警时间可以由公开截图核对，告警时间本身属于厂商遥测数据。恶意文件、提交记录、OSSF登记和维护者确认共同支持事件的真实性判断。

4.2 事件时间线

LiteLLM供应链投毒事件时间线

图5 2026年10月21日LiteLLM供应链投毒事件主要节点，时间为UTC。本文依据[1][2][3]整理。

五、影响研判

5.1 机密性影响

事件对机密性的影响等级为高。载荷覆盖云身份、代码仓库令牌、模型供应商密钥、数据库凭据、SSH私钥和AI工具登录信息。对于运行LiteLLM代理的服务器，载荷具有针对LiteLLM_CredentialsTable和LiteLLM_ProxyModelTable的专门收集逻辑，可能导致所有上游模型密钥同时泄露。

5.2 完整性与持续性影响

sitecustomize.py具备定时拉取和执行远程代码的能力。即使初次凭据窃取已经结束，攻击者仍可通过修改死信箱中的域名重新激活受感染主机。因此，受感染环境不能仅依靠删除恶意wheel判定为已清理。

5.3 暴露条件

符合以下任一条件的环境应纳入高风险排查：

1. 在2026年10月21日11:39UTC之后安装过LiteLLM1.107.0。
2. 拉取过v1.107.0、latest、main-latest或main-stable相关镜像。
3. 使用受影响提交或伪装仓库构建过LiteLLM产物。
4. CI、制品库或本地缓存中保留过1.107.0wheel或镜像层。

Socket报告LiteLLM的周下载量约为2300万。该指标描述整个项目的下载规模，不能作为恶意版本实际安装量或受影响组织数量[1]。

六、处置建议

6.1 暴露排查

应检查锁文件、SBOM、构建日志、制品仓库和容器镜像清单，确认是否出现：

litellm==1.107.0
ghcr.io/berriai/litellm:v1.107.0
ghcr.io/berriai/litellm:latest
ghcr.io/berriai/litellm:main-latest
ghcr.io/berriai/litellm:main-stable

同时检查litellm-database、litellm-non_root和docker.io/litellm/litellm的对应标签。

6.2 隔离与取证

发现可疑环境后，不应首先在该虚拟环境中运行python、pip或测试命令。.pth和sitecustomize.py可能在解释器启动时再次执行载荷。建议从宿主机或容器平台层面停止相关进程，保留镜像、网络日志和磁盘快照，再开展离线检查。

重点文件包括：

cook.pth
cook.py
sitecustomize.py
cook*.pyc
sitecustomize*.pyc
/tmp/remote_code_loader.lock
/tmp/.pc_once_72129118c59f5636c0bb

6.3 清理与重建

仅卸载LiteLLM不能保证环境已恢复。建议删除受影响虚拟环境和容器，从可信基础镜像重建，并清理wheel缓存、构建缓存与制品仓库中的对应版本。

在新的可信环境中，可按维护者建议固定至未受影响版本：

pip install 'litellm==1.106.2'

生产环境应进一步固定wheel哈希或镜像摘要，避免继续依赖latest等浮动标签。

6.4 凭据轮换

只要恶意版本在有网络访问能力的机器上运行过，应按凭据已经泄露处理。至少应轮换：

• 云平台访问密钥与实例角色临时凭据。
• SSH、GPG和代码签名私钥。
• GitHub、GitLab、npm、PyPI等开发平台令牌。
• LiteLLM上游模型密钥、虚拟密钥、主密钥和数据库密码。
• CI/CD、Kubernetes、Vault、Terraform及容器仓库凭据。
• AI工具登录令牌与本地配置文件中的API Key。

6.5 供应链防护

此次事件暴露了源码标签与发布产物之间的完整性缺口。建议采取以下控制措施：

• 对PyPI发布启用Trusted Publishing和构建证明。
• 对关键依赖固定文件哈希，不依赖版本号或浮动标签。
• 对容器镜像固定摘要，并验证SLSA provenance与签名主体。
• 将构建环境与开发者主机隔离，限制发布工作流的仓库来源参数。
• 在依赖安装阶段执行恶意包检测，并保留完整制品审计记录。

七、结论

LiteLLM1.107.0供应链投毒事件已由Socket、LiteLLM维护者、恶意包数据库及GitHub提交记录交叉确认。受影响产物具有安装即执行、凭据窃取、远程代码加载和持续驻留能力，影响不应仅按普通依赖漏洞评估。

PHP与Node.js当日披露的远程代码执行漏洞需要尽快修补。LiteLLM事件则要求同时检查构建链、制品链和凭据暴露面。两类处置并不冲突：运行时补丁解决服务暴露问题，供应链排查解决开发与发布环境是否已被植入后门的问题。

参考文献

[1] SOCKET RESEARCH TEAM. LiteLLM PyPI Package and Docker Images Compromised to Steal Cloud and AI Credentials[EB/OL]. (2026-10-21)[2026-10-21]. https://socket.dev/blog/litellm-compromise.

[2] BERRIAI. [SECURITY] litellm 1.107.0 compromised: cook.pth credential stealer + sitecustomize RCE loader[EB/OL]. GitHub Issue #47826, (2026-10-21)[2026-10-21]. https://github.com/BerriAI/litellm/issues/47826.

[3] OPEN SOURCE SECURITY FOUNDATION. Add litellm 1.107.0 (PyPI): credential stealer and backdoor[EB/OL]. GitHub Pull Request #1655, (2026-10-21)[2026-10-21]. https://github.com/ossf/malicious-packages/pull/1655.

[4] THE PHP GROUP. Security Advisory: Critical Remote Code Execution Vulnerabilities, Update Now[EB/OL]. (2026-10-21)[2026-10-21]. https://www.php.net/index.php#2026-10-21-5.

[5] NODE.JS SECURITY TEAM. Wednesday, October 21, 2026 Security Releases[EB/OL]. (2026-10-21)[2026-10-21]. https://nodejs.org/en/blog/vulnerability/october-2026-security-releases.