Ilustración editorial generada con IA por Defensops. No es una fotografía del incidente ni de los equipos afectados. Representa Ilustración del desvío de autenticación SSH en un router expuesto.

Síntesis y análisis propios a partir de la cobertura de The Hacker News; las afirmaciones del medio se atribuyen a su fuente.

Qué se ha confirmado

Según The Hacker News, CERT Polska denomina MikroTrick a la combinación de CVE-2026-67279, un fallo en el estado de SSH, y CVE-2026-86060, una inyección de argumentos en el inicio de sesión de RouterOS.

El primer fallo permite pasar a la fase de comandos después de renegociar la clave SSH durante la autenticación, sin que el servidor confirme la identidad del cliente.

En el segundo fallo, el nombre de usuario -2 se interpreta como una opción del programa de login, que toma del terminal una identidad y un nivel de privilegio elegidos por el atacante.

The Hacker News recoge registros de intentos con el usuario -2 desde el 2 de septiembre, un día antes de los parches de RouterOS 6.49.21, 7.23.4 y 7.24.2.

CERT Polska observó casos con creación de archivos de diagnóstico seguida de transferencias a una IP atacante, indicio de posible copia de configuraciones.

La cadena exige que SSH sea accesible para el atacante; la configuración doméstica predeterminada no lo expone a Internet, según MikroTik.

La fuente advierte de que actualizar bloquea la cadena, pero no revierte cuentas u otros cambios efectuados durante una intrusión previa.

Análisis de Defensops

La aportación de este análisis es explicar por qué los dos fallos juntos permiten una consola administrativa sin credenciales. El salto de fase SSH por sí solo no concede privilegios; la interpretación del nombre de usuario como parámetro completa la escalada. Esta distinción ayuda a revisar registros de autenticación fallida que, aislados, podrían parecer intentos ordinarios.

La exposición depende de las reglas de acceso al servicio SSH en cada router. El riesgo descrito concierne a equipos alcanzables desde redes no confiables; no permite extrapolar el mismo alcance a todas las instalaciones de RouterOS. La existencia de actividad anterior al parche obliga a separar la contención de la vulnerabilidad de la investigación de cambios persistentes.

La posible salida de archivos de diagnóstico convierte las credenciales y la configuración del equipo en parte de la respuesta al incidente. Ni el estado Flagged limpio ni la ausencia de una única huella bastan para descartar compromiso, según las limitaciones recogidas por la publicación. No hay una cifra autorizada de dispositivos comprometidos.

Prioridades de revisión

Inventariar routers MikroTik y comprobar desde qué redes se puede alcanzar SSH; restringirlo a rutas de administración autorizadas cuando no deba estar expuesto.

Verificar la versión instalada frente a las versiones corregidas citadas por la fuente y aplicar la actualización correspondiente.

Examinar registros SSH por intentos de usuario -2 y revisar la existencia de la cuenta ops con privilegios completos, junto con otras cuentas desconocidas.

Revisar cambios inesperados en scripts, tareas programadas, túneles y proxies, así como archivos de diagnóstico y transferencias no explicadas; consultar también el estado Flagged sin tratar un resultado negativo como prueba de limpieza.

Si aparecen indicios de compromiso, aislar el equipo, conservar registros y configuración para análisis, restablecerlo y reconstruirlo desde una configuración fiable; renovar contraseñas y claves potencialmente expuestas.

Qué no se ha confirmado

No se ha publicado un recuento autorizado de dispositivos comprometidos.

Los archivos de diagnóstico y transferencias observados sugieren copia de configuración, pero la fuente no demuestra el contenido extraído en cada incidente.

La ausencia de los indicadores conocidos o de estado Flagged no descarta otras modificaciones en un router.

Fuente

The Hacker News. Fecha indicada: 2026-09-23.