攻击者劫持AI工具链,LiteLLM沦为密钥提款机
在企业基础设施中，开发者工作站是最活跃的组成部分。这些笔记本电脑不仅是创建、测试、缓存、复制凭证的场所，更是跨服务、机器人、构建工具乃至本地AI Agent重复使用凭证的核心节点。
2026年3月，威胁组织TeamPCP通过针对LiteLLM（一个日下载量达数百万次的流行AI开发库）的供应链攻击，将开发者终端系统性地转化为凭证收集工具。恶意软件仅需访问磁盘上已有的明文密钥即可实施攻击。
LiteLLM攻击事件：
开发者终端沦陷的典型案例
此次攻击执行简单但影响深远。TeamPCP在PyPI上篡改了LiteLLM 1.82.7和1.82.8版本，植入信息窃取型恶意软件。当开发者安装或更新软件包时，该软件会系统性地收集SSH密钥、AWS/Azure/GCP云凭证、Docker配置等敏感数据。
PyPI在检测到问题后数小时内下架了恶意软件包，但危害窗口已然形成。GitGuardian分析显示，有1,705个PyPI软件包配置为自动拉取受感染的LiteLLM版本作为依赖项。这意味着即使从未直接使用LiteLLM的组织，也可能通过传递依赖链遭到入侵。
开发者终端为何成为诱人目标
这种攻击模式并非新事物，只是更具可见性。GitGuardian对6,943台遭入侵的开发者终端分析发现，每台设备平均存在33,185个独特密钥，其中3,760个仍有效。更惊人的是：59%的受感染系统是CI/CD运行器而非个人笔记本。
攻击者通过污染依赖项、恶意插件或更新包潜入工具链，随后系统性地收集.env文件、shell配置文件、终端历史记录、IDE设置、缓存令牌等位置的凭证数据。
明文凭证无处不在的现状
LiteLLM恶意软件得逞的关键在于开发者终端已成为明文凭证的密集存储点。这些凭证最终残留在源代码树、本地配置文件、调试输出、复制的终端命令、环境变量和临时脚本中。本应仅限本地使用的.env文件往往永久留存于代码库，便利性演变为安全隐患。
开发者运行的各种工具（本地MCP服务器、CLI工具、IDE扩展、构建管道等）都需要凭证，而这些凭证往往存储在恶意软件熟知的路径中，如~/.aws/credentials、~/.config/gh/config.yml等。
大规模保护开发者终端的策略
将工作站视为密钥扫描的主要环境。使用ggshield扫描本地代码库、项目工作区、dotfiles、构建输出以及本地AI工具生成的日志和缓存。不要忽视环境变量——shell配置文件和IDE设置常将环境值永久保存在磁盘上。
将凭证作为具有明确所有权、生命周期策略和自动化修复路径的托管身份进行管理。将其移至集中式保险库基础设施，安全团队可在此执行轮换计划、访问策略和使用监控。
Agentic工具能读取文件、执行命令和移动数据。切勿将凭证粘贴至Agent对话中，也不要教导Agent记住密钥”供后续使用”，并定期扫描Agent内存文件作为敏感数据存储。
采用WebAuthn（通行密钥）替代密码，在工作负载侧迁移至OIDC联盟，使管道不再依赖存储的云密钥和服务账户密钥。从高风险路径开始逐步扩展。
对于必须保留的密钥，应使其短期有效并自动更换。使用SPIFFE颁发自动轮换的加密身份文档（SVID）来替代静态API密钥。
在攻击者常扫描的位置（开发者主目录、常见配置路径等）放置诱饵凭证。当这些令牌被收集验证时，可立即触发警报，将检测时间从”数周后发现”缩短至”攻击进行时捕获”。
开发者终端已成为关键基础设施的一部分，位于权限、信任和执行的三重交汇点。LiteLLM事件证明，攻击者比多数安全方案更深刻理解这一点。只有将开发者终端纳入与生产系统同等级别的治理体系，企业才能在下一轮供应链攻击中立于不败之地。
参考来源：
How LiteLLM Turned Developer Machines Into Credential Vaults for Attackers
https://thehackernews.com/2026/04/how-litellm-turned-developer-machines.html
电报讨论
夜雨聆风
