Vulnerabilidad crítica en MikroTik RouterOS (septiembre 2026): explotación activa por SSH y qué hacer hoy

Si operas un ISP, un WISP o una red empresarial sobre MikroTik, esto no es un aviso más de los que se archivan. Es la primera vez en años que MikroTik publica un parche sin explicar qué corrige, incorpora un mecanismo nuevo para detectar equipos comprometidos y un CERT nacional confirma explotación activa dos días después. Esta nota resume lo que se sabe hoy, cómo verificar tus equipos y cómo cerrar la ventana de exposición sin dejar clientes sin servicio.

1. Qué pasó, en orden

2. Las fallas (CVE) y a quién afectan

Todas afectan a RouterOS 6.0 a 6.49.20 y 7.0 a 7.24.1, es decir, a prácticamente todo equipo que no se haya actualizado esta semana. La cadena explotada combina las dos fallas de SSH: la primera abre la sesión sin llave privada, la segunda la convierte en administrador.

3. Quién está realmente en riesgo

• Riesgo inmediato: cualquier equipo con el servicio SSH alcanzable desde internet, aunque tenga contraseña fuerte y aunque use llaves. Aquí no se adivina nada: se entra.
• Riesgo alto: equipos con bandwidth-test habilitado (viene activo por defecto) y expuesto, o con WWW/WWW-SSL públicos.
• Riesgo moderado: equipos cuya gestión está detrás de VPN o de listas de direcciones. Siguen siendo vulnerables desde la LAN o desde cualquier segmento que alcance esos servicios (un CPE de cliente comprometido, un Wi-Fi de invitados mal aislado, un contratista).
• Los CPE y los enlaces de última milla también cuentan. En un WISP, cientos de equipos pequeños con SSH abierto hacia la red de gestión son la puerta lateral hacia el concentrador. La actualización tiene que cubrir la flota completa, no solo el core.

4. Cómo verificar si un equipo fue comprometido

Primero actualiza (sección 5); RouterOS hace parte del trabajo por ti al arrancar. Luego, con o sin marca Flagged, revisa lo siguiente. Los comandos están en sintaxis de RouterOS 7; en v6 cambia las barras por espacios.

# 1. Estado del detector (solo existe tras actualizar a una versión parcheada)
/system/device-mode/print

# 2. Rastros de la cadena de ataque en el log (CERT Polska)
/log/print where message~"user -2"
/log/print where message~"ssh:-2@"

# 3. Usuarios y llaves que no creaste (el atacante suele crear "ops")
/user/print detail
/user/ssh-keys/print
/user/active/print

# 4. Persistencia: scripts, tareas programadas, proxies y túneles
/system/script/print
/system/scheduler/print
/ip/socks/print
/ip/proxy/print
/interface/print where type~"eoip|gre|ipip|l2tp|pptp|sstp|wg|ovpn"

# 5. Servicios que miran a internet
/ip/service/print
/tool/bandwidth-server/print

Si el equipo aparece como Flagged

RouterOS ya deshabilitó lo que le pareció sospechoso y bloquea crear nuevas entradas en scheduler, SOCKS, proxy, PPTP, L2TP, IPsec y SMB, además de las herramientas bandwidth-test, traffic-generator y sniffer. Antes de limpiar el estado, la secuencia correcta es:

1. Exportar la configuración completa y guardarla como evidencia.
2. Eliminar usuarios, llaves SSH, scripts, schedulers, proxies y túneles que no reconozcas.
3. Cambiar todas las contraseñas y llaves del equipo, y las de los servicios que dependen de él (RADIUS, SNMP, VPN, PPPoE de gestión).
4. Confirmar que está en la versión parcheada.
5. Ejecutar /system/device-mode/update flagged=no. El equipo exige confirmación física: pulsar el botón de reset o cortar la alimentación. Si el equipo está a 200 km, esto implica desplazar a alguien; planifícalo.

5. Actualizar sin tumbar la red

# 0. Respaldo ANTES de tocar nada (y cópialo fuera del equipo)
/system/backup/save name=pre-sec-20260905
/export show-sensitive file=pre-sec-20260905

# 1. Espacio libre: el paquete pesa ~15 MB; en equipos de 16 MB de flash hay que limpiar /file primero
/system/resource/print
/file/print

# 2. Canal y descarga
/system/package/update/set channel=long-term
/system/package/update/check-for-updates
/system/package/update/install
   → reinicio #1 (RouterOS)

# 3. Firmware de RouterBOOT (segundo reinicio, no lo omitas)
/system/routerboard/print
/system/routerboard/upgrade
/system/reboot
   → reinicio #2 (RouterBOOT)

# 4. Verificación
/system/package/print
/system/device-mode/print
/log/print where topics~"critical"

Cuánto dura el corte. Esta semana actualizamos un concentrador PPPoE con unos 950 clientes conectados de 7.22.2 a 7.23.5 long-term. Medido: el primer reinicio devolvió el equipo en 56 segundos, el de RouterBOOT en 116, y a los dos minutos del arranque ya habían reconectado 912 de los 954 clientes por sí solos. Los contenedores, WireGuard y User Manager volvieron sin intervención. Con respaldo hecho y espacio en flash verificado, la ventana real es de tres a cuatro minutos, no de una hora.

6. Si no puedes actualizar hoy: mitigaciones

Ninguna de estas sustituye el parche. Reducen la superficie mientras consigues la ventana.

# SSH, Winbox, WWW y API solo desde la red de gestión / VPN
/ip/service/set ssh address=10.99.100.0/24,192.0.2.10/32
/ip/service/set winbox address=10.99.100.0/24,192.0.2.10/32
/ip/service/set www,www-ssl,api,api-ssl address=10.99.100.0/24
/ip/service/disable telnet,ftp

# bandwidth-test viene habilitado por defecto: apágalo salvo que lo uses
/tool/bandwidth-server/set enabled=no

# Solo llaves modernas y sin contraseña por SSH
/ip/ssh/set strong-crypto=yes
/ip/ssh/set password-authentication=no

# Usuarios de operación diaria sin la política "test" (btest, sniffer, traceroute): grupo mínimo, no "full"
/user/group/add name=operador policy="ssh,winbox,web,read,write,!test,!ftp,!telnet,!policy,!sensitive,!sniff"
/user/print
/user/set [find name=operador1] group=operador

# Y la regla que debería existir desde el día uno: input cerrado por defecto
/ip/firewall/address-list/add list=mgmt-allowed address=10.99.100.0/24 comment="Red de gestion"
/ip/firewall/filter/add chain=input src-address-list=mgmt-allowed action=accept comment="Gestion" place-before=0
/ip/firewall/filter/add chain=input connection-state=established,related action=accept place-before=0
/ip/firewall/filter/add chain=input action=drop comment="Drop resto input"

• Llaves RSA con exponente 3: son las que hacen posible la falla de firma. Sustitúyelas por Ed25519 (o RSA con exponente 65537) en /user/ssh-keys y en cualquier certificado propio que el router valide.
• Cuidado con la lista de direcciones del servicio. Restringir /ip/service corta el protocolo, pero el puerto sigue completando el handshake TCP y aparece “abierto” en un escaneo. La defensa real es la cadena input del firewall con drop final.
• No te dejes fuera. Toda restricción de gestión se aplica con safe-mode activo y con un canal alternativo probado (RoMON, MAC-Telnet desde un vecino, consola).

7. Cómo te ayuda MikroHelp

Llevamos desde el 3 de septiembre aplicando esto en flotas reales, con clientes encima. Lo que ofrecemos es exactamente lo que hemos hecho en las nuestras:

Y si prefieres no volver a vivir esto cada vez que MikroTik publica un aviso: nuestro servicio de gestión completa para WISP incluye el monitoreo de versiones y la aplicación de parches de seguridad en toda la flota como parte del día a día, no como una emergencia.