LiteLLM 40万星项目遭劫持：50万台设备被植入木马

一个被40万开发者星标（Star）的Python工具，在48小时内变成了大规模数据收割机。攻击者没有破解你的服务器，只是在你每天调用的代码里塞了一行后门。

这就是3月下旬发生的LiteLLM供应链攻击事件。这个轻量级API中间件本是AI开发者的"瑞士军刀"——用统一接口调用OpenAI、Anthropic、Gemini等十几家大模型，省去重复封装代码的麻烦。它的GitHub仓库积累超过4万星标，3万次代码提交，PyPI（Python包索引）下载量以百万计。

攻击者自称"TeamPCP"，手段并不新鲜：先攻破Aqua Security的Trivy漏洞扫描工具账户，再顺藤摸瓜拿到LiteLLM的发布权限。他们推送了两个看似正常的版本更新：1.82.7和1.82.8。安全公司Endor Labs的分析显示，恶意代码藏在初始化脚本里，触发后会执行三阶段攻击：收割凭证（SSH密钥、云令牌、Kubernetes密钥、加密钱包、.env文件）、尝试横向移动、建立持久化后门。

50万次下载，多少开发者浑然不觉

具体感染规模难以精确统计，但多方信源指向一个数字：约50万台设备可能已执行过这两个恶意版本。BleepingComputer的追踪报道指出，这是继Aqua Security Docker镜像、Checkmarx KICS项目之后，同一批攻击者的第三次得手。

供应链攻击的可怕之处在于"信任转嫁"。开发者检查过LiteLLM的代码质量、社区活跃度、维护者背景，唯独没料到官方发布渠道本身会叛变。一位安全研究员在社交媒体上的吐槽被大量转发："我每天用pip install更新几十个包，怎么可能逐个审代码？"

攻击者显然吃准了这种心理。他们甚至给木马起了个颇具讽刺意味的名字："TeamPCP Cloud Stealer"——直译就是"云窃贼"，仿佛生怕受害者事后复盘时找不到责任人。

AI infra工具的"阿喀琉斯之踵"

LiteLLM的架构设计放大了这次事件的杀伤力。作为模型调用的中间层，它需要访问用户的API密钥、云服务商凭证、甚至Kubernetes集群权限才能正常工作。这些恰恰是攻击者的目标清单。

换句话说，这是一个"权限过度集中"的经典案例。开发者为了简化多模型切换，把钥匙串交给了管家，而管家被人冒充了。

Endor Labs的详细技术报告指出，恶意载荷会优先搜寻.env文件和云服务商的默认凭证路径。对部署在AWS、GCP、Azure上的AI应用来说，这意味着单点突破可能演变为整个云环境的沦陷。部分受害者反馈，攻击者甚至尝试利用窃取的Kubernetes服务账户令牌，在集群内部横向移动。

项目维护团队在发现异常后紧急回滚，并强制 deprecate（弃用）了这两个版本。但PyPI的包管理机制意味着，已经缓存到本地镜像或冻结在requirements.txt里的恶意版本，仍可能持续传播。

修复之后，更大的麻烦才开始

技术层面的清理相对直接：升级至1.82.9及以上版本，轮换所有可能暴露的密钥，审计近期云资源访问日志。但供应链信任的重建要困难得多。

LiteLLM并非孤例。同一时期，Checkmarx还披露了针对Nvidia、Salesforce等主流AI/ML工具链的类似攻击。攻击者正在系统性地瞄准"基础设施层"——那些开发者默认信任、却很少亲自审计的依赖项。

一个值得注意的细节：TeamPCP的命名风格与此前多起供应链攻击高度相似，但尚未有安全公司能确认其真实身份或地理位置。这种"匿名化+品牌化"的操作模式，让归因和追责变得几乎不可能。

对25-40岁的技术从业者来说，这次事件敲响了特定警钟。你们可能是第一批把AI模型集成到生产环境的人，习惯用开源工具快速搭建原型，对"pip install + API key"的便捷性习以为常。但便捷性的反面是攻击面的膨胀——每一个被信任的依赖项，都是潜在的特洛伊木马。

项目维护者在事后公告中承认，发布流程的权限管理存在漏洞，正在引入多因素认证和代码签名机制。但这些改进无法追回已经泄露的凭证。部分企业安全团队开始要求：所有PyPI包的首次引入必须经过静态分析和沙箱测试，无论其社区声誉如何。

50万台设备的数字可能最终被证明高估或低估，但它揭示了一个确定的趋势：AI基础设施正在成为网络犯罪的高价值目标。不是因为这里的防御更薄弱，而是因为这里的权限更集中、数据更敏感、恢复成本更高。

你现在还会直接pip install一个上周刚更新的包吗？