Todos los artículos

Noticias8 de octubre de 20265 min de lectura

Nvidia DCGM Exporter: DoS sin autenticación (CVE-2026-47483)

CVE-2026-47483 (CVSS 8.2) en Nvidia DCGM Exporter: peticiones sin autenticación a /debug/pprof/ tumban la monitorización de GPU. Actualiza a la 4.8.2.

Operador de espaldas frente a dos monitores en una sala de control, con grandes pantallas de monitorización en la pared del fondo

Una vulnerabilidad de gravedad alta en Nvidia DCGM Exporter, el servicio que publica las métricas de las GPU para sistemas de monitorización como Prometheus, permite a quien alcance el servicio, sin autenticación, agotar su memoria y hacerlo caer. El fallo se identifica como CVE-2026-47483, con una puntuación CVSS 8.2, y está corregido en la versión 4.8.2. Lo descubrieron y comunicaron a Nvidia los investigadores de Lava, una startup dedicada a la seguridad de los centros de datos; han informado sobre él The Register (8 de octubre de 2026), Help Net Security y CSO Online (9 de octubre de 2026).

Además del fallo, la investigación de Lava muestra hasta qué punto están expuestos en Internet los servicios de monitorización de las infraestructuras de inteligencia artificial.

Qué ha pasado

Según el investigador de Lava Michael Katchinskiy, citado por los tres medios, cuatro escaneos de Internet realizados entre marzo y mayo de 2026 encontraron unos 2.100 servidores GPU que exponían las métricas de DCGM Exporter, con más de 12.000 GPU distintas y un valor estimado del hardware de unos 100 millones de dólares. Ninguno exigía autenticación y todos respondían por HTTP en claro. Entre las tarjetas expuestas había Blackwell Ultra B300, H200 y H100, usadas para grandes cargas de IA, pero también tarjetas de consumo RTX 5090 y 4090.

Los hosts pertenecían a unas 300 organizaciones. Estados Unidos albergaba 5.274 de las GPU expuestas (44 %); según Help Net Security, le siguen Rumanía con 2.054 y China con 1.967. Algunos servicios expuestos funcionaban en infraestructuras de clientes de proveedores de GPU en la nube: los medios citan Voltage Park, Lambda, Northern Data y DigitalOcean, y The Register también Nebius. Según Help Net Security, Voltage Park confirmó que todas las instancias de DCGM Exporter expuestas las habían instalado los clientes y avisó a los afectados.

Las fuentes no coinciden en la fecha de la corrección: The Register escribe que Nvidia la publicó en septiembre, Help Net Security indica un boletín de seguridad de Nvidia del 28 de julio de 2026 y CSO Online habla de mayo. Ninguna de las tres informa de explotación activa.

Detalles técnicos

DCGM Exporter lee de las GPU del host temperatura, uso, memoria, consumo y errores, y los publica por HTTP, normalmente en el puerto 9400 (según Help Net Security), en la ruta /metrics. Las métricas incluyen el modelo exacto y el UUID de cada GPU.

El problema está en los endpoints de perfilado de Go /debug/pprof/, expuestos junto a /metrics por cerca de una cuarta parte de los hosts encontrados. Algunos de estos endpoints mantienen abierta la petición durante el tiempo que elige quien la envía: con muchas peticiones concurrentes sin autenticar, el consumo de memoria crece hasta que el exporter cae. Según CSO Online, el boletín de Nvidia clasifica el fallo como consumo descontrolado de recursos (CWE-400).

Según Help Net Security, Lava pensó al principio en un error de configuración de los operadores, pero reprodujo el comportamiento con el contenedor oficial de DCGM Exporter sin modificar: una instalación que expone el exporter en una interfaz enrutable puede, por tanto, exponer también /debug/pprof/.

Las consecuencias descritas:

  • pérdida de visibilidad sobre el estado y la actividad de las GPU, porque la monitorización se detiene;
  • presión sobre la CPU y la RAM del host, que puede ralentizar los procesos de entrenamiento o inferencia que se ejecutan en la misma máquina, sobre todo sin límites estrictos de recursos;
  • reconocimiento: incluso sin el fallo, las métricas revelan qué hardware usa una organización, cuánto lo usa y si tiene errores.

Lava examinó también Prometheus Node Exporter: 12.096 hosts públicos exponían datos de los adaptadores InfiniBand y RoCE de Nvidia/Mellanox (modelos, firmware, estado de los enlaces) y en algunos casos nombres de host, versiones del sistema operativo y del kernel y datos de la BIOS. Donde coincidían los dos exporters, según Katchinskiy se podía relacionar la actividad de las GPU con el servidor, su software y la red que lo rodea.

En términos de MITRE ATT&CK, agotar la memoria del exporter corresponde a T1499 (Endpoint Denial of Service), mientras que la recogida de las métricas expuestas entra en T1592 (Gather Victim Host Information). Las fuentes no publican indicadores de compromiso.

Impacto para las empresas europeas e italianas

El dato de Rumanía, segundo país por GPU expuestas, muestra que el problema no afecta solo a Estados Unidos. Quien usa GPU en sus instalaciones o en la nube para IA, cálculo científico o procesamiento de imágenes, incluidas universidades, centros de investigación y organizaciones sanitarias, debería comprobar qué expone su pila de monitorización. Para las entidades sujetas a NIS2, la gestión de vulnerabilidades y la protección de los sistemas de monitorización forman parte de las medidas de seguridad exigidas. Como recuerda Katchinskiy, en la nube también importa saber qué es responsabilidad del proveedor y qué del cliente: en los casos citados, los exporters los habían instalado los clientes.

Qué hacer ya

  1. Actualiza DCGM Exporter a la versión 4.8.2 o posterior, como indica el boletín de Nvidia.
  2. Comprueba que la opción --enable-pprof esté desactivada si no necesitas el perfilado. Según Help Net Security, en las versiones actuales es opcional; según CSO Online, en las versiones sin corregir puede estar activada por defecto.
  3. Saca de la red pública DCGM Exporter, Node Exporter y Prometheus: vincula los exporters a la interfaz de loopback o a una red privada y limita el acceso a tus sistemas de monitorización con reglas de firewall o security groups. Protege del mismo modo las API de consulta y las páginas de targets de Prometheus.
  4. Comprueba desde fuera si el puerto 9400 y las rutas /metrics y /debug/pprof/ de tus hosts responden desde Internet.
  5. Fija límites de CPU y memoria al contenedor del exporter, para que un fallo suyo no quite recursos a las cargas de trabajo.
  6. Vigila la propia monitorización: un exporter que deja de responder debe tratarse como un evento que hay que verificar, no solo como una avería.

Cómo ayuda ARXDOME

ARX Expose muestra lo que un atacante ve desde fuera: puertos abiertos, productos reconocidos y vulnerabilidades conocidas en los servicios públicos, útil para encontrar exporters expuestos por error. ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, y ARX Sentry recoge de los servidores logs e inventario de software, procesos y puertos, para saber dónde se ejecuta DCGM Exporter y en qué versión.

Última actualización:

¿Tienes preguntas?

Hablemos de las necesidades de tu empresa, sin compromiso.

Contáctanos

Artículos relacionados