智猩猩AI整理

编辑：汐汐

计算机开发者基本都离不开 Python。从 AI 模型训练、数据科学分析，到 Web 后端开发和自动化脚本，Python 凭借简洁语法和海量生态，已连续多年稳居全球最受欢迎编程语言之首。无论是初创团队还是科技巨头，几乎每一条生产流水线都建立在 Python 之上。

而 Python 生态的命脉之一，正是 pip 指令。一行 pip install xxx 就能自动拉取依赖、解析版本冲突的便利性，让开发者得以专注业务而非底层细节。可这份“即装即用”的信任，却把整个供应链脆弱得像一张薄纸：只要源头被污染，所有下游瞬间沦陷。

就在2026年3月24日，这个隐患彻底爆炸。月下载量近9700万次的热门包 LiteLLM，一个AI 开发者用来统一调用 100+ 大模型的“网关”，其 1.82.7 和 1.82.8 两个版本被投毒。

LiteLLM在AI/ML领域，超过百家LLM服务商通过LiteLLM作为AI网关，并且目前Github星标数已超40k。

Andrej Karpathy 一针见血地警告：“Simple pip install litellm 就足以窃取你的一切凭证。”

01 卡帕西警告LiteLLM被投毒

2026年3月24日，一切来得毫无征兆。

UTC 10:39 AM，LiteLLM 1.82.7悄然出现在PyPI；

约1小时后，1.82.8版本紧随其上。两个版本均无对应的GitHub Release，直接绕过正常发布流程，由维护者PyPI账号（疑似krrishdholakia）上传。

这是TeamPCP黑客团伙在攻破Trivy安全扫描工具后，通过LiteLLM CI/CD流程实现的又一次供应链攻击。版本上线后仅存活1-3小时，便被PyPI团队发现并隔离、移除。

3月25日，Karpathy发帖，直呼“Software horror: LiteLLM PyPI supply chain attack”。他强调说，无需import，只要pip install litellm，恶意代码就已就位。

是的，你没看错，你甚至不需要导入这个黑客版本的包，你下载了这个包，你就已经被攻击了。

02 LiteLLM恶意包细节

此次LiteLLM包投毒事件的具体细节如下：

·恶意包1.82.7版本，payload藏在了proxy_server.py中，只要import就执行；

·恶意包1.82.8版本，黑客在其中植入了litellm_init.pth文件。Python site 模块会在每次解释器启动时自动执行，无需任何 import 触发；

·恶意代码为base64编码的凭证窃取器+自复制机制。窃取范围极广，包括~/.ssh/密钥、AWS/GCP/Azure凭证、Kubernetes配置、Git凭证、全部环境变量（含API Key）、Shell历史、加密钱包、SSL私钥、CI/CD密钥、数据库密码等。

·恶意代码存在连锁攻击，恶意代码会尝试Kubernetes横向移动（创建特权pod挂载主机文件系统），并安装systemd持久化后门。不仅直接安装者中招，所有依赖litellm>=1.64.0的项目（如dspy）都会被波及。

而发现这个恶意版本的过程也很有意思，据卡帕西介绍，是因为安全研究员Callum McMahon在使用Cursor MCP插件时，uvx自动拉取transitive dependency，恶意代码因fork bomb耗尽内存导致机器崩溃，这才暴露。若非攻击者vibe code写得太糙，潜伏数天、数周都有可能。

Callum McMahon本人于2026年3月24日撰写的原始事件记录，详细披露了LiteLLM 1.82.8（以及后续确认的1.82.7）恶意版本的完整技术细节、发现过程、payload分析，以及如何通过Cursor MCP插件的传递依赖中招。

详细内容可以查看其博客：https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

LiteLLM日均下载量约为340万，短期内可能已经有数万甚至数十万实例暴露，PyPI已经将整个包临时下架并隔离。

如果你没有安装1.82.7或1.82.8版本，但是需要使用LiteLLM，使用下列方法安装：

pip install "litellm<=1.82.6"

# requirements.txt:

litellm<=1.82.6

如果你已经安装了这两个恶意版本，无论是否运行了代码都可能受到攻击，采用如下方法可以做一定防护：

rm -f ~/.config/sysmon/sysmon.py

rm -f ~/.config/systemd/user/sysmon.service

systemctl --user disable sysmon.service 2>/dev/null

systemctl --user daemon-reload

rm -f /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc /tmp/session.key.enc /tmp/.pg_state /tmp/pglog

同时，替换掉所有的：

SSH私钥：authorized_keys；

云凭证：例如AWS访问密钥；

API密钥：文件、shell 环境变量等；

Docker注册表凭证：~/.docker/config.json；

Kubernetes：~/.kube/config；

系统中的数据库密码；

git凭证：~/.gitconfig；

并且，根据Snyk官网给出的方案可以检查并加强安全防护。

1.检查安装的版本

pip show litellm | grep Version

如果显示1.82.7或1.82.8，则已经受到了攻击，立刻全量替换所有凭证（

云密钥、SSH、K8s token、API Key全部重置）

2.检查持久化伪影

# Check for the sysmon backdoor

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"

ls -la /root/.config/sysmon/sysmon.py 2>/dev/null && echo "ROOT BACKDOOR FOUND"

# Check for the systemd persistence service

systemctl --user status sysmon.service 2>/dev/null

ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null && echo "PERSISTENCE SERVICE FOUND"

# Check for exfiltration archive remnants

ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc /tmp/session.key.enc 2>/dev/null && echo "EXFIL ARTIFACTS FOUND"

3.检查malicious .pth files

# Find .pth files in site-packages with suspicious patterns

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \

  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

4.确认哈希值

# Check proxy_server.py (1.82.7)

find / -path "*/litellm/proxy/proxy_server.py" 2>/dev/null -exec shasum -a 256 {} \;

# Malicious: a0d229be8efcb2f9135e2ad55ba275b76ddcfeb55fa4370e0a522a5bdee0120b

# Check litellm_init.pth (1.82.8)

find / -name "litellm_init.pth" 2>/dev/null -exec shasum -a 256 {} \;

# Malicious: 71e35aef03099cd1f2d6446734273025a163597de93912df321ef118bf135238

5.检查网络特征

grep "litellm.cloud\|checkmarx.zone" /etc/hosts

grep "models.litellm.cloud\|checkmarx.zone" /var/log/syslog 2>/dev/null

6.检查Kubernetes

kubectl get pods -A | grep "node-setup-"

03 供应链攻击是现代软件最可怕的事情

卡帕西在帖子里直言，供应链攻击就是 “现代软件最可怕的问题”。依赖树看着像座稳固的金字塔，实则是颗随时会炸的定时炸弹。如今他自己也不再盲目依赖各类库，转而直接用LLM提取实现所需功能。

Snyk官方评论说，LiteLLM依赖事件并非“就这样发生了”，而是更大规模的一部分。

知名开发者swyx评论道，“这为我们敲响了警钟。像uv、bun等新型包管理器应该采取行动，降低这类事情的风险”

但是也有人质疑卡帕西的“利用LLM提取功能”的这一措施，表示“只是把一个未经审查的代码库换成了一个LLM输出的而已”。这个就比较见仁见智了，使用LLM过滤一遍对提高代码安全性是否存在帮助依然非常依赖提示词。

有开发者对此还感到后怕，因为那个包是非常非常多AI仓库的依赖，几乎每个人都在用他。足以可见本次攻击事件的问题之严重。

有用户提出了一个非常可怕的细节，那就是Cursor内部的MCP插件将LiteLLM作为传递依赖拉进来。在当今这个智能体无人审查的情况下安装软件包，导致shell访问权限也会成为一个攻击面。

对于此次恶意攻击被发现的原因，有网友调侃道“vibe coding”救了他们，还好他们代码太烂了而崩溃导致被发现了。

这甚至让有的用户直接质疑“依赖本身就是邪恶”。

04 开源供应链的系统性脆弱

LiteLLM投毒事件绝非 “单个软件包出问题” 那么简单，它恰恰是Python生态，乃至整个开源供应链系统性脆弱的真实缩影。

在AI时代，LLM工具本身已成为全新的攻击面。Cursor这类vibe coding 工具，正在把原本依赖人工审核的环节，变成默认信任的自动化流程，安全风险也因此呈指数级放大。

此次攻击事件早已超出了普通的独立项目，一次普通的安装操作，就可能导致企业核心数据泄露、K8s 集群全面沦陷、云服务费用暴增失控。

在AI/ML领域，LiteLLM作为对接上百家LLM服务商的工具，一旦API Key泄露，将直接引发下游模型滥用、造成巨额经济损失。行业合规认证（如 SOC 2）再也无法替代代码完整性校验，开源维护者账号被盗、CI/CD流程被污染...

但是，危机之中也给所有开发者和整个行业敲响了警钟。

这次由 “劣质代码” 引发的风险意外阻止了更严重的灾难，开源依赖的安全性不容忽视，安全应当是开发的核心，而不是一个事后补救的措施。

只有将依赖包的便捷性建立在可验证的信任之上，我们才能安心敲下每一行pip install。