2026年3月25日，Python AI网关库 LiteLLM 被曝在 PyPI 上遭遇供应链攻击，攻击者通过投毒官方发布包，在安装阶段悄然窃取开发者本地环境中的敏感信息。一个原本被视作“安全基础设施”的依赖，转瞬变成攻击入口。根据律动与 TechFlow 的统计，LiteLLM 月下载量约 9700 万次，且被包括 dspy 在内的主流 AI 项目直接依赖，这让一次看似“单点”的仓库事件，被放大为覆盖全球 AI 开发链路的系统性风险。这起攻击不仅击中了 Python 生态的技术薄弱点，更直指开源供应链“默认信任”的核心矛盾：当绝大多数团队将关键依赖视作理所当然、自动更新时，一次源头被攻破，足以撕开整个行业的信任裂缝。
AI网关成流量入口也成安全雷区
LiteLLM 本质上是一个 Python 生态中的 AI 网关库，为开发者提供统一接口来接入不同厂商的大模型 API，从 OpenAI 到各类新兴模型服务，都可以通过它在一处聚合、路由和管理。对许多团队而言，LiteLLM 是上层应用与底层模型服务之间的“总闸门”，写一次集成代码，就能在后端灵活切换提供方，这也是它迅速进入主流 AI 项目技术栈、被 dspy 等项目直接依赖 的原因。
正因为承担了“流量入口”的角色，LiteLLM 的下载量被推上了极高的台阶。研究简报显示，其 月下载量约 9700 万次，这意味着在全球范围内，每天都有海量开发环境、CI/CD 流水线、云原生服务在自动拉取并安装这个包。它已经不只是一个普通工具库，而是嵌入到各类 AI 应用、推理服务和内部平台的底层基础设施之中，一旦出了问题，其影响面很难被简单评估。
在这样的依赖度下，任何对 LiteLLM 发布流程的攻击，都会产生明显的 级联安全风险。攻击者不需要逐个突破企业网络边界，只要拿下一个高下载量、被广泛信任的开源库，就有机会同步打开放在数以万计服务器、开发机、云账户里的“后门”。从应用逻辑到云基础设施，再到企业内部权限体系，一个被投毒的 AI 网关，足以成为横向移动的中枢。LiteLLM 事件，把这种长期被低估的系统性风险，第一次以高频依赖库被攻破的方式，赤裸呈现在 AI 行业面前。
PyPI账号被劫持后恶意版本登场
根据公开信息，本次事件的起点是 LiteLLM 维护者在 PyPI 的账号 krrishdholakia 被劫持，攻击者由此取得了在官方仓库上发布新版本的权限。也就是说，表面上这些恶意版本依然来自“官方账号”，在大多数自动化工具和开发者眼中，并没有任何显而易见的异常提示。我们无法获知账号被攻陷的精确时间和具体技术手段，相关时间戳与细节尚未公开，但可以确认的是，供应链攻击的突破口，就落在了这一单点账号失守上。
在取得发布权限后，攻击者向 PyPI 推送了被植入恶意代码的 LiteLLM 版本。据当前公开的单一来源信息显示，1.82.7 与 1.82.8 被点名为受污染的恶意版本，这一指认本身仍需更多渠道交叉验证，因此在时间线与范围上，应被视作“待进一步确认”的线索，而非已经盖棺定论的最终清单。尽管如此，这两个版本已经足以触发开发者社区的高度警觉——它们被标记为潜在攻击载体，要求立即排查与卸载。
在事件被安全团队与社区成员识别并披露后，PyPI 官方已将相关恶意版本下架，阻断了进一步通过官方渠道传播的路径。从顺序上看，大致可以还原为：维护者账号被劫持 → 恶意版本被上传并在一段时间内正常分发 → 安全研究者与项目社区发现异常并发出预警 → PyPI 采取下架处置并同步信息。由于精确上传和传播时长仍处于待验证状态，现阶段能确认的是：攻击在一定时间里确实以“官方更新”的形式存在于 PyPI 生态中，而不是一场被提前扼杀在沙箱中的实验。
一行pth脚本窃走SSH与云密钥
从技术路径看，攻击者并没有选择复杂晦涩的内核漏洞，而是利用了 Python 生态中一个常见机制：在包安装时，通过特定文件实现 解释器启动阶段的自动执行。公开信息显示，恶意代码隐藏在名为 litellm_init.pth 的文件中。`.pth` 文件本应用于在 Python 启动时扩展 `sys.path` 或执行少量初始化逻辑，但一旦被恶意利用，就能在用户无感知的情况下，于解释器每次启动时自动运行任意脚本逻辑。
据律动与 TechFlow 报道，该恶意脚本在被执行后，会尝试收集并外传多类高敏感度信息，包括但不限于：SSH 密钥、云服务访问凭据、Kubernetes 配置文件等。这些数据不仅直接关联到服务器与容器集群的控制权限，也往往牵连到企业内部的生产环境、测试环境以及自动化运维体系。一旦被窃取并落入攻击者手中，就相当于将大量“万能钥匙”拱手相送，为后续长期潜伏、资产窃取乃至勒索攻击打开大门。
从开发者的日常使用场景出发，这种攻击路径的危险在于：大多数人只会把 `pip install litellm` 视作一次普通的依赖安装动作，不会联想到它可能在本地环境中部署了一个隐形监听器。对于连接公司 Git 仓库和生产服务器的工程师，只要在被污染的环境里日常使用 SSH 登录，密钥就有可能被连带打包走。对于在本地或 CI 环境中配置云凭据、Kubernetes kubeconfig 的团队，恶意脚本一旦扫描到相关配置文件，攻击面就会迅速从一台开发机扩散到整片云基础设施。简而言之，一次看似“无害”的依赖更新，足以在背后撬动大规模横向移动的序幕。
维护者自曝被攻破与安全团队预警
事件爆出后，LiteLLM 维护团队在 GitHub 上给出了直白的回应，其中一句 “We have been pwned by this” 被大量引用。对一个月下载量近亿次的基础库来说，这种表述不仅是对攻击事实的承认，也折射出项目方自身面对供应链攻击时的震惊与无力感：维护者能控制的是自己的代码仓库，却未能守住发布账号这一关键“闸门”，而账号一旦失守，原本被视作“官方更新”的信任链就瞬间崩塌。
安全社区也迅速给出可操作的自查建议。慢雾科技 CISO 23pds 建议用户先通过 `pip show litellm` 检查本地已安装的 LiteLLM 版本号，并与公开的恶意版本信息进行比对；若发现处于疑似污染版本区间，应立即卸载并更换为安全版本或临时锁定在已知安全的历史版本。这种基于命令行的简单核查路径，至少为大量开发者提供了一个第一时间自救的工具，以缩短从“听说事件”到“确认自身风险状态”之间的信息鸿沟。
在更广泛的社区讨论中，LiteLLM 事件被普遍视为 PyPI 供应链风险的一个警钟。安全团队、开源维护者与企业侧工程师开始重新审视：我们究竟在多大程度上，把对 PyPI 的信任，等同于对每一个包、每一次更新的无条件背书？当账号安全、发布管控与多重验证机制长期处于“能用即可”的状态时，一次成功的劫持不仅是对单个项目的打击，更是对整个开源生态信任模型的一次压力测试。
从单点账号失守到整条开源链条暴露
从这次事件往上追溯，技术突破口虽然是 PyPI 维护者账号被劫持，但真正暴露出来的，是开源包管理平台在“守门机制”上的结构性薄弱。账号安全策略是否强制启用多因素认证？发布流程是否引入独立签名验证与异常检测？对于高下载量项目，平台是否有更严格的额外审计层？这些本该在“基础设施”层面被不断加固的问题，在 LiteLLM 事件之前，很少被当作紧迫任务；而当攻击已经发生，人们才发现整个链路在账号权限这一单点上过度集中。
一旦像 LiteLLM 这种 高下载量依赖库的信任被打破，冲击就会沿着开发与运维链路迅速扩散。上层的 AI 应用会担心自身推理服务是否已经被植入后门，云基础设施团队要评估 SSH 和云凭据是否外泄，安全部门则需要重新划定企业内部的信任边界：哪些环境可以继续运行？哪些机器必须下线核查？在大模型被快速接入各类关键业务的当下，一个 AI 网关库被投毒，带来的不仅是代码层面的修复任务，而是贯穿从业务应用到基础设施再到合规审计的系统性连锁反应。
恶意版本之所以能在短时间内广泛传播，又难以及时被发现，很大程度上源于现代开发流程的 高度自动化 与 供应链监控的缺位。大量项目依赖自动化工具每天、甚至每次构建时自动更新依赖，只要版本号满足约束，就会被无条件拉取；而对依赖本身的完整性校验、行为分析与异常监控，则往往被忽略。结果就是：一旦“官方账号”释出恶意版本，它可以顺着 CI 流水线与包管理脚本，在没有任何人工干预的情况下，迅速潜入成千上万的环境。LiteLLM 事件揭示的，并不仅是某个项目的悲剧，而是整个开源供应链在自动化时代所面临的，共同结构性风险。
下一次供应链黑天鹅何时到来
归纳 LiteLLM 事件，矛盾的核心在于：开源供应链安全的系统复杂性，与开发者对其“默认安全”的盲目信任之间，存在根本性的结构错位。在现实工程实践中，团队习惯于以下载量、GitHub 星标数、社区口碑来衡量一个项目的可靠性，却很少去质疑：维护者账号会不会被攻破？发布链路中有没有额外校验？PyPI 或其他平台是否具备足够的攻击检测能力？当这些问题长期被压抑在意识之外，供应链攻击就变成一只随时可能降临的黑天鹅。
要降低类似事件的冲击强度，生态各方都难以置身事外。对 包管理平台 而言，更强的账号认证（如强制 2FA、多重签名）、敏感操作审计、对高影响力项目的差异化安全策略，已经不再是“可选项”；对 项目维护团队 而言，需要审视并加固自己的发布流程，引入构建产物签名、可验证构建（reproducible build）以及发布前的安全审计，而不是仅凭“我信任自己这台开发机”来维护全网信任链。
站在 加密与 Web3 的视角，LiteLLM 事件也为未来的基础设施设计提供了方向感：借助链上透明追踪机制，对关键依赖版本、构建哈希与发布者身份进行不可篡改的记录，可以在事后快速溯源“谁在什么时候发布了什么”；通过去中心化信誉体系与多方独立安全审计工具，让单一维护者或单一平台不再成为决定性信任源，而是置于一个可监督、可验证的网络之中。供应链攻击不会因此消失，但每一次投毒都将更早暴露、影响范围更可控、恢复路径更清晰。
对于已经深度依赖开源的软件产业来说，问题不再是“是否会有下一次供应链黑天鹅”，而是“我们是否在它到来之前，已经构建好足够弹性的信任与防御体系”。LiteLLM 只是一个开端，也是一次难得的集体反思窗口。
加入我们的社区，一起来讨论，一起变得更强吧！
官方电报（Telegram）社群：https://t.me/aicoincn
AiCoin中文推特：https://x.com/AiCoinzh
OKX 福利群：https://aicoin.com/link/chat?cid=l61eM4owQ
币安福利群：https://aicoin.com/link/chat?cid=ynr7d1P6Z
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
