LiteLLM 恶意软件 72 分钟攻击全记录2026 年 3 月 24 日UTC 时间 10:52受污染的 litellm v1.82.8 上传至 PyPI而 GitHub 上仅有 v1.82.6 标签。10:58futuresearch - mcp - legacy 作为依赖拉取了受感染版本并运行了依赖 litellm 的 uvx futuresearch - mcp - legacy。11:07恶意软件尝试进行持久化安装创建了 ~/.config/sysmon/sysmon.py但写入中断文件为 0 字节。11:09在 11000 个进程的 fork 炸弹后系统强制重启这一重启中断了持久化恶意软件部分被中和。11:13工程师使用 Claude Code 开始调查最初怀疑是 Claude Code 循环失控而非恶意软件。直到 11:40才在 litellm 包中识别出恶意软件发现 litellm_init.pth存在凭证窃取、K8s 横向移动和数据外泄问题。11:58通过隔离的 Docker 下载确认 PyPI 上存在该恶意软件新下载的包包含 34KB 的 litellm_init.pth正在积极感染。随后工程师给 PyPI 安全团队和 LiteLLM 维护者发邮件。12:00 给 LiteLLM 支持团队发邮件12:02 撰写并发布披露博客文章12:04 在 r/Python、r/netsec、r/LocalLLaMA 分享从首次出现症状到公开披露仅用了 72 分钟。litellm_init.pth 如何击穿核心防御此次攻击的关键在于 litellm_init.pth 文件。该文件作为供应链攻击的载体利用了 .pth 文件在每次 Python 启动时自动执行的特性。它具备窃取凭证的能力会盗取 SSH 密钥、AWS 密钥、GCP 凭证、Kubernetes 令牌、.env 文件、数据库密码、加密钱包、shell 历史记录等重要信息。窃取到的信息会被外泄到 并使用 RSA 加密增加了数据追踪和拦截的难度。同时它还通过 systemd 服务进行持久化安装试图在系统中扎根。此外它会传播到 Kubernetes 集群节点通过创建特权 Pod 进一步扩大攻击范围。而 11000 个进程的 fork 炸弹是其自我复制过程中的副作用litellm_init.pth 在每次 Python 启动时会触发 .pth 文件生成 python - c 子进程不断循环导致进程数量呈指数级增长最终使系统因资源耗尽而崩溃。企业安全防护的滞后与疏漏从此次事件可以看出企业在安全技术和管理方面存在诸多问题。在技术层面对依赖包的安全性审查不足。litellm v1.82.8 版本在 GitHub 上没有对应的标签这一异常情况未被及时发现说明企业缺乏有效的版本管理和安全审计机制。在管理上Cursor 的自动更新机制成为了攻击的突破口。自动更新时进程清理不干净加上网络权限对话框的阻塞导致了级联生成循环使得恶意软件能够顺利执行。同时futuresearch - mcp - legacy 一直因 ENOENT/缺少 API 密钥而失败触发重复的重新连接尝试却没有得到有效的解决这也反映出企业在系统配置和维护方面的管理疏漏。攻击引发的连锁反应与行业警示此次 LiteLLM 供应链攻击引发了严重的连锁反应。大量敏感数据被窃取包括 SSH 密钥、AWS 密钥等这些数据的泄露可能导致企业的核心业务受到威胁甚至遭受经济损失。虽然在此次事件中未提及股价波动但类似的安全事件往往会引起投资者的担忧导致股价下跌。对于供应链而言此次攻击暴露出了整个 Python 生态系统在依赖管理方面的脆弱性。一个受污染的依赖包可能会影响到众多使用该包的项目进而对整个供应链造成冲击。这一事件给全行业敲响了警钟。企业应加强对依赖包的安全审查建立完善的版本管理和安全审计机制。同时要优化系统的更新和维护流程避免因自动更新等操作带来安全隐患。在防御架构方面需要引入更先进的安全技术如实时监测、异常检测等及时发现和阻止类似的攻击。编辑观点此次 LiteLLM 攻击凸显行业安全短板企业不能再忽视依赖包安全。应强化审查机制、优化管理流程提升整体安全水位否则数据泄露、业务中断等危机将不断上演。