紧急预警!千万级Python库遭投毒,一行pip命令,全球开发者集体“裸奔”

最近AI圈炸了一场无声的惊雷——没有轰轰烈烈的漏洞通报，没有高调的黑客宣称，一场针对全球AI开发者的供应链攻击，悄无声息地席卷而来。

主角是月下载量近亿、GitHub星标超4万的Python热门库LiteLLM，一个被无数开发者依赖的AI模型网关工具。谁也没想到，一行简单的pip install litellm，竟成了黑客窃取核心信息的“开门密码”，无数企业的AI密钥、云资产、数据库密码，在不知情中被洗劫一空。

AI大佬Andrej Karpathy紧急预警：这是现代软件开发最恐怖的噩梦。而这场噩梦，离每一个正在用AI开发的你，都近在咫尺。

这场攻击的隐蔽性、破坏力，远超普通人的想象。整个过程短促而精准，堪称“教科书级”的AI供应链投毒。

时间回到2026年3月24日，疑似有组织威胁团伙TeamPCP，利用此前窃取的PyPI发布令牌，向Python官方仓库上传了LiteLLM的两个恶意版本——1.82.7和1.82.8。这两个版本在GitHub上没有任何对应标签和发布记录，完美伪装成正常更新，悄无声息地流向全球开发者。

更可怕的是，这次攻击没有任何“触发门槛”：

对于1.82.8版本，黑客利用Python的.pth自动加载机制，只要你安装了这个版本，哪怕不导入、不运行，只要启动Python进程——无论是打开IDE、执行脚本，甚至只是输一次pip命令，恶意代码都会自动执行，静默完成窃密操作。

而1.82.7版本则将恶意代码植入proxy_server.py文件，只要导入litellm.proxy，就会触发窃密行为。

这场攻击能被及时发现，纯属偶然——因为恶意代码写得过于粗糙，导致部分用户安装后出现内存爆掉的异常，才被安全研究员捕捉到痕迹。如果不是这个“低级bug”，这两个版本一旦大规模扩散，后果不堪设想：无数企业的AI基础设施、云服务器、核心数据库，都将沦为黑客的“囊中之物”。

更值得警惕的是，这并非TeamPCP的首次出手。在LiteLLM攻击前5天，该团伙先后攻击了Trivy、Checkmarx等安全工具，通过阶梯式攻击，窃取各类CI/CD密钥，最终瞄准了使用量巨大的LiteLLM，形成“连锁反应”式的供应链攻击战役。

很多开发者可能会觉得“我只是用LiteLLM做个简单开发，能有什么敏感信息？”但事实是，这次的恶意代码，堪称“全方位窃密机器”，只要你安装了恶意版本，几乎没有任何隐私可言。

根据安全机构的拆解，恶意代码的窃密范围涵盖了开发者和企业的核心资产，甚至包括加密货币钱包：

• AI相关密钥：OpenAI、Claude、阿里、腾讯、DeepSeek、Kimi等所有主流大模型的API Key，一键窃取；
• 云服务凭证：AWS、Azure、GCP、阿里云等云厂商的AccessKey、配置文件，拿到就可以直接操控云资源；
• 服务器与代码凭证：SSH私钥、Git账号密码、Shell历史记录，甚至能拿到数据库密码、K8s配置、Docker凭证；
• 其他敏感信息：.env环境文件中的所有配置、加密钱包的助记词和私钥，以及系统主机名、IP地址等侦察信息。

更阴狠的是，恶意代码还会实现持久化驻留——在你的系统中植入伪装成“系统遥测服务”的后门，通过systemd设置开机自启，哪怕你卸载了LiteLLM，后门依然存在，持续窃取信息。同时，它还会尝试横向渗透内网和云服务器，甚至在Kubernetes环境中部署特权Pod，实现容器逃逸，将危害从个人终端扩散到企业整个生产环境。

更致命的是，所有窃取的数据都会经过AES-256-CBC+RSA-4096双重加密后，发送到黑客的C2服务器，哪怕流量被捕获，也无法解密还原。也就是说，一旦中招，你甚至不知道自己的哪些信息被泄露、泄露到了哪里。

目前，PyPI已经下架了这两个恶意版本，LiteLLM官方也紧急发布了安全版本，但对于已经安装了恶意版本的开发者和企业，风险依然存在。

第一步：立即自查，确认是否中招

在终端执行以下命令，查看自己安装的LiteLLM版本：

pip show litellm | grep Version 

如果结果显示为1.82.7或1.82.8，说明你已经中招，必须立即按以下步骤处置！

第二步：中毒后完整处置流程（照做即可）

1. 卸载恶意版本，锁定安全版本

pip uninstall -y litellm pip install litellm==1.82.6 

1. 删除已知后门文件

rm -rf ~/.config/sysmon/ rm -f ~/.config/systemd/user/sysmon.service systemctl --user daemon-reload 

1. 清理可疑.pth木马文件

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \ -name "*.pth" -exec grep -l "base64\|exec\|systemd" {} \; 

列出的文件逐一检查，凡是包含可疑代码的，直接删除。

1. 最关键：全部密钥重置！只要装过恶意版本，默认所有密钥已泄露，必须立即重置以下内容：

• 所有LLM API Key（OpenAI、Claude等）；
• 云厂商AK/SK、SSH密钥、数据库密码；
• 环境变量中的所有敏感配置；
• 检查云控制台是否有异常实例、权限策略。

很多人看完会觉得，这只是一次偶然的开源库投毒，但真相远比我们想象的更严峻。

就在LiteLLM事件爆发的同时，国内流行API协作平台Apifox、AI开发工具Context Hub也相继遭遇供应链投毒，均指向同一类威胁——AI工具链供应链攻击。攻击者针对文档平台、模型网关、开发工具三条路径实施入侵，呈现出“立体化打击”的特征。

这背后，是AI时代开源生态的致命短板：我们太依赖开源工具，却太容易忽视开源工具的安全风险。

随着AI技术的普及，开发者为了提高效率，会大量引入第三方开源库、AI工具，而这些工具就像供应链上的“节点”，只要有一个节点被攻破，整个链条都会被污染。就像这次的LiteLLM，作为AI模型网关，它被无数项目依赖，一旦被投毒，所有依赖它的项目都会同步中招，形成“多米诺骨牌效应”。

更值得警惕的是，AI供应链攻击的门槛正在不断降低。正如全国政协委员、奇安信集团董事长齐向东所说，AI向“超人化”演进，不仅提升了开发效率，也降低了网络攻击的成本和门槛，加剧了“易攻难守”的危机。攻击者不再需要复杂的技术，只要窃取一个发布令牌、植入一段恶意代码，就能实现大规模攻击。

而这次LiteLLM事件，只是AI供应链攻击的一个缩影。从2月Cline CLI遭遇AI专属漏洞驱动的供应链攻击，到3月TeamPCP连续发起多起攻击，不难发现：AI供应链安全风险，已经从理论探讨迈入实际运营阶段，成为所有开发者和企业都必须面对的“生存考验”。

AI时代，效率与安全从来都不是对立的。想要享受AI带来的便利，就必须守住安全的底线。结合这次LiteLLM事件，给所有开发者整理了一份“保命清单”，建议收藏备用：

• 版本永远写死，拒绝“模糊依赖”
  ：不要用litellm>=1.0.0这种模糊的版本依赖，一定要写死具体版本，比如litellm==1.82.6，并加入版本控制，避免自动更新到恶意版本。
• 安装前先验包，警惕异常版本
  ：安装开源包前，先检查PyPI发布时间是否异常，对比GitHub官方发布记录，突然出现的版本、没有对应源码的版本，一律谨慎安装。
• 环境隔离，守住权限边界
  ：本地开发机和生产环境严格分离，不要在开发机上存放生产环境的敏感密钥；密钥不要明文写在.env文件中，尽量使用云密钥管理、临时凭证。
• 定期扫描漏洞，及时更新依赖
  ：使用Snyk、Safety、pip-audit等工具，定期扫描项目依赖的漏洞；对于长期不维护、存在安全隐患的开源库，及时替换。
• 减少不必要依赖，降低攻击面
  ：能用几行代码实现的功能，不要随便引入第三方包；依赖越少，被攻击的概率就越低。
• 开启告警，及时发现异常
  ：在云平台、AI平台开启异常调用告警、地域限制、速率限制，设置密钥自动轮转，一旦出现异常，立即止损。
• 警惕“免费陷阱”，拒绝不安全渠道
  ：不要为了省钱使用共享密钥、破解版客户端、非官方渠道的开源包，这类渠道最容易被投毒、窃密。

AI的爆发式发展，让我们习惯了“快速开发、高效迭代”，但我们不能因此忽视了最基本的安全底线。

这次LiteLLM事件给我们上了深刻的一课：你pip install的每一个包，都可能是一扇通往你核心资产的“后门”；你随手引入的每一个依赖，都可能成为黑客攻击的“突破口”。

对于开发者而言，安全不是“可选项”，而是“必选项”——多花一分钟检查版本，多做一步环境隔离，就能避免后续无数的麻烦；对于企业而言，更要建立完善的AI供应链安全体系，将安全能力嵌入AI应用的全生命周期，用“AI+安全”对抗AI带来的安全风险。

毕竟，没有安全的创新走不远，也走不稳。

愿每一位开发者都能守住安全底线，在AI时代既能享受效率的红利，也能守护好自己的核心资产。

最后，建议大家把这篇文章转发给身边的开发者朋友，提醒他们自查防护，避免中招。

关注我，持续为你解读AI圈的安全隐患与实用技巧，一起在AI时代安全前行。