文章摘要
作者记录了发现并应对LiteLLM 1.82.8供应链攻击的全过程,展示了AI工具如何加速恶意软件检测。作为促使PyPI隔离该软件包的工程师,他分享了从日常检查到确认攻击的详细时间线,体现了开发者借助AI能更快发现安全威胁。
文章总结
我对LiteLLM恶意软件攻击的逐分钟响应记录
作者:Callum McMahon
发布日期:2026年3月25日
事件概述
2026年3月24日,我作为工程师发现并促使PyPI隔离了受污染的litellm软件包。这是一次典型的软件供应链攻击,攻击者通过向PyPI上传带有恶意代码的litellm 1.82.8版本,试图窃取用户敏感信息。
攻击时间线
- 10:58:通过Cursor编辑器自动更新下载了受感染的litellm包
- 11:07:恶意软件尝试建立持久化机制
- 11:09:我强制重启电脑以中断攻击
攻击分析
恶意代码通过litellm_init.pth文件实现攻击,该文件会在每次Python启动时自动执行,具有以下功能:
- 窃取凭证:收集SSH密钥、AWS/GCP凭证、Kubernetes令牌、.env文件等敏感信息
- 数据外泄:将加密后的数据发送至
https://models.litellm.cloud/ - 持久化机制:在
~/.config/sysmon/目录下安装监控脚本 - 横向移动:尝试通过Kubernetes集群传播
- 自我复制:导致系统出现约11,000个Python进程的"fork炸弹"
响应措施
- 确认攻击:在Docker容器中复现了恶意包的下载
- 发布警告:12:01撰写并发布博客文章披露攻击细节
- 通知社区:建议在r/Python和r/netsec等Reddit板块分享警告
- 系统清理:清除uv缓存(
rm -rf ~/.cache/uv)
安全建议
- 立即轮换所有可能泄露的凭证(SSH密钥、云服务凭证等)
- 检查近期是否安装过litellm 1.82.8版本
- 向PyPI安全团队(
security@pypi.org)和litellm维护者报告 - 考虑禁用软件自动更新功能,改为手动更新
后续行动
12:13分发现Cursor编辑器再次触发了恶意包,立即进行了二次清理。最终确认Kubernetes集群未受影响,但建议仍应轮换相关凭证。
这次事件展示了AI工具在加速恶意软件检测方面的价值,整个过程从发现到公开披露仅用了约2小时。
评论总结
以下是评论内容的总结:
发现漏洞的过程与AI辅助
- 开发者Callum分享了使用Claude AI实时分析漏洞的经历,认为AI能帮助非安全专家快速识别和报告漏洞。
- 引用:"having Claude walk me through... felt like a game-changer" / "AI的辅助让非专家也能快速应对漏洞"
- 引用:"democratization of reverse engineering... pointed in the right direction easily" / "AI降低了逆向工程的门槛"
供应链安全的担忧
- 评论者指出依赖第三方库(如PyPI)的风险,建议减少依赖或使用原生代码。
- 引用:"infection chain: Cursor → futuresearch... → litellm" / "依赖链的污染令人担忧"
- 引用:"consider writing native software... no supply chain attack on libc" / "建议改用原生代码规避供应链攻击"
漏洞响应与改进建议
- PyPI快速响应(30分钟隔离包)获好评,有人提议开放实时数据流以加强安全分析。
- 引用:"PyPI reacted so quickly... pretty great!" / "PyPI的快速反应值得肯定"
- 引用:"GitHub/npm should expose a firehose... catch attacks immediately" / "建议包平台开放实时数据流"
AI的双刃剑效应
- 部分评论肯定AI提升效率(如快速重构代码),但也警告生成式AI可能引入漏洞。
- 引用:"created $100k worth of code in 90 minutes" / "AI助我90分钟完成高价值代码"
- 引用:"generative parts... unconditional net negative" / "生成式AI可能带来绝对负面影响"
其他观点
- 对攻击影响范围的疑问("extent of damage?"),以及对YCombinator背景公司的质疑。
- 对11k进程炸弹加速漏洞发现的讨论("how much longer would it take?")。