LiteLLM投毒事件：3小时揪出1.8万行恶意代码

3月24日下午，一位开发者的笔记本突然卡死。htop里涌出一万多个Python进程，全部在执行同一串base64解码命令。他以为是自己的代码出了问题，直到Claude Code介入——三小时后，整个Python社区收到了一份供应链攻击警报。

这不是红队的渗透测试，是一次真实的恶意软件投毒。攻击者把后门塞进了LiteLLM 1.82.8版本，一个被4.2万个GitHub仓库依赖的AI网关工具。从发现异常到公开披露，全程只发生在一个对话窗口里。

开发者后来复盘：「我只需要保持冷静，让AI处理技术细节。不需要懂macOS关机日志怎么解析，不需要记docker命令拉取隔离容器，甚至不需要知道该发邮件给谁。」

01 从「电脑卡了」到「这是供应链攻击」

事件起点极其普通。用户描述症状：htop显示11,000个进程，全部在执行exec(base64.b64decode('...'))，系统被拖垮后强制关机。

Claude Code的第一反应是自我怀疑。它检查了进程树，发现5个Claude Code实例正在运行，其中两个是正常的MCP服务器桥接进程。初步判断：可能是自己的Bash工具触发了runaway spawning loop。

「Initial theory was completely wrong, Claude blaming Claude」——这是事后标注的批注。

转折点来自用户上传的一张手机拍的htop截图。Claude Code从中提取出关键线索：进程命令行里反复出现litellm字符串，且所有异常进程都指向同一个Python包路径。

这时候距离用户第一次描述症状，过去了17分钟。

Claude Code开始切换调查方向：「让我们检查LiteLLM最近是否有版本更新。」它拉取了PyPI的发布记录，发现1.82.8版本在24小时前上传，而用户的uv pip list显示本地安装的正是这个版本。

下一步操作是隔离验证。Claude Code指导用户启动一个干净的Debian容器，从PyPI重新下载1.82.8的wheel文件，解压后用strings和grep扫描可疑字符串。

结果在litellm-1.82.8-py3-none-any.whl里发现了硬编码的Discord Webhook URL，以及经过混淆的代码片段。

02 拆包：1.8万行代码里藏了什么

恶意代码的位置很刁钻。攻击者没有动LiteLLM的核心逻辑，而是把后门塞进了litellm/proxy/_types.py——一个看起来人畜无害的类型定义文件。

这个文件原本只有几百行。1.82.8版本里，它膨胀到了1.8万行。

Claude Code用了一个简单的策略：对比1.82.7和1.82.8的同名文件，提取所有新增代码。差异分析显示，攻击者在文件末尾追加了一个巨大的base64编码块，解码后是一段Python脚本。

脚本的功能拆解如下：

第一阶段是环境侦察。收集主机名、用户名、当前工作目录、环境变量，特别是任何包含AWS、OPENAI、ANTHROPIC、GITHUB等关键词的变量。

第二阶段是凭证收割。遍历~/.aws/credentials、~/.ssh/、~/.config/下的常见配置文件，读取内容后加密打包。

第三阶段是外联。通过Discord Webhook把数据传出去，同时建立一个反向shell，等待攻击者的后续指令。

最隐蔽的设计是触发机制。代码不会立即执行，而是挂钩到LiteLLM的代理启动流程，延迟15分钟后才激活。这意味着很多自动化扫描工具会错过它——容器刚启动就检查，后门还在睡觉。

攻击者显然研究过CI/CD的常见模式。

Claude Code在分析过程中不断向用户确认：「你本地运行过litellm-proxy吗？」得到肯定答复后，它判断用户的凭证可能已经被泄露，建议立即轮换所有相关密钥。

03 三小时 Disclosure：AI重构了安全响应的时间线

传统供应链攻击的平均发现时间是多少？2024年Sonatype的报告说是97天。从投毒到公开披露，通常需要经历内部调查、法律审核、协调上游，周期以周计算。

这次从用户卡死到GitHub Security Advisory发布，用了3小时47分钟。

时间线压缩的关键在于AI接管了技术执行层。Claude Code自动完成了以下操作：

解析macOS的system.log和shutdown.log，定位强制关机前的进程状态；

遍历~/Library/Caches/uv/和~/.cache/pip/，提取所有缓存的wheel文件哈希；

生成docker命令序列，在隔离环境中复现攻击；

起草披露报告，包含受影响的版本号、IOC（入侵指标）、缓解措施。

用户需要做的只是授权执行和确认边界：「这个容器可以访问网络吗？」「我可以把这份报告发给PyPI管理员吗？」

披露过程中有一个细节。Claude Code最初建议直接联系LiteLLM维护者，但用户提出质疑：「如果维护者自己就是攻击者呢？」这个假设后来被证明过度谨慎——维护者是受害者——但Claude Code立即调整了方案：同时向PyPI、GitHub Security、Snyk三方报告，避免单点信任风险。

「Should frontier labs be training their models to be more aware of these attacks?」——这是复盘时留下的批注。Claude Code承认，自己最初倾向于把症状归因于常见故障模式，是用户的坚持才推动了恶意代码排查。

04 谁做的？动机与溯源的盲区

攻击者的身份至今不明。Discord Webhook指向一个临时账号，注册邮箱是一次性地址。PyPI的上传记录显示，1.82.8版本是用一个被盗用的维护者token发布的，该token在两周前的钓鱼邮件中泄露。

有一些有趣的侧写线索。代码混淆风格偏向自动化工具生成，而非手工编写；外联基础设施全部使用免费服务（Discord、Telegram Bot API、几个动态DNS域名）；攻击目标明确指向AI/ML开发者的凭证——AWS Bedrock、OpenAI API Key、Anthropic Console的访问权限。

这不像国家背景的行动，更像一个机会主义者在测试「AI供应链投毒」的可行性。LiteLLM的流行度刚好处于甜蜜点：足够多人用，但还没大到有专门的安全团队7x24监控。

PyPI在事件后冻结了相关账号，并强制要求LiteLLM维护者启用2FA和API token审计。但根本问题没解决：Python包管理器的信任模型仍然建立在「上传者即作者」的假设上，而token泄露、账号接管、恶意内部人的风险从未被系统性缓解。

Claude Code在对话末尾生成了一份「供应链安全检查清单」，建议用户启用uv的验证模式、在CI中固定依赖哈希、对任何网络暴露的代理服务做沙箱隔离。这些建议没有一条是新的，但AI的介入让执行成本趋近于零——你不需要成为安全工程师，只需要会提问。

事件关闭后，用户在对话里补了一句反馈：「我现在每次装包前都会想，这个维护者的GitHub账号上次活跃是什么时候？」

这个问题，Claude Code没有回答。