文章核心观点 - 开源软件供应链攻击已成为AI开发领域的一项重大系统性风险，此次LiteLLM恶意代码投毒事件因其在生态中的关键地位而破坏力巨大，暴露了现代软件开发对第三方库“默认信任”机制的脆弱性 [4][9][20] - 此类攻击的防御是一场长期的不对称博弈，攻击成本低而收益高，防守方审计成本巨大，虽然无法被根治，但可通过沙箱隔离、权限收缩、运行时审计等“默认怀疑”的防御思路将风险压缩到可控范围 [19][21][22] LiteLLM供应链攻击事件概述 - LiteLLM的PyPI官方发布版本1.82.7和1.82.8被注入恶意代码，资深开发者和OpenAI联合创始人Andrej Karpathy均发出紧急警告 [4] - LiteLLM是大模型生态中的关键适配层，在GitHub上已获超4万颗星，月下载量高达9700万次，其核心价值在于将复杂的各家API统一为OpenAI标准格式，是连接开发者与上百个LLM的底层枢纽 [7][8] - 由于其处于处理API密钥的“咽喉要道”位置，一旦被投毒，破坏力呈指数级放大，可能窃取包括OpenAI密钥、AWS/Azure云端密钥、SSH访问权限、Kubernetes集群配置等在内的所有核心数字资产 [9] 攻击原理与发现过程 - 攻击起点是黑客通过凭证窃取或社交工程手段，非法获取了LiteLLM维护者的PyPI账号权限，从而直接在官方渠道发布恶意代码 [12] - 攻击者并未修改主要逻辑代码，而是利用Python环境中具有极高执行优先级的`.pth`文件机制，使得只要安装恶意版本，启动Python解释器运行任何程序，恶意代码就会被静默唤醒 [13] - 恶意代码将攻击指令隐藏在Base64编码字符串中以躲避监测，并会扫描宿主机中的环境变量和配置文件以窃取敏感信息 [13] - 该攻击在发布后不到一小时内即被社区发现，核心原因是攻击者编写的恶意代码存在严重的内存泄漏问题，导致使用者系统内存被吃满而宕机，从而暴露了攻击行为 [14][15] 事件影响与当前应对 - PyPI仓库中的污染版本v1.82.7和v1.82.8已被官方删除，从源头上阻断了恶意软件的进一步传播 [17] - 对于已安装恶意版本的环境，威胁依然存在，因为`.pth`文件实现了“静默启动”和“自我复制”，当前最紧要的操作是立即手动检查并回滚至安全的v1.82.6版本 [18] - 此类供应链投毒攻击未来很可能再度发生，因为攻击成本低而收益高，一行恶意代码混入高频依赖就可能影响成千上万的项目，而防守方需为每一层依赖付出审计成本，这是一场长期的不对称博弈 [19] 行业防御趋势与建议 - 像OpenClaw这样的新一代AI Agent框架已开始呈现多层防御思路，其最新版本引入了沙箱隔离、权限收缩和运行时审计等机制，例如将高风险操作限制在独立环境、屏蔽敏感环境变量、子代理运行在隔离沙箱内等 [21][22] - 行业实践正在快速演进，越来越多开发者开始默认开启沙箱模式、使用Docker做运行隔离、执行最小权限原则，并对API Key做定期轮换 [22] - 对开发者而言，需要将开发理念从“默认信任”切换为“默认怀疑”；对用户而言，应将选择权交给那些真正愿意为安全付出成本的平台，因为在当前阶段，决定风险下限的是安全而非功能 [22][23]

事件概述 - 开源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]