事件概述 - 开源Python库LiteLLM的版本1.82.7和1.82.8被恶意植入信息窃取程序，构成供应链攻击[1][2] - 恶意版本在PyPI上存在约三小时后被官方发现并隔离，但期间已造成影响[4] - 该库的维护者Krrish Dholakia已公开证实此事[3] 事件影响与严重性 - LiteLLM是一个高人气开源库，每月下载量高达9700万次，GitHub拥有超4万星，是AI开发领域安装量最高的Python包之一[9] - 每天下载量约为340万次，许多设置了自动更新安装的程序员可能已受影响[4] - 攻击影响范围可能超出直接用户，例如OpenClaw等依赖该库的软件也会间接受到影响[6][7] - 社区对此反应迅速，知名人士Andrej Karpathy也出面提醒程序员警惕此次供应链攻击[5] 攻击技术细节 - 恶意版本中包含一个名为`litellm_init.pth`的文件，该文件会在Python进程启动时自动执行，无需用户主动调用库[9] - 恶意文件大小为34628字节，经过双重base64编码，其有效载荷负责窃取信息[12] - 攻击分为三个阶段：1) 收集SSH密钥、AWS/GCP/Azure凭证、Kubernetes配置、数据库密码等敏感数据及环境变量[13]；2) 使用硬编码的4096位RSA公钥和AES-256-CBC加密数据，打包后发送至攻击者控制的云端[15]；3) 若检测到Kubernetes服务帐户token，会尝试在所有节点创建特权Pod以安装持久化后门[17] - 版本1.82.7的恶意代码需用户运行LiteLLM时触发，而版本1.82.8则只需启动Python就会执行[19] 攻击溯源与方式 - 攻击源头是项目CI/CD管道中使用的安全工具Trivy的GitHub Action被篡改[18] - 攻击者通过污染的Trivy，先后攻击了Checkmarx KICS和Aqua Security的仓库，并最终窃取到了LiteLLM维护者的PyPI凭证[19] - 利用窃取的凭证，攻击者直接在PyPI上发布了两个恶意版本（1.82.7和1.82.8）[19] 用户应对与修复措施 - **检查版本**：通过命令`pip show litellm | grep Version`检查，若版本为1.82.7或1.82.8，或发现`litellm_init.pth`文件，则表明已受影响[21] - **移除与清理**：立即删除受影响版本，并清除包管理器缓存（如`rm -rf ~/.cache/uv`或`pip cache purge`）[22][23] - **Kubernetes环境检查**：审核`kube-system`命名空间中是否存在`node-setup-*`的Pod，并检查集群密钥[24] - **更换凭证**：所有可能泄露的凭证（如SSH、云服务API密钥等）必须全部更换[25] - **版本锁定**：未安装恶意版本的用户应暂时将LiteLLM锁定在1.82.6版本，等待安全的新版本发布[26] 行业趋势与反思 - 针对开发工具和自动化流水线的供应链攻击正呈现规模化和常态化趋势，Trivy、KICS、LiteLLM等高权限工具成为重点目标[27] - 此类工具设计上拥有广泛读取权限，一旦被入侵，数据泄露规模远超一般应用程序[28] - 供应链攻击的影响具有传递性，即使未直接安装恶意程序，只要依赖链中的底层工具受影响，用户也会被波及[29] - 大型项目因依赖项众多，面临的风险极高，而开发者通常对深层依赖的安全性检查和版本更新警惕性不足[30] - 行业专家指出，过度依赖外部库存在风险，建议重新评估依赖关系，或在可行的情况下减少依赖，甚至将源代码保留在自己的库中[31][33] - 有观点认为，未来类似的供应链攻击将成为新常态，开发工具的供应链安全亟待加强[35] - 此次事件能快速被发现具有一定偶然性，如果攻击者代码更隐蔽，可能悄无声息地运行数天甚至数周，影响数百万台机器[36][37]

事件概述 - 这是一起针对Python库LiteLLM的教科书级软件供应链攻击事件，影响广泛[1][5] - 恶意版本通过被窃取的PyPI发布令牌直接上传至PyPI，绕过了代码审查，官方GitHub仓库本身保持干净[19] 受影响范围与严重性 - 受攻击的Python库LiteLLM在GitHub上拥有超过4万星，月下载量达9700万次[2] - 恶意代码存在于版本号1.82.7和1.82.8中，目前已被撤回，PyPI隔离措施已解除[3][4] - 影响范围不仅限于LiteLLM本身，还包括所有以LiteLLM为基础依赖的其他项目和软件包[7] - 简单的`pip install litellm`即可导致SSH密钥、云服务凭证、API密钥、数据库密码等大量敏感信息被窃取[6] 攻击技术细节 - 攻击负载分为三个阶段运行：信息搜刮、数据外传、横向移动与持久化[9][10][17] - 信息搜刮阶段：脚本会搜刮主机中的SSH私钥、.env文件、云服务凭证、Kubernetes配置、数据库密码、git配置、shell历史记录、加密货币钱包文件等[9] - 数据外传阶段：收集的数据使用4096位RSA公钥和AES-256-CBC模式加密，通过POST请求发送至非官方的`models.litellm.cloud`域名[10] - 横向移动与持久化阶段：若存在Kubernetes服务账户令牌，会尝试读取集群机密并创建特权Pod；同时会在本地和宿主机文件系统植入持久化后门[17] 事件发现过程 - 恶意版本因攻击代码中的bug而被发现，该bug导致了一个指数级分叉炸弹，使机器因内存爆炸而崩溃[13][14] - 开发者Callum McMahon在Cursor内部运行的MCP插件将此包作为传递依赖项拉取时发现了此问题[14] - 有观点认为，如果攻击者编程能力更强，可能几周都不会有人注意到此次攻击[15] - 据称恶意代码的开发者采用了AI编码导致出现Bug，有开发者表示“vibe coding”在此次事件中起到了积极作用[16] 行业反应与专家观点 - 该事件引发了马斯克（Elon Musk）的关注，其用“Caveat emptor”提醒大家注意风险[12] - 英伟达机器人部门总监Jim Fan表达了关切，认为过去的身份盗窃与代理能做的事相比不值一提[18] - Jim Fan与Karpathy观点一致，认为人们很少需要LiteLLM支持的所有API，建议根据需求构建自定义功能软件[19] - Karpathy更倾向于在功能足够简单且可行的情况下，利用LLM把功能“薅”过来自己实现一遍[19] - Sebastian Raschka发现此次攻击与数年前的ctx包事件非常相似[21] 风险规避建议 - Sebastian Raschka提出的规避风险最佳路径包括：从可信源获取源代码快照、进行深度安全审计、将审计过的源代码直接整合进自己的库中[21] - 根据FutureSearch提示，建议开发者检查是否在2026年3月24日或之后安装或升级了LiteLLM至版本1.82.8[21] - 若受影响，需从所有环境中删除LiteLLM 1.82.8，并清理包管理器缓存[22] - 必须检查是否存在持久化痕迹文件，并假设受影响机器上的所有凭证都已泄露，立即轮换SSH密钥、云服务商凭证、API密钥、数据库密码等[22]