Una explicación de una vulnerabilidad en GPUStack (un gestor de código abierto que ejecuta modelos de IA en clústeres de GPU y aprovisiona instancias de GPU) que permite a partes sin autenticar actuar como administrador. Cubre qué ocurre, quién está afectado y cómo responder, desde el lado de la defensa y sin pasos de ataque.
- CVE
- CVE-2026-102895 (aviso de GitHub GHSA-gj9m-f8ph-pmhr)
- Gravedad
- CVSS v3.1 9.8 (crítica). El mismo valor en el aviso, el registro CVE y NVD
- Tipo
- Autenticación incorrecta (CWE-287). El aviso también enumera la elusión de autenticación por suplantación (CWE-290) y el error de validación de origen (CWE-346)
- Condiciones previas
- Sin autenticar; basta con tener acceso de red a GPUStack. Según el aviso, los ajustes por defecto están afectados
- Afectado
- pip gpustack anterior a 2.2.0
- Corrección
- gpustack 2.2.0
- Fechas
- Aviso: 31 de julio de 2026 / registro CVE: 4 de noviembre de 2026
- Explotación
- Explotación en la práctica informada en el aviso. Añadido a CISA KEV el 9 de noviembre de 2026 (plazo: 12 de noviembre)
El riesgo de esperar
Según el aviso, una parte sin autenticar puede cambiar usuarios, modelos y ajustes de workers, y crear claves de API de administrador que funcionan desde cualquier dirección de origen. Pueden leerse las credenciales de workers y de proveedores de nube, y combinado con la funcionalidad exclusiva de administrador esto lleva a la ejecución de código en los hosts de los workers. El aviso dice que se observó explotación en la práctica. CISA marca el triaje forense como necesario para esta entrada de KEV.
Qué es la vulnerabilidad
Con los ajustes por defecto (force_auth_localhost es false), GPUStack trata una petición procedente de la misma máquina (loopback) como el administrador integrado. Está pensado para ahorrar autenticación en el uso local. El problema es que lo que decide «es la misma máquina» puede influirse desde fuera.
Según el aviso hay dos caminos hacia el administrador sin autenticación. El primero es un proxy inverso en el mismo host: cuando el proxy reenvía a GPUStack, incluso las peticiones externas parecen a GPUStack venir de loopback. Es una disposición autoalojada habitual y no necesita cabecera ni credencial. El segundo es una cabecera de reenvío de peticiones; el aviso dice que un valor aportado por el cliente puede hacer que una petición parezca loopback. Este sitio no describe cómo explotarlo.
Antes (anterior a la 2.2.0)
- Un origen loopback se convierte en administrador sin autenticación
- Detrás de un proxy inverso en el mismo host, el tráfico externo parece loopback
- Una cabecera de reenvío puede falsear el origen
Cambios después (2.2.0)
- Se elimina el camino que trata loopback como administrador
- Se refuerza el tratamiento de la IP del cliente y de las cabeceras de reenvío
- Una cabecera de IP real del cliente solo se acepta de una pasarela autenticada y de confianza
Alcance
| Elemento | Detalle |
|---|---|
| Producto | GPUStack (gestor de código abierto de clústeres de GPU) |
| Paquete afectado | pip gpustack |
| Versiones afectadas | Anteriores a la 2.2.0 (aviso y registro CVE) |
| Versión corregida | 2.2.0 |
| Daño real | Aviso: explotación en la práctica observada contra la v2.1.1 |
| Qué puede ocurrir | Todas las acciones de administrador (cambiar usuarios, modelos, workers), crear claves de API de administrador, leer credenciales de workers y de proveedores de nube, ejecución de código en los workers (según el aviso y KEV) |
- Según el aviso, los ajustes por defecto están afectados.
- El aviso enumera solo el paquete pip gpustack. Si lo instaló de otra forma, como una imagen de contenedor, consulte la información de su proveedor sobre la versión.
Cómo comprobar si está afectado
Compruebe la versión de GPUStack
Compruebe la versión de gpustack instalada. Cualquiera anterior a la 2.2.0 está afectada. Si tiene entornos de producción, preproducción y desarrollo, compruebe cada uno (lista de comprobación del inventario de activos).
Compruebe si es accesible desde fuera
Compruebe si el puerto de GPUStack, o el proxy inverso que tiene delante, es accesible desde rangos no confiables como internet. Según el aviso, el fallo funciona a través de un proxy inverso en el mismo host, así que estar detrás de un proxy no es prueba de seguridad.
Compruebe el ajuste force_auth_localhost
Compruebe si force_auth_localhost está en true. Según el aviso, el valor por defecto es false, lo que deja abierto el camino vulnerable.
Qué hacer hoy
Actualice a la 2.2.0 (máxima prioridad)
Actualice gpustack a la 2.2.0 o posterior. El plazo de KEV es el 12 de noviembre de 2026.
Hasta entonces, reduzca la entrada
Las soluciones provisionales del aviso son las siguientes. Ninguna sustituye a la actualización.
- Ponga force_auth_localhost en true para que las peticiones loopback también necesiten autenticación.
- Asegúrese de que el proxy inverso o la pasarela no puedan hacer que el tráfico externo parezca loopback, y elimine en el borde cualquier cabecera X-GPUStack-Real-IP aportada por el cliente.
- Mantenga la API fuera de redes no confiables, detrás de una VPN o de una autenticación en el borde.
Tras actualizar, audite las claves de API de administrador
Según el aviso, una clave de API de administrador creada funciona después desde cualquier dirección de origen. Actualizar no la elimina, así que haga una lista de las claves de API existentes y elimine las de las que no reconozca al creador o la hora de creación. Mire sobre todo las claves creadas antes de la actualización.
Revoque y reemita las credenciales
El aviso dice que pueden leerse las credenciales de workers y los secretos de proveedores de nube. Revoque y reemita lo que registró en GPUStack: datos de conexión de workers, claves de proveedores de nube, tokens de descarga de modelos y similares. Como añadido de este sitio, reemítalos aunque no encuentre rastro de abuso. Consulte La guía de corrección de vulnerabilidades y Conceptos básicos de seguridad: .env y claves de API.
Revise los ajustes y los workers
Busque backends personalizados, usuarios y ajustes de modelos que no reconozca. En los workers, busque procesos y conexiones salientes que no reconozca. Como la explotación está confirmada, trate cualquier configuración que no reconozca como una posible señal de compromiso. Si encuentra algo sospechoso, aísle ese worker y considere reconstruirlo.
Estado de la explotación
- El aviso afirma que se observó explotación en la práctica contra un despliegue v2.1.1. La explotación se atribuye a un informante externo.
- CISA lo añadió a KEV (el catálogo de vulnerabilidades con explotación confirmada; versión 2026.11.09) el 9 de noviembre de 2026, con un plazo del 12 de noviembre. El uso en campañas de ransomware figura como desconocido, y el triaje forense como necesario.
- El registro de NVD tiene el estado Analyzed. El CVSS v3.1 es 9.8, igual que el aviso y el registro CVE.
- El aviso atribuye el descubrimiento a varios informantes que comunicaron la vulnerabilidad de forma independiente.
La visión de este sitio: no deje nada sin autenticar por ser interno o estar detrás de un proxy
Esto es menos un descuido de código que una suposición de diseño errónea. «Una petición de mi propia máquina soy yo» se derrumba en cuanto se pone un proxy inverso delante. Un proxy inverso en el mismo host es además una forma muy extendida de añadir HTTPS y publicar un servicio, de modo que una configuración que parece protegida se convierte en la entrada.
La consola de administración de una plataforma de IA reúne en un solo lugar el entorno de ejecución de modelos, los recursos de GPU y las credenciales de la nube. Si acepta peticiones sin autenticar, el daño no se queda en una máquina; se extiende hacia fuera por las credenciales de la nube. Proteja las consolas y las API de administración con autenticación, no con la ubicación ni la dirección de origen. La misma clase de problema aparece cuando un diseño confía en las cabeceras de reenvío (suplantación de XFF y proxies de confianza). Tras actualizar, el trabajo no ha terminado hasta que haya limpiado las claves de API que se crearon y las credenciales que pudieron leerse.
Fuentes
- GPUStack — GHSA-gj9m-f8ph-pmhr: Authentication bypass via trusted loopback source (publicado el 31 de julio de 2026; versiones afectadas, corrección, soluciones provisionales, informe de explotación)
- CVE.org — CVE-2026-102895 (publicado el 4 de noviembre de 2026; anteriores a 2.2.0, CVSS 9.8)
- NVD — CVE-2026-102895 (estado Analyzed)
- CISA KEV — Known Exploited Vulnerabilities Catalog (añadido el 9 de noviembre de 2026, plazo el 12 de noviembre)
Última verificación: 10 de noviembre de 2026.
Lee a continuación
- Práctica: La guía de corrección de vulnerabilidades / Lista de comprobación del inventario de activos
- Decidir: Priorizar con CVSS, EPSS y KEV
- Autenticación: Suplantación de XFF y proxies de confianza / Autenticación frente a autorización
- Claves: Conceptos básicos de seguridad: .env y claves de API / ¿Qué es CVSS?