CISA confirma ataques a SSHole y a FreeSWITCH: cuatro fallas al catálogo KEV con solo tres días de plazo, hasta el 12 de noviembre

Este lunes 9 de noviembre, la agencia de ciberseguridad de Estados Unidos (CISA) agregó cuatro vulnerabilidades a su catálogo de fallas con explotación confirmada (KEV). Dos le importan directamente a una pyme mexicana: SSHole, la falla de OpenSSH en servidores Alpine que te contamos el sábado, y una en FreeSWITCH, un motor de telefonía IP de código abierto.

Las cuatro llegaron con la misma fecha límite: jueves 12 de noviembre. Tres días.

Las cuatro fallas de hoy

En el catálogo, CISA marcó las cuatro con triage forense: bajo su directiva BOD 26-04 (del 10 de junio de 2026), las dependencias no solo deben parchar, también deben recolectar evidencia y determinar si ya hubo intrusión. Para una empresa privada nada de esto es obligatorio, pero el mensaje es útil: si el equipo estuvo expuesto, parchar no basta.

SSHole: de prueba de concepto a ataque confirmado

El jueves 5, OpenSSH publicó la versión 10.6p2. El viernes 6, la firma de inteligencia Previdian dijo a Help Net Security que su primer intento de explotación detectado llegó menos de nueve horas después de publicada la CVE, que contó ocho intentos desde una sola dirección IP en Japón y que el atacante obtuvo acceso root en una de sus trampas (honeypots) con Alpine Linux y OpenSSH reales. Luego corrió comandos de reconocimiento como id, uname y hostname.

Hasta el sábado, CISA no la tenía en el KEV; hoy ya está. Si el fin de semana aplicaste el parche o desactivaste PasswordAuthentication, vas bien. Lo que falta, si ese servidor estuvo expuesto con contraseñas activas entre el 5 y el día que parchaste, es revisar bitácoras: busca Accepted password for en cuentas que no deberían tener contraseña (root, alpine o usuarios que solo entran con llave), usuarios nuevos y llaves SSH agregadas.

FreeSWITCH: el conmutador que escucha mensajes de chat

FreeSWITCH es un motor de telefonía de código abierto que puede correr por dentro de conmutadores IP y plataformas de call center sin que el usuario lo vea. El aviso de seguridad del proyecto, publicado el 28 de octubre con severidad crítica (CVSS 9.8), explica el problema así: el módulo SIP (mod_sofia) acepta mensajes de chat (SIP MESSAGE), y un mensaje armado de cierta forma puede elegir el "protocolo" api, que ejecuta comandos de FreeSWITCH. Desde ahí, el atacante puede correr comandos con los permisos del servicio, leer configuración y credenciales y controlar llamadas. El aviso ya mencionaba explotación observada.

Lo grave son las condiciones:

• Viene vulnerable de fábrica. El chat está activo salvo que el perfil diga enable-chat=false, y los perfiles de ejemplo (internal y external) lo dejan encendido. La lista de acceso de entrada (ACL) no cubre los mensajes MESSAGE.
• Una cuenta cualquiera basta. Si exiges autenticación en los mensajes, cualquier cuenta válida del perfil sirve, aunque solo tenga permiso de registrarse.
• Ni siquiera eso, con la configuración de ejemplo. Las instalaciones que conservan el directorio de ejemplo tienen un usuario default sin contraseña que se autentica salvo que allow-empty-password esté en false.

Qué hacer:

1. Pregúntale a tu proveedor si tu conmutador, tu call center o tu troncal SIP usan FreeSWITCH, y en qué versión. Todas hasta la 1.11.2 son vulnerables.
2. Actualiza a la 1.11.3. Esta versión agrega un parámetro por perfil, enable-chat-api-proto, apagado por defecto, y rechaza con un error 403 los intentos de usar el protocolo api.
3. Si no puedes actualizar hoy, pon enable-chat=false en los perfiles que no necesiten chat por SIP. Según el aviso, eso cierra el camino por completo en esos perfiles. Activar auth-messages o disable_system_api_commands=true no es suficiente.
4. Borra usuarios sin contraseña del directorio y cambia las credenciales SIP si sospechas que alguien leyó la configuración.

Si este escenario te suena, es porque ya lo vivimos con Issabel en septiembre: conmutadores instalados una vez, con la configuración de ejemplo, expuestos a internet y sin nadie a cargo de actualizarlos. En nuestra guía de telefonía IP para empresas insistimos en que el mantenimiento del conmutador entre en el contrato.

GPUStack y Aspera: menos comunes, igual de serios

GPUStack es una herramienta de código abierto para administrar servidores con GPU y servir modelos de IA. Su aviso (publicado el 31 de julio, CVSS 9.8) explica que, con la configuración de fábrica, trata como administrador cualquier petición que parezca venir de la propia máquina, y eso se puede falsificar con un encabezado X-GPUStack-Real-IP o pasa solo si hay un proxy inverso en el mismo servidor. El proyecto reportó explotación contra una instalación 2.1.1. Corrige la 2.2.0; mientras, pon force_auth_localhost=true y no dejes la API expuesta a internet. Si tu equipo montó un servidor de IA propio "para probar", es buen momento para preguntar qué software usa.

IBM Aspera Faspex es la plataforma de IBM para enviar archivos muy grandes entre empresas. IBM publicó el 7 de noviembre que las versiones 5.0.0 a 5.0.19 permiten a un usuario autenticado obtener privilegios de administrador (CVSS 9.8) y que se corrige con 5.0.19 PL1, sin alternativa temporal. El boletín de IBM no hablaba de ataques; el catálogo de CISA, sí.

Qué hacer antes del jueves

1. Haz la lista de lo que se ve desde internet: SSH, puertos SIP de telefonía (normalmente 5060 y 5061), paneles de administración y APIs de IA. Si no sabes qué está expuesto, empieza por los reenvíos de puertos de tu firewall.
2. Parcha en este orden: lo expuesto y sin autenticación (SSHole, FreeSWITCH con configuración de ejemplo, GPUStack), después lo que requiere cuenta (Aspera).
3. Cierra lo que no necesita estar abierto. SSH y la administración del conmutador deben quedar detrás de una VPN o un acceso Zero Trust, no abiertos a todo internet.
4. Revisa huellas en cada equipo que estuvo expuesto antes del parche: accesos raros, usuarios nuevos, llamadas a destinos internacionales que nadie hizo.

Fuentes: catálogo KEV de CISA (versión 2026.11.09) y guía de implementación de la directiva BOD 26-04; aviso GHSA-mg63-h38w-8p9p de FreeSWITCH (28 de octubre); aviso GHSA-gj9m-f8ph-pmhr de GPUStack (31 de julio); boletín de seguridad de IBM para Aspera Faspex (7 de noviembre); Help Net Security (6 de noviembre) con datos de Previdian; notas de la versión 10.6p2 de OpenSSH y aviso de Alpine Linux (5 de noviembre).