La vulnerabilidad de GPUStack CVE-2026-102895 convierte en administrador a cualquiera que logre parecer local. Sin contraseña, sin token y sin tocar la pantalla de acceso: basta que la petición parezca venir de 127.0.0.1, la dirección que un equipo usa para hablar consigo mismo. CISA la metió el 9 de noviembre en su catálogo de fallos explotados y el plazo federal para corregirla vence mañana, 12 de noviembre.
GPUStack es un gestor de clústeres de tarjetas gráficas (GPU) de código abierto: sirve modelos de inteligencia artificial y reparte instancias de GPU entre máquinas trabajadoras. En las versiones anteriores a la 2.2.0, la función get_current_user, dentro del archivo gpustack/api/auth.py, ascendía a administrador integrado toda petición con origen local cuando el ajuste force_auth_localhost estaba en falso. Ese es su valor por defecto.
El origen de la petición lo calcula otra función, client_ip_getter, y el aviso de seguridad del propio proyecto, publicado en GitHub, describe dos caminos para que devuelva 127.0.0.1 sin credenciales. El primero pasa por un proxy inverso instalado en el mismo servidor, la forma habitual de montar el servicio en casa.
Con ese reenvío, el proxy manda el tráfico a http://127.0.0.1 y cada petición remota llega con par TCP local. La rama de administrador se activa sola. Ni cabecera hace falta.
La segunda vía usa una cabecera falsificada, X-GPUStack-Real-IP con valor 127.0.0.1, en el modo de puerta de enlace integrada. La causa raíz, escrita por los mantenedores con todas sus letras, es confiar en el origen de red de una petición como señal de identidad: un par de socket local o una cabecera que el cliente controla no prueban quién pide.
Qué se puede hacer con ese acceso
El acceso obtenido es administrativo y completo. El aviso enumera: listar y modificar usuarios, modelos, máquinas trabajadoras y la configuración; crear claves de interfaz de programación (API) de administrador persistentes, con alcance total y válidas desde cualquier dirección IP; leer credenciales de los trabajadores y secretos de proveedores de nube.
Con una función reservada a administradores, POST /v2/inference-backends/from-yaml, el acceso termina en ejecución de código en los equipos trabajadores.
No es un escenario de laboratorio. El aviso afirma que el fallo fue observado en explotación real contra un despliegue con la versión 2.1.1, con motores de inferencia personalizados que abrían shells inversas en los trabajadores.
El registro del CVE, publicado el 4 de noviembre, lo puntúa con CVSS 3.1 de 9,8 sobre 10, crítico. Ostorlab, que desarmó el fallo línea por línea, mide el parque expuesto con un dato: la imagen de GPUStack en Docker Hub sumaba 942.824 descargas el 5 de noviembre.
Ese retrato encaja con un problema más amplio ya contado en este medio: la infraestructura de IA expuesta en internet creció 63 % en el informe de Censys de octubre.
Muchos de esos despliegues son de equipos pequeños, también en América Latina, que montan su clúster propio con un proxy inverso en el mismo servidor para servir un modelo sin pagar nube grande. Esa forma de montaje, la que el aviso llama canónica, es justo la que deja la puerta abierta.
El arreglo existe desde junio y parchear solo no alcanza
La corrección llegó con la versión 2.2.0, publicada el 18 de junio: eliminó la ruta de administrador automático por origen local y endureció el trato de las cabeceras de reenvío.
El commit que quitaba el atajo entró al repositorio el 19 de mayo, casi seis meses antes de que CISA sumara el fallo a su catálogo, con triaje forense exigido a las agencias federales. El reloj de tres días premia a quien ya venía actualizado y castiga al que dejó el servidor en la 2.1.1.
Ostorlab recomienda subir un escalón más, hasta la 2.2.2, y recrear el contenedor. El motivo es un segundo fallo, CVE-2026-102894, un rodeo de la respuesta SAML con CVSS 9,1 que alcanza a todas las versiones de la 0.7.1 a la 2.2.1, incluso sin SAML configurado: quedarse en la 2.2.0 cierra una puerta y deja abierta la otra.
Para quien no pueda actualizar hoy, el aviso deja tres atajos temporales: activar force_auth_localhost, borrar en el borde cualquier cabecera X-GPUStack-Real-IP que traiga el cliente y mantener la API fuera de redes no confiables, detrás de una red privada virtual (VPN).
La parte que más equipos olvida viene después del parche. Una clave de administrador creada por un atacante sigue válida tras actualizar, porque nació con alcance total y sin atadura a la dirección de origen.
Toca revisar usuarios y claves emitidas, comparar los motores de inferencia con los registros propios y rotar las credenciales de trabajadores y de nube como si ya hubieran sido leídas. El aviso no publica fecha de la explotación observada, ni número de víctimas ni indicadores de compromiso: cada administrador debe buscar en sus registros las peticiones que entraron sin credencial y salieron con respuesta de administrador.
El fallo lo reportaron Nikko Enggaliano, Wei Yunzhou, Rui Yang y Haoyu Wang, de la Universidad Johns Hopkins, y la explotación activa la avisó Javier Sixto.
Para cualquier equipo que sirva modelos con GPUStack detrás de un proxy en el mismo servidor, la comprobación de esta noche es corta: versión instalada, valor de force_auth_localhost y lista de claves vigentes. Mañana vence el plazo de CISA, y los escáneres que buscan este atajo no distinguen entre una agencia federal y un clúster casero en Hazleton o en Santo Domingo.
Fuente: GPUStack en GitHub
