Lava descubre miles de servidores GPU expuestos y una vulnerabilidad de monitoreo de NVIDIA de alta gravedad

La infraestructura detrás de un modelo de IA puede revelar una cantidad sorprendente antes de que alguien lo vulnera. Un punto final de monitoreo público puede divulgar las GPU en un servidor, su utilización y el software que las rodea. Una falla en ese mismo servicio de monitoreo puede convertir la visibilidad en un riesgo de disponibilidad.

Una nueva investigación de Lava, publicada el 8 de octubre, describe ambos problemas. La empresa de seguridad identificó aproximadamente 2 100 hosts del NVIDIA DCGM Exporter accesibles públicamente que reportaban más de 12 000 GPU únicas sin autenticación. Durante su investigación, Lava también descubrió una vulnerabilidad de alta gravedad que podría permitir a un atacante no autenticado agotar recursos y provocar el bloqueo del monitoreo de GPU.

NVIDIA ha asignado el problema CVE-2026-47483, lo ha calificado como 8.2, Alta y ha publicado una actualización. Los hallazgos ponen en el foco una parte menos glamorosa de la infraestructura de IA: los servicios utilizados para observar el costoso cómputo necesitan protección propia.

Qué encontraron los investigadores — y qué significan los números

La investigación original de Michael Katchinskiy de Lava describe cuatro escaneos realizados entre marzo y mayo de 2026. Por lo tanto, los totales representan observaciones durante ese período de investigación, en lugar de un recuento en tiempo real de los sistemas que siguen expuestos hoy.

Los hosts devolvían telemetría de GPU sin autenticación. Lava observó aceleradores de centros de datos, incluidos H100, H200 y Blackwell Ultra B300, así como sistemas RTX 4090 y 5090. La empresa estimó que las GPU observadas representaban más de 100 millones de dólares en hardware, basándose en valores de mercado aproximados. Esa cifra describe el valor del hardware, no las pérdidas derivadas de un ataque.

Alrededor de una cuarta parte de los hosts DCGM expuestos también dejaron accesibles los puntos finales internos de perfilado Go. Este subconjunto es importante: un punto final de métricas expuesto y una interfaz de perfilado vulnerable accesible son hallazgos relacionados pero distintos. Sería engañoso describir a todas las más de 12 000 GPU como víctimas confirmadas de esta vulnerabilidad.

Lava afirma que reprodujo el agotamiento de recursos en un entorno controlado, en lugar de atacar las implementaciones públicas. La investigación muestra una ruta de ataque potencial; no establece que las organizaciones observadas hayan sufrido explotación o que se haya robado sus datos de modelo.

Por qué el monitoreo de GPU revela más que una luz de estado

DCGM significa Data Center GPU Manager. La documentación del DCGM Exporter de NVIDIA explica que el exportador recopila campos de telemetría de GPU seleccionados y los sirve en un formato que Prometheus puede consumir. Su punto final de métricas suele ser utilizado por los sistemas de monitoreo para seguir el estado y la actividad de los nodos GPU.

La temperatura, la utilización, el uso de memoria, el consumo de energía y los eventos de error son útiles para los operadores porque describen cómo se está comportando el cómputo. Cuando la misma información es accesible a extraños, se convierte en una fuente de inventario y reconocimiento.

Las respuestas expuestas pueden revelar modelos de hardware y detalles operativos. Lecturas repetidas pueden proporcionar pistas sobre períodos de alta actividad y actividad recurrente. Esas pistas no son prueba de que un modelo en particular esté siendo entrenado o servido, pero pueden ayudar a un externo a delimitar qué contiene un entorno y cuándo está activo.

Esa distinción vale la pena preservar. Leer la telemetría de GPU no es lo mismo que leer los pesos, los datos de entrenamiento o los prompts de un modelo. Sin embargo, la información de infraestructura aún puede ser valiosa: un atacante que descubre qué componentes y versiones están presentes tiene un punto de partida más específico que alguien que se enfrenta a un servidor opaco.

La vulnerabilidad apunta al servicio de monitoreo

boletín de seguridad de NVIDIA localiza la falla en el Exporter de DCGM /debug/pprof puntos finales. Las solicitudes concurrentes de perfilado no autenticadas pueden provocar un consumo descontrolado de recursos, con posible denegación de servicio y divulgación de información. El aviso reconoce a Michael Katchinskiy de Lava por reportarla.

El perfilado es una capacidad de diagnóstico legítima. Ayuda a los desarrolladores a investigar el comportamiento de CPU y memoria dentro de una aplicación. El problema de seguridad surge cuando una función interna potencialmente costosa se vuelve accesible a un llamador no confiable sin los controles adecuados.

Según Lava, los investigadores inicialmente sospecharon un error de configuración del operador, y luego reprodujeron el comportamiento con el contenedor oficial de NVIDIA. Demostraron que el agotamiento de recursos podría bloquear el exportador, eliminando la visibilidad de la salud de la GPU. La presión de CPU y memoria también podría afectar a las cargas de trabajo de entrenamiento o inferencia que comparten el servidor.

Bloquear un exportador no detiene necesariamente la carga de trabajo de la GPU en sí. El efecto inmediato es la pérdida del monitoreo; la interferencia con cargas de trabajo vecinas depende del aislamiento de recursos y de la implementación. Se trata de una vulnerabilidad del servicio de software en la infraestructura de GPU, más que de una evidencia de un defecto en el silicio de la GPU.

La distinción importa operativamente. Si el monitoreo desaparece durante una desaceleración de la carga de trabajo, los respondedores deben investigar si el propio sistema de observación está fallando. Tratar cada métrica ausente como una simple incomodidad de instrumentación podría retrasar el reconocimiento de un incidente de consumo de recursos.

La exposición se extiende más allá de la capa GPU

El anuncio de Lava también describe 12 096 hosts de Node Exporter accesibles públicamente. Node Exporter informa información del servidor y del sistema operativo en lugar de desempeñar el mismo papel que DCGM Exporter. Los datos expuestos incluían detalles de hardware y software que podrían ayudar a terceros a comprender los sistemas que rodean las cargas de trabajo de GPU.

Esos recuentos deben mantenerse separados. Las observaciones de Node Exporter son un hallazgo de exposición de infraestructura más amplio, no otro recuento de hosts confirmados vulnerables al CVE‑2026‑47483. Combinar las cifras oscurecería qué servicio y qué riesgo representa cada número.

La implicación más amplia es que la seguridad de IA debe incluir la capa de monitoreo y gestión. Los controles de acceso al modelo no protegen automáticamente un servicio de métricas desplegado junto al modelo. Una organización puede asegurar su API de inferencia mientras deja otro servicio en la misma infraestructura abierto a Internet.

Aplicar parches y restringir el acceso abordan problemas diferentes

La actualización de seguridad ya está disponible. El boletín de NVIDIA identifica DCGM Exporter 4.8.2 como una versión actualizada y también enumera DCGM 4.5.3. Los operadores deben consultar el aviso actual y el emparejamiento de versiones admitidas para su despliegue en lugar de tratar esos dos números de versión de componentes como intercambiables.

Actualizar soluciona la vulnerabilidad divulgada. No establece, por sí mismo, que el punto final de métricas esté restringido adecuadamente. Un exportador parcheado aún puede divulgar telemetría si sigue siendo accesible públicamente sin controles de acceso.

El Prometheus security model advierte explícitamente contra exponer los puntos finales HTTP de componentes a redes públicas sin medidas apropiadas. Su guía cubre métricas, API e interfaces de perfilado Go, y reconoce la posibilidad de sobrecargar estos servicios.

Para los equipos que revisan su infraestructura de IA, eso sugiere una secuencia práctica:

• Inventariar los servicios de monitoreo desplegados. Determinar qué exportadores, servidores Prometheus e interfaces de diagnóstico están en funcionamiento, quién los posee y cómo se accede a ellos.
• Aplicar las actualizaciones de seguridad del proveedor. Verificar la versión real del software o contenedor desplegado, no solo un archivo de configuración que aún no se haya implementado.
• Limitar el acceso al monitoreo. Utilizar redes privadas y firewalls, grupos de seguridad y controles de acceso adecuados para que la telemetría esté disponible solo para la infraestructura de monitoreo que la necesita.
• Revisar los requisitos de perfilado. Lava recomienda dejar --enable-pprof desactivado a menos que el perfilado sea explícitamente necesario; en las versiones actuales, es opt‑in.
• Verificar la visibilidad después de la remediación. Confirmar que la recolección autorizada sigue funcionando y que se detecten fallas inesperadas del exportador.

Estos pasos abordan preguntas distintas: si el software contiene la vulnerabilidad, si una parte no confiable puede alcanzarlo y si una falla de monitoreo será detectada. Resolver una no resuelve las demás.

La infraestructura de IA necesita un propietario de seguridad explícito

La capacidad de GPU a menudo abarca infraestructura operada por el proveedor y servicios desplegados por el cliente. Una revisión de seguridad útil identifica quién mantiene cada componente, quién controla la exposición de red y quién responde cuando se informa de un punto final público. Sin esas asignaciones, un servicio de monitoreo puede quedar entre dos equipos que esperan que el otro lo asegure.

La lección central de la investigación de Lava es práctica: proteger el cómputo de IA incluye proteger los sistemas que lo miden y gestionan. Los nuevos hallazgos documentan una exposición histórica significativa, mientras que el aviso de NVIDIA ofrece una ruta de remediación para la vulnerabilidad divulgada. Para los operadores, la prioridad es verificar su despliegue actual, aplicar la corrección y mantener los servicios de observación internos dentro de su límite de confianza previsto.