La Agencia de Ciberseguridad y Seguridad de Infraestructuras de Estados Unidos (CISA) añadió el 9 de noviembre cuatro vulnerabilidades a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), al detectar pruebas de explotación activa. Los fallos afectan a GPUStack, SignalWire FreeSwitch, OpenBSD OpenSSH e IBM Aspera Faspex, y ponen en riesgo a las organizaciones que ejecutan despliegues vulnerables de accesos no autorizados, ejecución de comandos o escalada de privilegios.
La alerta de CISA establece estas prioridades de corrección para las organizaciones afectadas. Los relatos técnicos públicos describen ataques contra OpenSSH en Linux y contra GPUStack, mientras que el aviso del fabricante de FreeSWITCH también confirma la explotación en entornos reales.
Las cuatro incorporaciones al catálogo son:
- CVE-2026-102895, GPUStack: autenticación incorrecta que permite el acceso administrativo sin credenciales. El fabricante identifica como afectadas las versiones anteriores a 2.2.0 y recomienda 2.2.0 o posterior.
- CVE-2026-116779, SignalWire FreeSwitch: inyección de código que puede exponer la configuración y las credenciales, dar a los atacantes el control de las llamadas y permitirles ejecutar comandos.
- CVE-2026-123158, OpenBSD OpenSSH: un fallo por código de estado o valor de retorno inesperado, conocido como SSHole, que puede eludir la autenticación en Linux.
- CVE-2026-123218, IBM Aspera Faspex: autorización incorrecta que permite a un usuario autenticado enviar un mensaje especialmente diseñado y elevar sus privilegios.
The Hacker News informó de puntuaciones de gravedad CVSS de 9,8 para los fallos de GPUStack, FreeSwitch y Faspex, y de 8,1 para SSHole. Sitúa las correcciones en julio, octubre, noviembre y noviembre de 2026, respectivamente.
Los ataques contra OpenSSH incluyen intentos de mantener el acceso
The Hacker News informó de que Previdian había registrado 22 intentos de explotación de SSHole procedentes de 14 direcciones IP únicas, con intentos fechados desde el 6 de noviembre. Defused Cyber indicó en una publicación del 7 de noviembre que había observado a un pequeño número de actores atacando el fallo y que la actividad aún no estaba generalizada.
GreyNoise registró el primer intento contra su red de honeypots (sistemas utilizados para observar ataques) a las 00:46 UTC del 7 de noviembre. Informó de actividad confirmada tras la explotación desde seis direcciones IP de origen, que representaban 18 cadenas de ataque distintas.
Esas cadenas incluían reconocimiento, consultas a servicios de metadatos de la nube, intentos de leer hashes de contraseñas y claves SSH de root, y esfuerzos por modificar el archivo authorized_keys de SSH para mantener el acceso. En al menos un caso, los atacantes desplegaron TAC Agent, un programa de comando y control en Python capaz de ejecutar comandos de shell, recopilar información del sistema, listar directorios, transferir archivos y actualizarse a sí mismo.
El informe también citó observaciones de watchTowr sobre la explotación de SSHole con fines de botnets y minería de criptomonedas.
GPUStack puede confundir el tráfico remoto con un administrador local
El aviso de GPUStack describe un fallo de confianza en get_current_user, en gpustack/api/auth.py. Antes de la versión 2.2.0, las solicitudes consideradas procedentes de loopback (la propia dirección de red local del host) recibían automáticamente la identidad de administrador integrada cuando force_auth_localhost tenía el valor False, que es su valor predeterminado.
Dos rutas podían activar ese comportamiento. En un despliegue autoalojado típico, con un proxy inverso en la misma máquina que reenvía a 127.0.0.1, las solicitudes remotas llegaban a GPUStack con una dirección de socket local. No se necesitaban credenciales ni cabeceras falsificadas. El aviso indica que esta ruta se verificó de extremo a extremo contra HEAD 6bee5883. Alternativamente, un atacante podía enviar X-GPUStack-Real-IP: 127.0.0.1 para que una solicitud pareciera local.
Ese acceso permitía a los atacantes inspeccionar y modificar usuarios, modelos, workers y configuración; leer credenciales de workers y secretos de proveedores de nube; y crear claves de API de administrador persistentes con el alcance ["*"], utilizables después desde cualquier IP de origen. Las funciones administrativas, como POST /v2/inference-backends/from-yaml, podían ejecutar código en los hosts de los workers.
Los mantenedores informan de explotación contra un despliegue de 2.1.1, donde los backends personalizados creados por los atacantes ejecutaban reverse shells, lo que daba a estos acceso remoto para ejecutar comandos. Los mantenedores reconocen los informes independientes de Nikko Enggaliano, Wei Yunzhou, Rui Yang y Haoyu Wang, de la Universidad Johns Hopkins, y la explotación activa notificada por Javier Sixto, de Ulex Innovative Systems. The Hacker News fecha el aviso el 31 de julio.
Los mensajes de chat de FreeSWITCH pueden llegar a las interfaces de comandos
El aviso de FreeSWITCH explica que sofia_presence_handle_sip_i_message() divide el usuario de destino de un SIP MESSAGE entrante en el carácter +, y trata la parte izquierda como un selector de protocolo de chat. SIP es un protocolo de señalización que usan los sistemas de llamadas.
El módulo mod_dptools registra una interfaz de chat api que pasa su dirección a switch_api_execute(). Por tanto, un par capaz de lograr que se acepte un MESSAGE puede seleccionar un comando de la API de FreeSWITCH. Los comandos se ejecutan con los privilegios del proceso de FreeSWITCH, lo que permite ejecutar comandos del sistema operativo, revelar credenciales y configuración, y tomar el control total de las llamadas. Cuando mod_lua está cargado, como ocurre en la configuración estándar, el código Lua en línea también puede acceder a la biblioteca estándar completa.
El chat entrante está habilitado salvo que un perfil establezca enable-chat=false; los perfiles internos y externos estándar lo dejan habilitado. Endurecer la lista de control de acceso entrante no elimina la exposición, porque esa lista no cubre el tráfico MESSAGE.
Donde se aplica la autenticación de MESSAGE, basta con una cuenta ordinaria con permiso de registro. Algunas configuraciones estándar también permiten el acceso sin una cuenta controlada por el atacante: conf/vanilla/directory/default/default.xml define un usuario default sin password ni a1-hash, que se autentica salvo que allow-empty-password sea false para ese usuario.
La corrección introduce un ajuste por perfil, enable-chat-api-proto, que está desactivado salvo que se habilite explícitamente. Los intentos bloqueados de seleccionar api reciben una respuesta 403 y generan un registro con el origen y el comando solicitado. La comprobación no distingue mayúsculas de minúsculas; los mensajes sin selector o que usan otros protocolos de chat conservan su enrutamiento. El ajuste viene comentado en los perfiles vanilla y en el ejemplo de mod_sofia. El aviso reconoce a Örn Arnarson y Gunnlaugur.
Qué deben hacer los administradores
Los administradores de GPUStack deben actualizar a 2.2.0 o posterior, versión que elimina el acceso automático de administrador por loopback y refuerza el tratamiento de las direcciones de cliente. Las soluciones alternativas de los mantenedores consisten en establecer force_auth_localhost=true, impedir que los proxies presenten las solicitudes externas como loopback, eliminar en el perímetro las cabeceras X-GPUStack-Real-IP enviadas por el cliente y restringir el acceso a la API mediante una VPN o una autenticación en el perímetro.
Los administradores de FreeSWITCH deben aplicar la corrección del fabricante o establecer enable-chat=false en cada perfil que no necesite chat SIP entrante. Esta solución alternativa desactiva toda la entrega de chat MESSAGE entrante en esos perfiles.
La autenticación por sí sola no cierra la vía de comandos de FreeSWITCH. La autenticación de MESSAGE está habilitada por defecto desde la versión 1.10.7; combinada con la eliminación de todos los usuarios del directorio que carezcan de ambos campos de contraseña (incluidos los usuarios de ejemplo default y Skinny), solo reduce la exposición a la ejecución de comandos por parte de usuarios autenticados. Del mismo modo, disable_system_api_commands=true elimina la API system, pero deja accesibles otras API, incluidas la carga de módulos y la originación de llamadas.
Para las agencias federales civiles del Poder Ejecutivo de Estados Unidos, la Binding Operational Directive 26-04 de CISA exige priorizar con rapidez los fallos del KEV en activos expuestos públicamente cuando la explotación otorga control total, y establece expectativas para comprobar si el compromiso precedió a la aplicación del parche. The Hacker News informa de una fecha límite de corrección el 12 de noviembre para estas incorporaciones; esa fecha concierne a las agencias federales civiles. CISA anima a otras organizaciones a priorizar la corrección de las vulnerabilidades del KEV mediante una gestión de vulnerabilidades basada en el riesgo.
