Lava 发现数千台暴露的 GPU 服务器和一个高危 NVIDIA 监控漏洞

AI 模型背后的基础设施在任何人入侵之前就可能泄露大量信息。公共监控端点可能会披露服务器中的 GPU、它们的利用率以及相关软件。同一监控服务中的缺陷可能会将可见性转化为可用性风险。

Lava 于 10 月 8 日发布的新研究描述了这两个问题。该安全公司识别出约 2,100 台公开可访问的 NVIDIA DCGM Exporter 主机，这些主机在未认证的情况下报告了超过 12,000 块独立 GPU。在调查期间，Lava 还发现了一项高危漏洞，可能让未认证的攻击者耗尽资源并导致 GPU 监控崩溃。

NVIDIA 已为该问题分配了 CVE-2026-47483，评级为 8.2，高，并发布了更新。此发现将 AI 基础设施中不那么光鲜的部分置于聚光灯下：用于观察高价值计算的服务本身也需要保护。

研究人员发现了什么——以及这些数字的意义

Lava 的 Michael Katchinskiy 的原始研究 描述了 2026 年 3 月至 5 月期间进行的四次扫描。因此，这些总数代表了该研究期间的观察结果，而不是今天仍然暴露的系统的实时计数。

这些主机在未认证的情况下返回 GPU 遥测数据。Lava 观察到的数据中心加速器包括 H100、H200 和 Blackwell Ultra B300，以及 RTX 4090 和 5090 系统。公司估计，观察到的 GPU 硬件价值超过 1 亿美元，基于大致的市场估值。该数字描述的是硬件价值，而非攻击造成的损失。

约四分之一的暴露 DCGM 主机还开放了内部 Go 分析端点。该子集很重要：暴露的指标端点和可访问的易受攻击的分析接口是相关但不同的发现。将所有 12,000 多块 GPU 都描述为该漏洞的确认受害者是误导性的。

Lava 表示，他们在受控环境中复现了资源耗尽，而非攻击公开部署。该研究展示了一条潜在的攻击路径；但并未证明受影响的组织遭受了利用，也未表明其模型数据被窃取。

为什么 GPU 监控揭示的信息不仅仅是状态灯

DCGM 代表数据中心 GPU 管理器。NVIDIA 的 DCGM Exporter 文档 说明，导出器会收集选定的 GPU 遥测字段，并以 Prometheus 可消费的格式提供。其指标端点通常被监控系统用于跟踪 GPU 节点的状态和活动。

温度、利用率、内存使用、功耗和错误事件对运维人员有用，因为它们描述了计算的运行情况。当这些信息对陌生人可见时，就会成为资产清单和侦察来源。

暴露的响应可以揭示硬件型号和运营细节。重复的读取可以提供关于繁忙时段和周期性活动的线索。这些线索并不能证明某个特定模型正在被训练或提供服务，但它们可以帮助外部人员缩小对环境中包含哪些资源以及何时活跃的判断范围。

这一区别值得保留。读取 GPU 遥测并不等同于读取模型的权重、训练数据或提示。然而，基础设施信息仍然有价值：了解存在哪些组件和版本的攻击者，比面对一个不透明服务器的人拥有更具体的起点。

漏洞针对监控服务

NVIDIA 的安全公告 将缺陷定位于 DCGM Exporter 的 /debug/pprof 端点。并发的未认证分析请求可能导致不可控的资源消耗，进而可能导致拒绝服务和信息泄露。该通告将此报告归功于 Lava 的 Michael Katchinskiy。

分析是一项合法的诊断功能。它帮助开发者调查应用内部的 CPU 和内存行为。当潜在耗资源的内部函数在没有适当控制的情况下被不受信任的调用者访问时，就会出现安全问题。

根据 Lava 的说法，研究人员最初怀疑是运营商配置错误，随后使用 NVIDIA 官方容器复现了该行为。他们证明资源耗尽可能导致导出器崩溃，从而失去对 GPU 健康状态的可视化。CPU 和内存压力也可能影响共享同一服务器的训练或推理工作负载。

导出器崩溃并不一定会停止 GPU 工作负载本身。直接影响是监控丢失；对相邻工作负载的干扰取决于资源隔离和部署方式。这是一种围绕 GPU 基础设施的软件服务漏洞，而非 GPU 硅片缺陷的证据。

这一区别在运营层面至关重要。如果在工作负载减速期间监控消失，响应人员需要调查观察系统本身是否出现故障。将每一个缺失的指标都视为仪表不便可能会延迟对资源消耗事件的识别。

暴露范围超出 GPU 层

Lava 的公告还描述了 12,096 台公开可访问的 Node Exporter 主机。Node Exporter 报告服务器和操作系统信息，而不是承担与 DCGM Exporter 相同的角色。公开的数据包括硬件和软件细节，可能帮助外部人员了解围绕 GPU 工作负载的系统。

这些计数应保持分离。Node Exporter 的观察属于更广泛的基础设施暴露发现，而不是另一组已确认受 CVE-2026-47483 影响的主机计数。将两者合并会掩盖每个数字所对应的服务和风险。

更广泛的含义是，AI 安全必须涵盖监控和管理层。模型访问控制并不能自动保护部署在模型旁边的指标服务。组织可以保护其推理 API，却让同一基础设施上的另一服务对互联网开放。

修补和限制访问解决不同的问题

安全更新已发布。NVIDIA 的公告将 DCGM Exporter 4.8.2 标识为更新版本，并同时列出 DCGM 4.5.3。运营者应查阅当前的安全通告以及其部署所支持的版本配对，而不是将这两个组件的版本号视为可互换。

升级可以修复已披露的缺陷，但本身并不意味着指标端点已得到适当限制。如果已打补丁的导出器仍然公开可达且缺乏访问控制，仍可能泄露遥测数据。

Prometheus security model明确警告不要在没有适当措施的情况下将组件的 HTTP 端点暴露到公共网络。其指南涵盖度量、API 和 Go 分析接口，并认识到这些服务可能会被过载。

对于审查其 AI 基础设施的团队，这提示了一个实用的顺序：

• 清点已部署的监控服务。确定正在运行的导出器、Prometheus 服务器和诊断接口，它们的所有者以及如何访问它们。
• 应用供应商的安全更新。检查实际部署的软件或容器版本，而不仅仅是尚未发布的配置文件。
• 限制监控访问。使用私有网络以及适当的防火墙、安全组和访问控制，使遥测数据可供需要它的监控基础设施使用。
• Review profiling requirements. Lava recommends leaving --enable-pprof 除非明确需要分析，否则禁用；在当前版本中，它是可选的。
• 在修复后验证可见性。确认授权的收集仍然有效，并且能够注意到意外的导出器故障。

这些步骤分别针对以下问题：软件是否包含缺陷、是否有不受信任的方可以访问以及监控故障是否会被检测到。解决其中一项并不等同于解决其他所有问题。

AI 基础设施需要明确的安全负责人

GPU 容量通常跨越供应商运营的基础设施和客户部署的服务。一次有效的安全审查应明确谁维护每个组件、谁控制网络暴露以及在公共端点被报告时由谁响应。缺乏这些分工，监控服务可能位于两个团队之间，而每个团队都期待对方来保障其安全。

Lava 研究的核心教训是实用的：保护 AI 计算必须同时保护用于测量和管理的系统。新发现记录了显著的历史暴露，而 NVIDIA 的通告则提供了针对已披露漏洞的修复路径。对于运营者而言，首要任务是核实当前部署、应用修复，并将内部观察服务保持在预期的信任边界内。