文章总结： 2026年3月24日litellm包在PyPI遭供应链投毒，恶意版本利用.pth文件在Python启动时窃取凭据并尝试K8s横向移动与持久化。文章详细分析了攻击链路，建议受影响团队立即隔离主机、清除恶意版本、排查后门并全面轮换凭据，同时强调需监控发布链路异常、落实依赖治理与最小权限原则以降低供应链风险。 综合评分： 91 文章分类： 供应链安全,应急响应,漏洞预警,恶意软件

Litellm 供应链遭受攻击，今晚安装或升级请注意防范

SecureNexusLab

2026年3月24日 23:48 北京

3 月 24 日，litellm 在 PyPI 发布的 1.82.8（后续更新显示 1.82.7 也受影响）被植入恶意载荷。问题的严重性不在“这个包有漏洞”，而在于：它把攻击执行点放在了 Python 启动链路里，天然跨业务代码边界，并且具备凭据窃取、集群横向和持久化能力。

如果你的团队在该时间窗口升级过依赖，或者是被间接依赖带入，请按“已暴露”处理，而不是按“普通回滚”处理。

根据小编实时追踪，北京时间晚上8点，@hnykda在X发布预警，11点30左右，官方已将1.82.7版本移除

先理解影响面：litellm 为什么值得警惕

litellm 本质上是一个 LLM 访问适配层。它统一了不同模型厂商接口，提供路由、重试、成本统计等能力。对工程团队来说，它常常部署在“AI 网关”位置，总下载量次数4亿次。

这个位置有两个特征：

• 离核心凭据很近：.env、云密钥、数据库连接串往往都在；
• 权限通常不低：能访问内部服务，甚至能触达 K8s 控制面。

所以，一旦这类组件被投毒，事件等级会从“应用 bug”直接上升到“供应链 + 基础设施安全”。

事件时间线与异常点

根据公开信息，北京时间 2026-03-24 18:52 ，litellm 1.82.8 发布到 PyPI。关键异常：GitHub 仓库没有对应 tag/release，呈现“绕过常规发布流程，直接上传包仓库”的特征。

恶意版本内含 litellm_init.pth。.pth 文件会在 Python 解释器启动时被处理，这意味着触发条件不是“你是否 import 了某个模块”，而是“这个环境里是否启动了 Python 进程”。

公开样本还暴露了一个实现缺陷：恶意逻辑会递归触发，形成类似 fork bomb 的资源耗尽。这是攻击代码的 bug，但对受害方来说，结果一样糟糕：机器先不稳定，再谈排查。

攻击链路：三步走

1）信息收集（Collection）

目标很明确：把机器上能用的凭据尽可能拿走。包括 SSH 私钥、.env、云厂商凭据、K8s 配置、数据库密码、shell 历史等；同时读取环境变量并访问云元数据接口（IMDS/container credentials）。

2）数据外传（Exfiltration）

数据会先加密打包（AES-256-CBC + 内置 RSA 公钥封装会话密钥），然后 POST 到 https://models.litellm.cloud/。公开分析指出，该域名不属于 litellm 正常基础设施。

3）横向移动与持久化（Lateral Movement & Persistence）

若发现 Kubernetes service account token，恶意代码会尝试读取全局 secrets，并在 kube-system 创建高权限 alpine:latest Pod，挂载宿主机后写入持久化后门：/root/.config/sysmon/sysmon.py，再通过 systemd 用户服务维持驻留。

本机也会尝试类似持久化路径。

工程团队该怎么判断自己是否中招

满足任一条件，就建议按“已暴露”流程走：

• 3 月 24 日及之后安装/升级过 litellm；
• CI/CD 在该时间窗口拉取了新依赖；
• 使用 uv/pip 且可能命中缓存 wheel；
• 运行环境中有云凭据、数据库密钥、K8s token。

优先执行的检查动作：

• 版本确认：pip show litellm
• 缓存排查：find ~/.cache/uv -name "litellm_init.pth"
• 持久化排查：~/.config/sysmon/sysmon.py、~/.config/systemd/user/sysmon.service
• 集群审计：kube-system 内是否存在 node-setup-* 可疑 Pod

应急处置顺序（按优先级）

1. 「先隔离，再分析」 把受影响主机/容器从网络和生产链路中摘出来，先止血。
2. 「清除恶意版本与缓存」 卸载受影响 litellm，清理缓存（rm -rf ~/.cache/uv 或 pip cache purge），避免“修完又装回去”。
3. 「排查持久化和横向痕迹」 重点看 sysmon 路径、node-setup-* Pod、异常 secret 读取记录。
4. 「轮换凭据，按最坏情况处理」 SSH、云 AK/SK、K8s 配置、数据库密码、.env API Key 全部进入轮换清单。
5. 「补齐审计闭环」 回放异常出网、密钥调用、集群控制面操作日志，确认影响边界。

一句话：这是“凭据失陷 + 可能入侵”的响应模型，不是“简单版本回滚”的响应模型。

公开信息入口

• 讨论入口： litellm #24512
• 作者主页： author

公开信息曾出现讨论线程关闭与噪声干扰。对工程团队来说，不要把处置节奏绑定在“舆论定性”上，应该绑定在“证据与资产风险”上。

这次事件的三个长期教训

1. 「把发布链路异常当成一等告警」 比如“PyPI 有新版本，但源码仓库无 tag/release”。这类信号应该触发人工复核，而不是自动放行。
2. 「把依赖治理做成工程能力」 固定版本、启用哈希校验、减少在线拉取 latest，把“可复现构建”落到流水线，而不是停在制度。
3. 「把凭据暴露面压到最小」 最小权限、短时令牌、分级隔离。供应链攻击不可完全避免，但横向扩散可以被显著限制。

安全不是“绝不出事”，而是“出事时损失可控、恢复可预期”。

这次 litellm 事件，给所有做 AI 基础设施和平台工程的团队都提了个醒：依赖管理，已经是生产安全的一部分。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：SecureNexusLab 《Litellm 供应链遭受攻击，今晚安装或升级请注意防范》