Ars Technica 报道：供应链攻击后 LiteLLM 凭据大规模泄露

Ars Technica 报道称，与 2,500 多家组织相关的凭据出现在通过遭入侵的 AI 软件包窃取的数据中。报道所披露的规模，使得 3 月的 LiteLLM 事件不再只是一次短暂的软件包故障，而可能演变为一场持续性凭据危机。

攻击者篡改了两个官方 LiteLLM 版本，并通过 Python Package Index（即 PyPI）进行分发。恶意代码会在受感染系统中搜索云密钥、代码仓库令牌、SSH 凭据、数据库密码以及 AI 服务使用的密钥。

攻击并非始于 LiteLLM。这是一次通过受信任的安全工具、开发者工作流和软件包发布账户逐步推进的行动。据报道，每一个遭攻破的环节都提供了凭据，帮助攻击者进入软件供应链的另一部分。

最新披露的数据更清晰、但仍不完整地呈现了事件余波。研究人员将数十万文件或流水线记录与 2,500 多家组织联系起来。不过，某个域名出现在被盗数据中，并不能证明每一家被列出的组织都遭遇了未经授权的访问。

这一差别很重要。已确认的软件包入侵发生在 2026 年 3 月，而研究人员在数月后才披露更广泛的数据集。安全团队现在必须判断：攻击期间收集的凭据是否仍然有效、是否已被滥用，或是否在攻击者使用前就已轮换。

Ars Technica 所称泄露数据揭示了什么

最新进展不是又一个遭投毒的软件包，而是表明最初入侵影响范围远超早期估计的证据。

根据这份凭据暴露报告，安全研究人员检查了一个归属于攻击者的大型数据集合。据报道，其中包含与 2,500 多家组织相关的密钥。

该集合包括云访问密钥、源代码仓库令牌、SSH 密钥、Kubernetes 密钥、环境变量、软件包发布凭据和 AI 提供商密钥。这些是可用于实际操作的凭据，而不只是从公开目录收集来的账户名称。

泄露的云密钥可能授予对托管基础设施的访问权限。代码仓库令牌可能泄露私有源代码，或允许未经授权的修改。软件包发布凭据可能让攻击者以受信任项目的名义分发恶意软件。

Kubernetes 密钥则构成另一条路径。Kubernetes 是用于管理容器化应用的系统，其服务账户可能拥有广泛的基础设施权限。权限过大的被盗令牌，可帮助攻击者从单个工作负载横向进入整个集群。

研究人员还将这些数据与约 434,000 条持续集成与交付记录关联起来。CI/CD 流水线会自动执行软件测试、构建和部署，并且常常会暂时将凭据加载到内存中。

这个数字不应被解读为 434,000 起已确认的入侵事件。一个组织可能运行许多任务、运行器、代码仓库和重复的流水线执行。跨多个攻击阶段窃取的数据中，重复记录也会抬高统计数字。

据报道，该数据集关联的文件集合规模约为 195 TB。若将每一个字节都描述为独立凭据，将具有误导性。此类集合可能除密钥外，还包括重复的系统文件、源代码树、日志、归档文件和内存捕获内容。

更站得住脚的结论关乎覆盖范围，而非凭据数量。攻击者似乎从众多存有高价值凭据的开发环境中收集了数据。材料规模也增加了验证和通知受害者的难度。

CloudSEK 创建了一项可搜索的暴露查询服务，让组织检查其域名是否出现在已分析材料中。匹配结果应触发调查，但并非攻击者进入该组织网络的确凿证据。

同样地，如果某个组织安装过受影响的软件包，没有匹配结果也不应令人安心。数据集可能并不完整，域名可能未出现在机器生成的痕迹中，而攻击者的基础设施也可能在记录受害者之前失效。

因此，这篇报道提升了事件的紧迫性，但并未解答所有问题。组织需要结合本地安装记录、网络遥测、云审计日志和凭据历史，才能确定自身的实际暴露情况。

一个受信任的 AI 软件包成了投递机制

LiteLLM 之所以一旦遭入侵便格外危险，是因为它通常运行在攻击者最想窃取的凭据旁边。

LiteLLM 为调用不同大语言模型服务的应用提供了通用接口。开发者无需维护多套独立集成，而是可以通过一个代理或 Python 库路由请求。

这种便利性使 LiteLLM 靠近 OpenAI、Anthropic、云托管模型及其他提供商的 API 密钥。生产部署还可能访问数据库、可观测性平台、云存储和内部服务。

攻击者于 2026 年 3 月 24 日向真实的 PyPI 项目发布了恶意 LiteLLM 版本 1.82.7 和 1.82.8。这些并非拼写相似的仿冒软件包，而是经由用户本已信任的分发渠道到达。

Wiz 报告称，这些版本大约在 8:30 UTC 出现，而 PyPI 在 11:25 UTC 隔离了该项目。其恶意软件包分析还发现，在 Wiz 观察到的云环境中，36% 使用了 LiteLLM。

版本 1.82.7 会在软件导入 LiteLLM 代理代码或启动代理时激活载荷。版本 1.82.8 则新增了一个名为 litellm_init.pth 的 Python 启动文件。

Python 会在初始化 site-package 环境时处理 .pth 文件。因此，即便应用在该会话中从未导入 LiteLLM，恶意代码也可能在 Python 每次启动时运行。

这一机制颠覆了人们对依赖项暴露的常见假设。开发者不一定需要执行一个明显已遭入侵的命令；仅安装该版本，就可能在环境中植入自动执行钩子。

随后，恶意软件会搜索内存、环境变量、配置目录、Shell 历史记录和常见凭据位置。它会在将收集到的材料发送至仿冒 LiteLLM 合法域名的攻击者控制基础设施前对其加密。

据报道，数据目标包括 AWS、Google Cloud 和 Microsoft Azure 凭据。该窃密程序还会搜索 Kubernetes 令牌、Docker 配置、数据库密码、加密货币钱包、私钥和 CI/CD 密钥。

Datadog 的活动调查建议，将任何安装过受影响版本的系统都视为发生了全面凭据暴露。这一立场基于恶意软件的收集行为，而非证明每一项发现的密钥都已到达攻击者手中。

LiteLLM 维护者表示，受影响版本已被移除，维护者凭据也已轮换。他们还表示，代理 Docker 镜像用户未受影响，因为其依赖项已固定版本。

维护者聘请了 Mandiant，并在审查代码仓库和构建系统期间暂停发布。他们的公开回应将此次发布环节的入侵与此前 Trivy 事件中暴露的凭据联系起来。

这些遏制措施减少了新的感染，但无法收回已传输的数据，也无法自动使每一项被盗凭据失效。因此，修复工作必须远远超出卸载软件包的范围。

真正的对手：受信任的自动化与有限访问权限

这起事件让自动化软件交付的速度，与“任何依赖项都不应继承不受限制凭据”这一安全原则正面相撞。

现代构建流水线会从许多外部项目拉取代码、工具、容器和操作。自动化让发布变得可重复，但每个依赖项也会成为组织实际安全边界的一部分。

Trivy 展示了这一问题。它是一款用于发现容器和软件制品漏洞的安全扫描器。团队往往会给予扫描器广泛的可见性，因为检查工作需要访问源代码、镜像仓库和构建输出。

3 月 19 日，攻击者入侵了 Trivy 的部分发布和 GitHub Actions 生态系统。Datadog 报告称，恶意组件抓取了 GitHub 托管运行器的内存，并搜索常见的凭据位置。

随后，攻击者似乎在其他项目和软件包系统中复用了被盗访问权限。在恶意 LiteLLM 版本出现在 PyPI 前，这场行动已波及与 Checkmarx 相关的操作和扩展。

这一过程颠倒了通常的安全模型。原本用于检测不安全软件的扫描器，反而成为上游访问来源，帮助攻击者攻破另一个被广泛使用的软件包。

这场行动还表明，软件包已签名或带有官方名称，并不能解决信任问题。真实的注册表位置只能确认制品来自何处，不能保证发布者账户或构建流水线始终安全。

自动升级加剧了这种矛盾。团队常常允许补丁版本快速流转，因为他们预期小版本号包含兼容性修复。攻击者正是通过合法项目发布恶意版本，利用了这一预期。

固定版本可以减缓这一攻击路径，但并非完整防线。团队仍可能主动批准一个已被投毒的版本，尤其当它的注册表身份和发布版本号看起来都很正常时。

加密哈希验证能提供更强的控制，因为它会核验制品本身。然而，必须有人在安装前确定哪个哈希值得信任。若从同一已遭攻破的渠道复制恶意哈希，只会延续这场攻击。

私有软件包镜像可在外部制品进入生产环境前增加审核与延迟。它们也会新增一项敏感服务，必须受到保护、监控并保持更新。

更深层的控制措施是凭据隔离。构建任务中运行的依赖项，应只获得完成该项特定任务所需的权限。短期凭据应在被盗副本产生长期访问价值之前过期。

工作负载身份会用与任务或服务绑定的临时凭据替代静态密钥。这种方法降低了从遭入侵运行器中收集到的文件和环境变量的价值。

组织还需要分离构建阶段。扫描任务通常不需要发布软件包、管理云账户、访问生产数据库，或修改无关代码仓库的权限。

许多流水线仍为方便起见而合并这些权限。当一个进程可以访问所有部署服务时，一个被投毒的依赖项就可能将一次软件更新转化为覆盖全组织的身份安全事件。

LiteLLM 攻击并未创造这一弱点。它揭示了当 AI 中间件位于应用、模型提供商、云、数据库和可观测性系统之间时，这一弱点会如何急剧放大。

为什么仅卸载 LiteLLM 还不够

移除恶意软件包只阻断了一条执行路径，却无法撤销该代码活跃期间被复制的机密信息。

凭证窃取带来的应对问题不同于普通恶意软件清理。重建机器可以消除后门，但攻击者仍可能持有能从另一套系统使用的有效密钥。

每个受影响环境都需要进行凭证盘点。安全团队必须识别暴露期间存在于内存、文件、环境变量、Shell 历史记录以及已挂载服务账户目录中的机密信息。

轮换范围应包括云访问密钥、AI 提供商密钥、数据库密码、代码仓库令牌、SSH 密钥、Kubernetes 服务账户、软件包注册表凭证、Webhook 密钥和签名材料。

操作顺序至关重要。团队应先限制可疑访问、保全证据并创建替代身份。随后可在使已暴露凭证失效前更新依赖服务，避免造成失控的服务中断。

云审计日志可显示被盗密钥是否曾从异常地点被使用。代码仓库历史则可能显示异常克隆、令牌创建、工作流变更、发布活动或权限修改。

软件包维护者还肩负额外责任。若受感染运行器中存在发布令牌，则应审查该令牌可访问的每一个软件包。攻击者可能会等待一段时间后再利用访问权限。

.pth 持久化技术也意味着团队应直接检查 Python 环境。卸载 LiteLLM 未必会删除 site-packages 中独立创建的启动文件。

公开的事件时间线建议检查 litellm_init.pth，并轮换受影响系统中存在的所有凭证。该时间线还指出了攻击者控制的 models.litellm.cloud 端点。

防御人员应在网络日志中搜索与已知命令控制基础设施的连接。他们还应检查进程记录、异常的 Python 启动、归档文件创建以及意外出现的高权限 Kubernetes Pod。

不过，数月时间的流逝会造成可见性缺口。较短的保留周期可能会在延迟调查开始前清除端点和网络记录。

这正是当前所报告的数据泄露为何重要。3 月时未发现明显入侵迹象的组织，如果其域名出现在恢复的材料中，可能会获得新的调查线索。

不过，调查人员不应将研究人员的查询工具视为最终权威。域名匹配可能来自公开配置、克隆的源代码、供应商引用或客户名单。

反过来的错误同样危险。企业不应仅因无法立即证明数据被外传，就忽视一项匹配。凭证日志、安装记录和依赖项锁定文件可以提供更有力的证据。

团队还应检查间接安装情况。开发者可能不记得主动选择过 LiteLLM，因为其他框架、内部工具或测试环境引入了该软件包。

软件物料清单有助于追踪这些关系。物料清单会记录应用程序或构建产物中包含的组件及其版本。

然而，即使是完整的组件清单，也无法揭示执行期间哪些凭证可见。依赖证据必须与运行时身份和访问记录结合起来。

对于需要保留调查笔记、凭证时间线和修复决策的开发者而言，一个可搜索的技术知识库可以减少证据碎片化。敏感机密本身绝不应被复制到通用笔记中。

这些数字无法证明什么

报告的规模令人震惊，但现有证据并不能证明发生了 2,500 起已完成的网络入侵，或泄露了 195 TB 的独有凭证。

Ars Technica 将这一新的规模归因于安全研究人员的分析。底层软件包遭入侵一事，得到多项独立技术调查和 LiteLLM 维护者回应的支持。

之后的受害者数量取决于研究人员如何将被盗工件映射到组织。公开报道目前尚未提供足够细节，无法复现每一项匹配，也无法区分客户、供应商、开发者和被引用的第三方。

企业域名出现在源代码中，并不能证明该代码来自域名所有者的系统。测试夹具、电子邮件地址、依赖元数据和文档都可能包含外部名称。

研究人员可以通过多种信号加强归因，包括内部主机名、私有代码仓库路径、云账户标识符、组织专属令牌、运行器名称以及匹配的时间戳。

即便如此，“受影响”仍可能描述多种情形。一个组织可能执行过恶意软件，另一个可能暴露过已撤销的密钥，第三个则可能仅出现在被复制的文档中。

434,000 这一数字同样需要语境。如果它代表文件、记录或流水线执行次数，就不应被表述为同等数量的独立受损流水线。

所报告的 195 TB 数据收集量也应谨慎看待。原始窃取归档可能包含重复目录、大型二进制文件、模型文件、缓存、源代码仓库和日志。

将全部 195 TB 称作“凭证”，会把这些区别压缩成一个戏剧性的标题。凭证占用空间很小，而围绕它们的环境可能极为庞大。

即使不夸大措辞，实际风险依然严重。一个包含有效云管理员密钥的小型文本文件，可能比数 TB 不敏感构建工件更加重要。

被点名的组织也需要得到公平对待。出现在暴露数据集中，并不能证明其存在疏忽、持续遭受入侵，或其生产系统发生了数据失窃。

部分被列出的组织可能已在最初响应期间轮换凭证。另一些组织的名称或域名，可能出现在供应商环境中，而非其自身环境内。

攻击者是否持有并使用该数据集，是另一个问题。据报道，研究人员获得或分析了与该活动相关的材料，但公开证据并未显示每一项凭证被利用到了何种程度。

凭证的有效性会随时间变化。临时令牌可能在数分钟内过期，而旧 SSH 密钥和静态 API 凭证则可能在数月甚至数年内仍然有效。

最具后果的不确定性涉及长期有效的机密。若受影响组织只轮换了显而易见的 AI 密钥，攻击者仍可能通过被遗忘的部署令牌或服务账户保留访问权限。

因此，这次披露应被视为一条由已确认恶意软件事件支持的调查线索。它不应成为对数据集中每一个域名作出的最终泄露裁定。

这种平衡的表述避免了两种失败：既防止被夸大的受害者数量超越证据，也防止不确定性成为不采取行动的借口。

三个信号将显示危机是否得到控制

下一阶段取决于凭证轮换、经独立验证的受害者发现，以及软件包发布安全方面可衡量的改进。

第一个信号，是在 3 月遏制窗口之后是否存在凭证滥用的证据。云服务提供商、软件包注册表和受影响组织应披露，被盗身份是否促成了后续访问。

若确认休眠的发布令牌曾被使用，将强化该活动造成长期供应链威胁的判断。若未观察到使用迹象，则可降低即时担忧，但前提是审计覆盖充分。

第二个信号，是对暴露数据集的独立验证。更多组织应将研究人员的匹配结果与安装日志、云标识符和网络遥测数据进行比对。

一致的确认将支持所报告的规模。广泛存在的误匹配或重复记录，则会缩小估计影响范围，但不会改变 LiteLLM 已确认遭入侵这一事实。

第三个信号，是更安全的发布与运行时控制措施的采用。PyPI 的可信发布模型使用短期身份令牌，而不是可重复使用的上传凭证。

更广泛的供应链审查建议采用可信发布、工件哈希验证、受限服务账户，并监控意外出现的 Python 启动文件。该文档指出，AI 中间件是下游凭证的集中点。

开发者不应等待一份完美的受害者名单。任何安装过 LiteLLM 1.82.7 或 1.82.8 的人，都应将该环境视为已暴露，并确认所有可访问的凭证均已更换。

安全团队还应审查自 3 月 19 日起与 Trivy 相关的暴露情况。该活动的攻击链早于恶意 LiteLLM 版本出现，若只关注一个软件包，可能会遗漏上游入侵。

未发现受影响版本的组织仍应检查其依赖策略。下一个被投毒的软件包未必会使用 LiteLLM、Python 或相同的持久化机制。

Ars Technica 报道的核心教训，比其庞大数字所暗示的更为狭窄，也更具可操作性。受信任的自动化将高价值身份置于第三方代码旁，而一条被攻破的链条横跨了许多系统。

今天就提出一个具体问题：哪个外部软件包能够读取你最具权限的构建凭证？如果答案不明确，请在下一次例行更新将隐藏的信任变成事故之前，先梳理这类访问权限。