2026 年 3 月 24 日，AI 开发者们还在敲代码，PyPI 上的 LiteLLM 悄然被“下毒”。月下载量高达 9700 万次的 Python 开源库 LiteLLM，其 PyPI 仓库在凌晨被恶意篡改，两个受污染版本（1.82.7、1.82.8）悄然上线。短短三小时内，数万个开发环境和企业系统可能暴露在数据泄露风险中。与普通攻击不同，这次事件不是孤立的恶意注入，而是黑客组织 TeamPCP 精心策划的连锁攻击。
慢雾(SlowMist) 自主研发的 Web3 威胁情报与动态安全监控工具 MistEye 也在第一时间给相关客户推送了相关威胁情报预警。
此次 LiteLLM 攻击的源头，并非库本身存在漏洞，而是其 CI/CD 流水线中使用的开源安全扫描器 Trivy 早已被攻破。回溯攻击时间线：3月19日，TeamPCP 篡改了 Trivy 的 GitHub Action 标签，植入恶意代码；3月23日，攻击者入侵 Checkmarx KICS 安全扫描工具，为下一步攻击铺路；3月24日，LiteLLM 的 CI/CD 流水线运行受污染的 Trivy 时，PyPI 发布令牌被窃取，攻击者借此绕过正常发布流程，将两个恶意版本直接推向 PyPI，完成对 AI 核心依赖库的“投毒”。
这场攻击的曝光颇具戏剧性——攻击者原本打算悄无声息潜伏，没想到自己在编写恶意代码时出现了疏漏——1.82.8 版本中植入的 litellm_init.pth 文件，会在每次 Python 进程启动时自动执行，并通过子进程反复触发自身，直接导致 FutureSearch 工程师的测试机器内存耗尽、崩溃。正是这个意外的漏洞，让这场本可能潜伏数天甚至数周的攻击提前暴露，否则后果不堪设想。
TeamPCP 为 LiteLLM 设计的恶意代码，采用了分阶段执行的策略，隐蔽性强、破坏范围广，且具备持久化和横向扩散能力，远超普通供应链攻击的危害程度。第一阶段为信息收集，恶意脚本会系统性扫描受感染主机的所有敏感数据，涵盖范围极广：从开发者的 SSH 私钥、Git 配置、shell 历史记录，到企业的云服务商(AWS/GCP/Azure) 凭证、Kubernetes 配置、数据库密码，甚至包括加密货币钱包文件、助记词等。值得注意的是，LiteLLM 作为统一调用各类大模型 API 的网关，常存储多个模型提供商的密钥，一旦被攻破，相当于直接向攻击者敞开了企业 AI 基础设施的大门。
第二阶段为加密泄露，收集到的所有数据会通过 AES-256-CBC 算法加密，搭配 4096 位 RSA 公钥保护会话密钥，打包成 tar 归档文件后，发送至攻击者控制的虚假域名 models.litellm.cloud——该域名注册于攻击前一天，与 LiteLLM 官方基础设施毫无关联，极具迷惑性。据披露，攻击者已通过此次攻击窃取约 300GB 压缩凭证，涉及 50 万个敏感凭据。
第三阶段为持久化与横向移动，这也是此次攻击最危险的后遗症来源。在本地机器上，恶意代码会在用户目录下创建后门脚本 sysmon.py，并通过 systemd 服务实现自启动，即便卸载 LiteLLM，后门仍可能持续运行；若检测到 Kubernetes 环境，攻击者会利用服务账户令牌，在集群所有节点部署特权 Pod，实现全网扩散，将单一主机的感染转化为整个集群的安全危机。攻击者还试图通过恶意机器人刷屏、盗用维护者账号关闭 GitHub issue 等方式掩盖攻击痕迹。
目前，PyPI 已撤回受感染版本，隔离区也已解除，LiteLLM 维护者正在处理后续事宜，但这场攻击留下的后遗症远未消除。首先是持久化后门的清理难题，部分用户可能仅卸载 LiteLLM 就认为风险解除，却不知后门仍在后台收集数据；其次是凭证泄露的连锁反应，50 万个被窃凭证可能形成“多米诺骨牌效应”；最后是依赖链的扩散风险，LiteLLM 被 DSPy、MLflow、Open Interpreter 等 2000 多个包引用，许多开发者因使用其他工具间接引入了恶意版本。
LiteLLM 攻击不禁让人联想到 Trust Wallet 安全事件。而此次 LiteLLM 攻击中，加密货币钱包文件、助记词同样被纳入窃取范围，且攻击者具备长期潜伏和横向扩散能力。事实上，TeamPCP 组织此前曾公开嘲讽安全厂商“连自己的供应链都保护不了”，并宣称计划长期窃取商业机密，此次 LiteLLM 攻击只是其系统性入侵开源生态的一个环节。
面对此次攻击及其后遗症，无论是个人开发者还是企业，都需立即采取行动：1. 立即排查感染情况，若为 1.82.7 或 1.82.8 版本需立即卸载并清除缓存；2. 全面轮换敏感凭证，包括 SSH 密钥、云服务商凭证、数据库密码、API 密钥，尤其是加密货币钱包的私钥、助记词；3. 规范依赖管理，锁定 LiteLLM 至 1.82.6 及以下安全版本，同时加强 CI/CD 流水线安全。
LiteLLM 供应链攻击不仅揭示了开源生态的脆弱，也提醒我们：在 AI 高速发展的今天，核心依赖库的安全直接关系到整个生态稳定。唯有正视供应链安全，及时排查隐患、完善防护体系，才能避免类似的重大损失，守护自身的数据和资产安全。
[慢雾科技]
LiteLLM供应链攻击：加密基础设施安全性的警钟
最近的LiteLLM供应链攻击代表了开源史上最复杂、影响最深远的安全漏洞之一，对加密货币和区块链生态系统具有特别令人担忧的影响。虽然最初看起来像是标准软件供应链的妥协，但这一事件揭示了一个多阶段攻击，明确针对加密钱包凭据和API密钥，在整个数字资产领域创造了系统性风险。
攻击机制与加密特定威胁
TeamPCP对LiteLLM的攻击不仅仅是机会主义的，而是战略性地针对高价值数字资产。该攻击破坏了一个拥有每月9700万下载量的库——基本上毒害了无数AI和机器学习应用的关键依赖项。对于加密投资者来说，这一事件特别令人担忧的是，攻击者明确专注于加密钱包文件、助记词和各种LLM提供商的API密钥。
三阶段执行策略展示了复杂的威胁情报：收集涵盖SSH密钥、云凭据和加密钱包的信息；使用强大的加密(AES-256-CBC与4096位RSA)进行加密数据传输；以及确保在初始漏洞被发现后仍能保持持续访问的持久机制。对于加密项目和持有者来说，这意味着攻击者可能不仅获得了钱包凭据，还获得了开发环境访问权限，这可能导致多个项目的私钥泄露。
市场影响与代币影响
鉴于攻击的近期性，其直接的市场影响可能尚未完全显现。然而，经验丰富的投资者应为几种潜在场景做好准备：
首先，我们预计其开发团队或基础设施可能受到影响的项目代币将增加波动性。50多万个被盗凭据创造了二次攻击向量，可能表现为钱包清空攻击、交易所账户被入侵或针对受影响实体的复杂钓鱼活动。
其次，这一事件突显了即使是成熟的基础设施也可能存在脆弱性，可能加速向替代性去中心化解决方案的转变。强调去中心化开发环境、安全密钥管理解决方案和可验证构建过程的项目可能会获得更多投资者关注和资本流入。
加密投资者的战略风险
对于加密投资者而言，LiteLLM攻击引入了几个需要立即关注的关键风险：
-
对手风险：使用LiteLLM或其依赖项的项目或交易所可能其凭据已遭泄露，可能影响其安全态势并增加资产被盗的风险。
-
开发基础设施泄露：许多加密开发团队依赖类似的CI/CD流水线和依赖管理系统。这次攻击可能只是针对加密基础设施的更广泛活动中的一个向量。
-
供应链级联效应：LiteLLM被超过2,000个包引用，包括DSPy、MLflow和Open Interpreter，其连锁反应可能影响到通过其依赖项间接受影响的大量加密项目和协议。
-
长期潜伏威胁：TeamPCP展示的长期持久能力表明，他们可能在被入侵的系统内保持休眠状态，在市场条件对其目标最有利的战略时机执行后续攻击。
危机中的投资机会
虽然攻击带来了显著风险，但也为那些认识到安全格局不断变化的投资者创造了引人注目的机会：
-
安全基础设施项目：专注于去中心化身份、多方计算(MPC)钱包和可验证软件供应链的解决方案可能会随着行业应对这些威胁而看到需求增加。
-
审计和验证服务：强调强大安全审计、依赖扫描和持续验证的加密项目将获得竞争优势，可能为提供这些服务的组织带来代币升值。
-
去中心化开发平台：集中式开发环境和包仓库的局限性可能推动采用提供更高透明度和安全保证的去中心化替代方案。
-
事件响应和取证：随着组织争先恐后地评估其暴露程度，区块链取证和事件响应服务提供商可能会面临需求增长，在专业安全代币中创造投资机会。
加密投资者的防御策略
经验丰富的投资者应采取立即的防御措施：
-
评估暴露风险：审查所有可能使用LiteLLM或其依赖项的开发环境、系统和工具。即使是通过其他包的间接使用也会创造潜在漏洞。
-
凭据轮换：立即轮换所有敏感凭据，特别是与加密钱包、交易所和开发环境相关的凭据。考虑使用硬件安全模块或物理隔离系统进行密钥管理。
-
依赖项审计：将所有依赖项固定到安全版本并实施更严格的依赖项管理实践。考虑为关键包使用去中心化验证机制。
-
基础设施加固：审查CI/CD流水线和开发基础设施以查找类似漏洞。为所有第三方工具和服务实施更严格的验证程序。
LiteLLM攻击是一个严峻的提醒，在我们日益互联的数字生态系统中，安全性只与其最薄弱的环节一样强大。对于加密投资者而言，这一事件既凸显了复杂供应链攻击带来的重大风险，也凸显了为我们当前依赖的脆弱集中式基础设施构建更强大、更去中心化替代方案的新兴机会。