Si quieres pasar directamente a la guía de hardening, busca en el navegador «guía practica» e iras directo a ella.
MikroTik publicó el 3 de septiembre de 2026 una actualización de seguridad urgente para RouterOS. Dos días después, CERT Polska reveló seis vulnerabilidades que afectan al servidor y cliente SSH, WebFig, bandwidth-test y la validación de certificados X.509. Dos de ellas, CVE-2026-67276 y CVE-2026-86060, pueden encadenarse para formar el ataque «MikroTrick», una técnica que CERT Polska ha observado como vector de ataque contra dispositivos con SSH accesible desde redes públicas. Advertiros que el nombre del ataque, «MikroTrick» puede dar a confusion con el nombre del fabricante MikroTik así que tenerlo en cuenta en la lectura.
Para los administradores de red, el problema no termina al instalar el parche. CERT Polska sitúa ataques exitosos desde, al menos, el 2 de septiembre, antes de que las versiones corregidas estuvieran disponibles públicamente. Esto obliga a tratar la actualización y la búsqueda de indicadores de compromiso como dos tareas independientes: parchear impide el ataque conocido, pero no elimina una persistencia creada antes de actualizar.
Las correcciones están incluidas en RouterOS 7.24.2, 7.23.4, 7.25beta3 y 6.49.21. La rama long-term 7.23.4 fue sustituida posteriormente por 7.23.5, que conserva las correcciones y soluciona una regresión introducida en DHCP sobre IPv6. A 7 de septiembre, 7.24.2 es la versión Stable y 7.23.5 la Long-term relevante para producción.
La superficie de ataque: no todas las vulnerabilidades requieren las mismas condiciones
Las seis vulnerabilidades afectan al mismo rango general de versiones, pero no comparten el mismo vector de explotación. Para un administrador es más útil identificar qué servicios están expuestos que limitarse a comprobar el número de versión.
| CVE | CVSS v4 | Superficie | Condición principal | Impacto |
|---|---|---|---|---|
| CVE-2026-67276 | 9,2 Crítica | SSH | SSH alcanzable y conocimiento del usuario y módulo RSA autorizado | Suplantación de usuario sin poseer su clave privada |
| CVE-2026-86060 | 9,2 Crítica | SSH | Sesión no autenticada capaz de alcanzar el login helper | Manipulación de policy mask y privilegios administrativos |
| CVE-2026-67277 | 8,8 Alta | bandwidth-test | Servicio alcanzable | Fuga de memoria del kernel y DoS con reinicio |
| CVE-2026-67281 | 8,7 Alta | WebFig /jsproxy | WebFig alcanzable | Lectura no autenticada de determinados archivos |
| CVE-2026-67279 | 6,9 Media | SSH | SSH alcanzable | Ejecución prematura de solicitudes exec y manipulación de archivos |
| CVE-2026-67278 | 6,3 Media | TLS saliente | Control o redirección de una conexión TLS saliente | Suplantación del servidor TLS |
Los rangos publicados por CERT Polska son:
- RouterOS 6.0.0 hasta versiones anteriores a 6.49.21.
- RouterOS 7.0.0 hasta versiones anteriores a 7.23.4.
- RouterOS 7.24 hasta versiones anteriores a 7.24.2.
Esto significa que utilizar una versión de RouterOS relativamente reciente no garantiza estar fuera del rango afectado.
Ataque «MikroTrick»: de un error criptográfico a control administrativo
La parte más crítica del incidente se encuentra en SSH.
1. CVE-2026-67276: RouterOS no validaba toda la clave RSA
Durante la autenticación SSH mediante clave pública, RouterOS debía comprobar que la clave presentada por el cliente coincidía con la autorizada para el usuario.
El problema estaba en que comparaba el tipo de clave y el módulo RSA, pero no el exponente.
Una clave RSA pública está formada esencialmente por dos valores:
(n, e)donde n es el módulo y e el exponente público.
Un atacante que conozca el nombre del usuario y el módulo de una clave RSA autorizada puede construir otra clave con el mismo módulo y un exponente manipulado. CERT Polska documenta el uso de un exponente igual a uno para conseguir que RouterOS acepte una firma sin disponer de la clave privada legítima.
No significa que cualquier clave permita iniciar sesión en cualquier router. Exige que el atacante necesita alcanzar SSH y conocer información sobre una clave RSA autorizada.
Sin embargo, el problema rompe una propiedad esencial del sistema: poseer la clave privada deja de ser un requisito suficiente para demostrar la identidad del usuario.
2. CVE-2026-86060: manipulación de la policy mask
La segunda vulnerabilidad se encuentra también en la ruta de autenticación SSH.
RouterOS utiliza internamente una policy mask para representar los permisos de una sesión: lectura, escritura, administración de usuarios, acceso SSH, WinBox y otras capacidades.
CERT Polska descubrió que determinadas cadenas utilizadas como nombre de usuario podían alterar esa máscara de permisos cuando llegaban al componente interno responsable del inicio de sesión.
Una sesión que consiga alcanzar ese punto puede terminar obteniendo privilegios administrativos completos.
El encadenamiento resulta especialmente importante:
Acceso a SSH
↓
CVE-2026-67276
Bypass de autenticación RSA
↓
CVE-2026-86060
Manipulación de la policy mask
↓
Privilegios administrativos
↓
Control del routerCERT Polska denomina «MikroTrick» a esta combinación y confirma que ha sido utilizada contra equipos reales.
3. CVE-2026-67279: otro fallo preautenticación en SSH
«MikroTrick» no es el único motivo por el que un administrador debe retirar SSH de Internet.
CVE-2026-67279 afecta a la máquina de estados del protocolo. Después de que el cliente solicitase una renegociación de claves o rekey, RouterOS podía avanzar hacia la fase de conexión sin haber completado antes la autenticación.
El cliente podía entonces abrir un canal de sesión y enviar una solicitud:
execEn versiones vulnerables, RouterOS procesaba esa operación y permitía crear, sobrescribir o reconstruir archivos dentro del espacio de archivos gestionado por el sistema, incluidos determinados archivos de soporte que contienen información de configuración y diagnóstico.
Por tanto, restringir SSH es relevante incluso en instalaciones que no utilicen autenticación mediante claves RSA.
4. WebFig: lectura de archivos antes de autenticarse
CVE-2026-67281 afecta a WebFig y, concretamente, al componente /jsproxy.
El fallo combina un puntero de principal no inicializado utilizado para comprobar permisos con componentes de directorio padre dentro de una URI procesada por WebFig.
El resultado puede permitir que un atacante no autenticado salga del espacio de archivos esperado y lea determinados archivos propiedad de root.
CERT Polska indica que entre los archivos potencialmente accesibles existen almacenes de configuración que pueden contener credenciales.
Para un administrador, la conclusión es inmediata: una contraseña robusta no protege frente a este CVE si WebFig vulnerable está directamente accesible para el atacante, porque el problema se produce antes de una autenticación válida.
5. bandwidth-test: una herramienta de diagnostico de red convertida en superficie de ataque
CVE-2026-67277 afecta al servidor de pruebas de ancho de banda integrado en RouterOS.
Una conexión relacionada podía alcanzar un estado que debería haberse reservado a clientes autenticados. A partir de ese punto, dos errores adicionales permitían acceder a memoria no inicializada del kernel o provocar un cálculo incorrecto del tamaño de los paquetes.
CERT Polska documenta dos consecuencias:
- exposición de memoria del kernel;
- denegación de servicio remota capaz de reiniciar RouterOS.
En una red empresarial, bandwidth-test no debería estar habilitado permanentemente salvo que exista una necesidad de mantenimiento o diagnostico puntual de la red.
6. CVE-2026-67278: el problema que el firewall de entrada no resuelve
La sexta vulnerabilidad es diferente.
CVE-2026-67278 afecta a la comprobación de firmas RSA PKCS#1 v1.5 durante la validación de certificados X.509.
RouterOS aceptaba determinadas firmas malformadas y su almacén de confianza incluía una autoridad certificadora con exponente RSA e=3.
Un atacante que pueda interceptar o redirigir una conexión TLS iniciada desde el propio router podría construir una cadena aparentemente confiable y suplantar al servidor remoto.
Este detalle es importante: bloquear SSH o WebFig desde Internet no mitiga CVE-2026-67278. El parche es la solución principal.
CERT Polska recomienda que, mientras un dispositivo siga sin actualizar, no inicie conexiones TLS sobre redes no confiables y tampoco utilice los clientes SSH integrados:
/system ssh
/system ssh-exec
Qué se ha observado en los ataques
CERT Polska confirma que el ataque «MikroTrick» está siendo explotado activamente contra dispositivos con SSH accesible desde Internet.
Entre las entradas observadas aparecen patrones como:
login failure for user -2 from <IP> via sshseguidos de:
user <name> added by ssh:-2@<IP>También se ha observado la creación de un usuario con privilegios elevados denominado:
opsLas direcciones IP asociadas a la actividad conocida son:
82.192.72.4 (Ataques exitosos via "MikroTrick")
103.102.31.18 (Intentos de explotacion)La primera aparece vinculada por CERT Polska a ataques exitosos observados desde, al menos, el 2 de septiembre. La segunda fue utilizada en intentos de explotación.
Estos IOC deben utilizarse para buscar actividad histórica, no para construir la defensa exclusivamente alrededor de dos direcciones IP.
Bloquear 82.192.72.4 y 103.102.31.18 no protege frente a «MikroTrick» si SSH continúa abierto para todo Internet. Un atacante puede utilizar otra dirección IP en cualquier momento.
Tampoco puede considerarse limpio un router únicamente porque no exista el usuario ops.
Guía práctica: cómo securizar un MikroTik frente a estas vulnerabilidades.
Las siguientes medidas están pensadas para RouterOS 7 en entornos empresariales. Los comandos deben adaptarse a las interfaces, rangos y servicios de cada organización.
ADVERTENCIA
Antes de modificar remotamente el firewall de RouterOS o las interfaces de gestión, debe existir un mecanismo de recuperación ya sea via: acceso local, consola, out-of-band o una sesión de administración alternativa. Una regla incorrecta de firewall o un cambio en una interfaz de gestion puede dejar el router inaccesible. Antes de hacer cualquier cambio recuerda tambien que el «SAVE MODE» es tu mejor amigo 😉
1. Comprobar el estado del equipo.
Antes de realizar cambios, comprueba versión, servicios y sesiones activas:
/system resource print
/system package update print
/system device-mode print
/ip service print detail
/tool bandwidth-server print
/user print detail
/user active print
/user ssh-keys print detailHay cuatro preguntas que deben responderse inmediatamente:
- ¿Está RouterOS dentro del rango vulnerable?
- ¿SSH está habilitado?
- ¿SSH o WebFig son alcanzables desde Internet?
- ¿
bandwidth-testestá habilitado?
2. Buscar primero los IOC conocidos
Antes de reiniciar innecesariamente el dispositivo, revisar los registros:
/log print where message~"user -2"
/log print where message~"ssh:-2"
/log print where message~"82.192.72.4"
/log print where message~"103.102.31.18"Comprobar específicamente el usuario observado:
/user print detail where name="ops"Y revisar las sesiones actualmente abiertas:
/user active printEncontrar alguno de estos elementos debe iniciar un proceso de respuesta a incidentes.
No encontrarlos no descarta el compromiso.
3. Actualizar RouterOS
Para producción puede mantenerse la rama long-term:
/system package update set channel=long-term
/system package update check-for-updatesComprobar que ofrece 7.23.5 o posterior y realizar la instalación durante la ventana de mantenimiento:
/system package update installPara organizaciones que utilizan rama Stable:
/system package update set channel=stable
/system package update check-for-updatesLa versión relevante a 7 de septiembre es 7.24.2 o posterior.
Después del reinicio:
/system resource print
/system device-mode printEn dispositivos RouterBOARD, MikroTik recomienda también actualizar posteriormente el bootloader:
/system routerboard print
/system routerboard upgrade
/system rebootEl upgrade del bootloader no sustituye al parche de RouterOS, pero forma parte del mantenimiento recomendado por el fabricante.
4. Eliminar SSH de Internet
Esta es la medida de reducción de superficie más importante frente a los patrones observados.
Si SSH no se utiliza:
/ip service disable sshSi es imprescindible, limitarlo exclusivamente a una red administrativa, ejemplo:
/ip service set ssh address=10.255.255.0/24Sustituir 10.255.255.0/24 por la VLAN, VPN o rango real de administración.
Después del parche puede reforzarse la configuración criptográfica de SSH:
/ip ssh set strong-crypto=yesEsta última opción no corrige «MikroTrick». Es una medida adicional de hardening.
Cambiar el puerto SSH de 22 a otro valor tampoco debe considerarse una mitigación de estas CVE. Puede reducir ruido de escaneo automatizado, pero un servicio vulnerable sigue siendo vulnerable cuando el atacante descubre el nuevo puerto.
5. Deshabilitar WebFig si no se utiliza
Comprobar los servicios:
/ip service printSi WebFig no forma parte del modelo de administración:
/ip service disable www
/ip service disable www-sslSi se necesita WebFig, deshabilitar HTTP:
/ip service disable wwwy limitar HTTPS a la red administrativa:
/ip service set www-ssl address=10.255.255.0/24En producción debería utilizarse además un certificado apropiado para www-ssl.
La restricción de acceso es especialmente relevante frente a CVE-2026-67281, porque la vulnerabilidad afecta a una ruta que puede alcanzarse sin haber completado una autenticación válida.
6. Apagar bandwidth-test
MikroTik recomienda desactivar el servidor de pruebas en entornos de producción cuando no sea necesario:
/tool bandwidth-server set enabled=noEsto elimina directamente la superficie utilizada por CVE-2026-67277.
RouterOS permite añadir una segunda capa mediante device-mode. Primero comprobar el estado:
/system device-mode printSi la organización no utiliza esta funcionalidad:
/system device-mode update bandwidth-test=noCambiar device-mode requiere confirmación física mediante el botón del dispositivo o un ciclo de alimentación, precisamente para impedir que un atacante remoto modifique silenciosamente estas protecciones.
En equipos donde tampoco sean necesarios SOCKS o el proxy de RouterOS puede valorarse:
/system device-mode update bandwidth-test=no proxy=no socks=noDebe comprobarse previamente que ninguna de esas funciones forma parte de producción.
7. Aplicar doble control: "/ip service» y firewall
El parámetro address de «/ip service» restringe los orígenes desde los que RouterOS permite utilizar un servicio. MikroTik recomienda, no obstante, emplear además el firewall para impedir que redes no confiables lleguen siquiera al socket de administración.
Una política empresarial puede crear una lista de redes administrativas:
/ip firewall address-list
add list=MGMT-TRUSTED address=10.255.255.0/24 comment="Management VPN"Después, aceptar únicamente la gestión necesaria desde ese origen:
/ip firewall filter
add chain=input action=accept src-address-list=MGMT-TRUSTED protocol=tcp dst-port=22,443,8291 comment="SEC: trusted management"Y bloquear los servicios de administración desde WAN:
/ip firewall filter
add chain=input action=drop in-interface-list=WAN protocol=tcp dst-port=21,22,23,80,443,8291,8728,8729 comment="SEC: block management from WAN"Los puertos corresponden a servicios habituales como FTP, SSH, Telnet, WebFig, WinBox y API. Deben adaptarse si la organización ha modificado los puertos.
El orden de las reglas es crítico. La aceptación desde la red administrativa debe situarse antes de la regla que deniega el acceso desde WAN y respetar la política de firewall existente.
No debe pegarse este bloque sin revisar previamente:
/ip firewall filter print8. No olvidar IPv6
Un error frecuente consiste en proteger el acceso administrativo en IPv4 mientras el router conserva una dirección IPv6 global y una política de entrada más permisiva.
Comprobar:
/ipv6 address print
/ipv6 firewall filter printSi el dispositivo dispone de conectividad IPv6 pública, los mismos principios deben aplicarse en:
/ipv6 firewall filterUna regla de cierre para los servicios administrativos puede seguir la misma lógica:
/ipv6 firewall filter
add chain=input action=drop in-interface-list=WAN protocol=tcp dst-port=21,22,23,80,443,8291,8728,8729 comment="SEC: block management from IPv6 WAN"Esta regla debe integrarse en una política IPv6 correctamente diseñada. No deben eliminarse indiscriminadamente ICMPv6, Neighbor Discovery u otros componentes necesarios para el funcionamiento de IPv6.
9. Administrar el router a través de una VPN
Una arquitectura más segura consiste en dejar accesible desde Internet únicamente el endpoint de la VPN y administrar RouterOS a través de esa red.
WireGuard está integrado en RouterOS 7.
Ejemplo mínimo de una red dedicada a administración:
/interface wireguard
add name=wg-mgmt listen-port=13231
/ip address
add address=10.255.255.1/24 interface=wg-mgmt
/interface wireguard peers
add interface=wg-mgmt public-key="<CLAVE_PUBLICA_DEL_ADMIN>" allowed-address=10.255.255.2/32El firewall debe permitir el establecimiento de WireGuard desde WAN antes de la regla general de descarte:
/ip firewall filter
add chain=input action=accept in-interface-list=WAN protocol=udp dst-port=13231 comment="SEC: allow management WireGuard"A partir de ahí, WinBox, SSH o WebFig pueden limitarse exclusivamente a:
10.255.255.0/24Por ejemplo:
/ip service set winbox address=10.255.255.0/24
/ip service set ssh address=10.255.255.0/24La ventaja no es únicamente criptográfica. Los servicios vulnerables dejan de ser directamente alcanzables desde Internet.
10. Revisar usuarios, claves y mecanismos de persistencia
CERT Polska recomienda inspeccionar la configuración incluso cuando flagged=no.
Una revisión mínima debería incluir:
/user print detail
/user active print
/user ssh-keys print detail
/system script print detail
/system scheduler print detail
/ip firewall filter print detail
/ip firewall nat print detail
/ip firewall mangle print detail
/ip dns print
/ip route print detail
/ip proxy print
/ip socks print
/interface wireguard print detail
/interface eoip print detail
/interface gre print detail
/interface ipip print detail
/certificate print detail
/file print detailEl administrador debe buscar:
- usuarios desconocidos;
- nuevas claves SSH;
- scripts que no pertenezcan a la configuración habitual;
- tareas programadas;
- reglas NAT inesperadas;
- modificaciones del DNS;
- túneles desconocidos;
- proxies o SOCKS activados;
- rutas estáticas nuevas;
- certificados no reconocidos;
- ficheros creados recientemente.
CERT Polska cita específicamente usuarios, scripts, scheduler, proxies y túneles como elementos que deben revisarse.
11. Interpretar correctamente flagged
Tras instalar las versiones corregidas:
/system device-mode printpuede aparecer:
flagged: yesRouterOS analiza durante el arranque determinados rastros de modificaciones consideradas sospechosas. Cuando los detecta, deshabilita algunos elementos y activa el estado flagged.
Si aparece yes, debe asumirse un posible compromiso del dispositivo.
No debe ejecutarse inmediatamente:
/system device-mode update flagged=nopara hacer desaparecer el aviso.
Primero deben preservarse las evidencias y analizarse la configuración.
Igualmente importante:
flagged=nono significa “router limpio”.
El mecanismo solo reconoce determinados patrones conocidos.
12. Qué hacer si existen indicios de compromiso
Si aparece flagged=yes, el usuario ops, los patrones ssh:-2, cambios inexplicables o cualquier otra evidencia, el procedimiento cambia de hardening a respuesta a incidentes.
El orden recomendado para la respuesta a incidente es:
- Aislar el MikroTik de redes no confiables.
- Mantener acceso mediante consola o una red controlada.
- Preservar los registros antes de reiniciar innecesariamente.
- Obtener una copia de la configuración para análisis.
- Documentar usuarios, claves, rutas, firewall, NAT, túneles y scripts.
- Tras preservar las evidencias, realizar un factory reset.
- Actualizar RouterOS.
- Reconstruir la configuración desde una versión conocida y revisada teniendo en cuenta los pasos de hardening vistos anteriormente.
- Rotar credenciales y secretos.
Puede generarse un export para análisis:
/export file=incident-pre-resetTambién puede generarse un supout.rif:
/system sup-output name=incident-supout.rifEstos archivos deben descargarse y almacenarse de forma segura.
Un backup binario obtenido de un equipo sospechoso puede conservarse como evidencia, pero no debe utilizarse posteriormente como mecanismo automático de recuperación.
CERT Polska es explícito en este punto: no se debe restaurar ciegamente una copia completa procedente de un dispositivo potencialmente comprometido.
13. Rotar secretos después de un compromiso
Si el atacante ha conseguido privilegios administrativos, deben considerarse potencialmente expuestos los secretos gestionados desde el router.
Dependiendo de la configuración, puede ser necesario renovar:
- contraseñas de usuarios RouterOS;
- claves SSH autorizadas;
- claves privadas utilizadas para administración;
- claves de WireGuard;
- secretos IPsec;
- certificados y claves privadas;
- credenciales RADIUS;
- comunidades SNMP;
- credenciales PPP;
- claves utilizadas por túneles o servicios externos.
También puede regenerarse la identidad criptográfica del servidor SSH:
/ip ssh regenerate-host-keyEsto cambiará la huella SSH del router, por lo que los equipos de administración deberán actualizar sus registros known_hosts.
14. Reducir también la superficie de administración en capa 2
Aunque las CVE de septiembre se concentran principalmente en servicios IP, una política de hardening empresarial debería restringir igualmente las funciones de administración en capa 2.
MikroTik recomienda limitar o desactivar MAC-Telnet, MAC-WinBox y descubrimiento de vecinos en redes de producción.
Si se crea una lista de interfaces específica:
/interface list add name=MGMT
/interface list member add list=MGMT interface=wg-mgmtpuede utilizarse para limitar estas funciones:
/tool mac-server set allowed-interface-list=MGMT
/tool mac-server mac-winbox set allowed-interface-list=MGMT
/ip neighbor discovery-settings set discover-interface-list=MGMTSi no son necesarias:
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=none
/tool mac-server ping set enabled=no
/ip neighbor discovery-settings set discover-interface-list=none
15. Centralizar los logs
Los registros almacenados únicamente en el router tienen dos inconvenientes: son limitados y permanecen dentro del mismo dispositivo que puede resultar comprometido.
En una red empresarial, los eventos relevantes deberían enviarse a syslog, SIEM o una plataforma central de monitorización.
Como mínimo deben conservarse externamente eventos relacionados con:
- SSH;
- inicio y cierre de sesiones;
- creación o modificación de usuarios;
- sistema;
- errores;
- advertencias;
- eventos críticos.
Esto permite detectar patrones como ssh:-2 aunque el atacante modifique posteriormente la configuración o el dispositivo se reinicie.
Medidas que no deben confundirse con una solución
Ante un incidente de este tipo es fácil aplicar medidas que reducen ruido pero no eliminan la vulnerabilidad.
Cambiar el puerto SSH no corrige «MikroTrick».
Utilizar una contraseña compleja no corrige un fallo que permite superar la autenticación.
Bloquear únicamente las dos IP conocidas no impide que la explotación proceda de otra dirección.
Tener flagged=no no demuestra que el router esté limpio.
Cerrar únicamente IPv4 no protege un servicio que siga expuesto mediante IPv6.
Actualizar sin auditar posteriormente la configuración impide nuevos ataques conocidos, pero no elimina usuarios, scripts o túneles creados antes de instalar el parche.
La estrategia correcta combina:
PATCH
+
REDUCCIÓN DE SUPERFICIE
+
SEGMENTACIÓN DE GESTIÓN
+
BÚSQUEDA DE IOC
+
MONITORIZACIÓN
Qué configuración debería quedar después del hardening
Para un MikroTik empresarial que no necesite ofrecer servicios de administración públicamente, el objetivo debería aproximarse a este modelo:
INTERNET
│
│ UDP WireGuard
▼
┌───────────────────┐
│ MikroTik │
│ │
│ SSH ──┐ │
│ WinBox ──┼── accesibles solo desde VPN/MGMT
│ WebFig ──┘ │
│ │
│ API disabled │
│ Telnet disabled │
│ FTP disabled │
│ btest disabled │
└───────────────────┘
│
▼
LAN / VLANLa exposición pública debería limitarse únicamente a aquellos servicios que realmente deben ser públicos.
La interfaz de administración pertenece al plano de gestión, y debería tratarse como una red diferenciada del tráfico de usuarios y del plano de datos.
Ejemplo de un hAP con RouterOS 7.21.2
Un MikroTik hAP con RouterOS 7.21.2 está, por versión, dentro del rango publicado para las seis vulnerabilidades.
En una instalación empresarial con ese equipo, la actuación mínima sería:
- Revisar logs e IOC.
- Comprobar
flagged. - Retirar inmediatamente SSH, WebFig y
bandwidth-testde cualquier interfaz pública. - Actualizar a 7.23.5 Long-term o 7.24.2 Stable.
- Auditar usuarios, scripts, tareas, NAT, DNS, túneles y claves.
- Mantener WinBox/SSH únicamente mediante VPN o red de administración.
- Enviar los logs a un sistema externo.
Un salto a otra versión de la rama 7.21 no es suficiente para corregir las vulnerabilidades divulgadas en septiembre.
Cierre, la lección para los administradores de red.
«MikroTrick» vuelve a poner sobre la mesa una realidad conocida en seguridad de redes: ningún control aislado es suficiente. Mantener RouterOS actualizado es imprescindible, pero debe formar parte de una estrategia más amplia basada en reducción de superficie de ataque, segmentación del acceso administrativo, monitorización y revisión periódica de la configuración.
Para los administradores de red, la prioridad no debería ser únicamente corregir estas seis vulnerabilidades, sino revisar cómo se gestiona el router en su conjunto. Limitar los servicios expuestos, separar el plano de administración, centralizar los registros y disponer de procedimientos de respuesta ante incidentes puede marcar la diferencia entre un intento de explotación bloqueado y el compromiso completo de un dispositivo crítico.
Las vulnerabilidades de septiembre terminarán parcheadas. La arquitectura de seguridad que quede después de aplicar esos parches será la que determine cómo afrontará la red el siguiente fallo que todavía no conocemos.
Fuentes del incidente de septiembre de 2026 y «MikroTrick»
[1] MikroTik — September 2026 vulnerability
Aviso oficial del fabricante publicado el 3 de septiembre de 2026. Confirma la existencia de la vulnerabilidad, las primeras versiones corregidas y la comprobación mediante Flagged después de actualizar.
https://mikrotik.com/supportsec/september-2026-vulnerability/
[2] MikroTik — RouterOS Changelogs
Registro oficial de versiones de RouterOS. Permite comprobar las fechas y canales de 7.24.2, 7.23.4, 7.23.5, 7.25beta3 y 6.49.21.
https://mikrotik.com/download/changelogs
[3] MikroTik — RouterOS Downloads
Página oficial de descargas. El changelog de RouterOS 7.23.5 confirma que 7.23.4 era una actualización de seguridad y que 7.23.5 corrigió adicionalmente el problema introducido en DHCP sobre IPv6.
https://mikrotik.com/download/routeros
[4] CERT Polska — Critical vulnerabilities in MikroTik RouterOS are being actively exploited. Immediate update recommended
Fuente principal para la explotación activa de «MikroTrick», los IOC, el usuario ops, las IP observadas, el mecanismo Flagged, las recomendaciones de respuesta y el uso de IA durante la investigación.
https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
[5] CERT Polska — Vulnerabilities in MikroTik RouterOS software
Análisis técnico de las seis vulnerabilidades: condiciones de explotación, causa raíz, versiones afectadas y versiones corregidas.
https://cert.pl/en/posts/2026/09/mikrotik-routeros-cve/
[6] CERT Polska — MikroTik: securing logs and configuration
Procedimiento de preservación de logs y exportación de configuración para el análisis de un dispositivo potencialmente comprometido.
https://wiedza.cert.pl/obsluga-incydentow/zabezpieczanie-danych/urzadzenia-sieciowe/zabezpieczanie-logow-i-konfiguracji-mikrotik/
[7] CERT.LV — Ataques contra routers MikroTik
CERT nacional de Letonia. Confirma actividad contra dispositivos RouterOS accesibles desde Internet y recomienda la actualización inmediata.
https://www.cert.gov.lv/lv/2026/09/papildinats-uzbruceji-pastiprinati-censas-kompromitet-mikrotik-marsrutetajus
[8] SI-CERT — SI-CERT 2026-05 / «MikroTrick»
CERT nacional de Eslovenia. Confirma conocimiento de casos de abuso de dispositivos MikroTik que mantenían SSH públicamente accesible.
https://www.cert.si/si-cert-2026-05/
Fuentes de los registros oficiales de los seis CVE de septiembre 2026
[9] CVE-2026-67276 — SSH / validación RSA
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-67276
[10] CVE-2026-67277 — bandwidth-test
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-67277
[11] CVE-2026-67278 — X.509 / RSA PKCS#1 v1.5
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-67278
[12] CVE-2026-67279 — máquina de estados SSH
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-67279
[13] CVE-2026-67281 — WebFig /jsproxy
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-67281
[14] CVE-2026-86060 — SSH / manipulación de privilegios
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-86060
Fuentes sobre la documentación oficial de MikroTik para el hardening
[15] MikroTik RouterOS Manual — Securing your router
Guía oficial de securizacion para RouterOS. Recomienda usar VPN para la administración remota, restringir servicios de gestión, deshabilitar servicios innecesarios, MAC-Telnet, MAC-WinBox, MAC-Ping y bandwidth-server.
https://manual.mikrotik.com/docs/getting-started/securing-your-router/
[16] MikroTik RouterOS Manual — Services
Referencia oficial de /ip/service. Documenta SSH, WebFig, WinBox, API/API-SSL, puertos utilizados y la restricción mediante address. MikroTik recomienda firewall para bloquear redes externas o no confiables.
https://manual.mikrotik.com/docs/system-information-and-utilities/services/
[17] MikroTik RouterOS Manual — Device mode
Documentación actual del mecanismo /system/device-mode, las funciones que pueden deshabilitarse y el campo flagged.
https://manual.mikrotik.com/docs/system-information-and-utilities/device-mode/
[18] MikroTik RouterOS Manual — WireGuard
Configuración oficial de WireGuard, peers, direccionamiento y reglas necesarias en input para permitir el establecimiento del túnel.
https://manual.mikrotik.com/docs/virtual-private-networks/wireguard/
[19] MikroTik RouterOS Manual — SSH
Documentación del servidor SSH de RouterOS y autenticación mediante claves públicas.
https://manual.mikrotik.com/docs/management-tools/ssh/
[20] MikroTik RouterOS Manual — Securing your router / SSH strong crypto
Incluye la recomendación oficial para activar:
/ip/ssh/set strong-crypto=yes
https://manual.mikrotik.com/docs/getting-started/securing-your-router
[21] MikroTik RouterOS Manual — Bandwidth server
Referencia de /tool/bandwidth-server, incluido el parámetro enabled utilizado para desactivar el servicio afectado por CVE-2026-67277.
https://manual.mikrotik.com/docs/cli-reference/tool/bandwidth-server/
[22] MikroTik RouterOS Manual — Log
Documentación oficial del sistema de logs y de su envío a servidores remotos mediante Syslog/CEF.
https://manual.mikrotik.com/docs/diagnostics-monitoring-and-troubleshooting/log/
[23] MikroTik RouterOS Manual — RouterOS Update
Referencia oficial de /system/package/update, incluidos los canales stable, long-term, testing y development.
https://manual.mikrotik.com/docs/cli-reference/system/package/update/
[24] MikroTik RouterOS Manual — RouterBOOT
Procedimiento oficial para actualizar RouterBOOT después de actualizar RouterOS mediante:
/system/routerboard/upgrade
https://manual.mikrotik.com/docs/getting-started/installation-and-upgrade/routerboot
[25] MikroTik RouterOS Manual — MAC server
Documenta MAC-Telnet, MAC-WinBox y MAC-Ping y cómo limitarlos a determinadas interfaces o deshabilitarlos.
https://manual.mikrotik.com/docs/management-tools/mac-server/
[26] MikroTik RouterOS Manual — Neighbor Discovery
Documenta MNDP, CDP y LLDP y el uso de discover-interface-list para restringir la exposición de información en capa 2.
https://manual.mikrotik.com/docs/system-information-and-utilities/neighbor-discovery/
[27] MikroTik RouterOS Manual — First Time Configuration
La documentación oficial recomienda no exponer directamente la administración a Internet y utilizar métodos seguros como WireGuard o IPsec.
https://manual.mikrotik.com/docs/getting-started/first-time-configuration/
Fuentes de las vulnerabilidades anteriores de RouterOS durante 2026
[28] Patrik Žák — Finding an Integer Overflow in MikroTik RouterOS Core IPC Library
Investigación técnica original de CVE-2026-39042. Documenta el fallo en nv::message::unflatten() de libumsg.so, las pruebas realizadas y las versiones corregidas 7.21.4 y 7.22.2.
https://zakpatrik.cz/blog/finding-an-integer-overflow-in-mikrotik-routeros-core-ipc-library
[29] CVE-2026-39042 — Registro oficial
CVE.org:
https://www.cve.org/CVERecord?id=CVE-2026-39042
[30] INCIBE-CERT — Restricción insuficiente de intentos de autenticación en productos MikroTik
Aviso INCIBE-2026-515 correspondiente a CVE-2026-16347. Explica el riesgo de intentos masivos de autenticación y recomienda no exponer la API directamente a Internet.
https://www.incibe.es/incibe-cert/alerta-temprana/avisos-sci/restriccion-insuficiente-de-intentos-de-autenticacion-en-productos-de-mikrotik
[31] CISA — ICSA-26-209-05: MikroTik RouterOS and Cloud Hosted Router
Aviso oficial estadounidense correspondiente a CVE-2026-16347.
https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-05
Registro CVE:
https://www.cve.org/CVERecord?id=CVE-2026-16347
[32] CISA — ICSA-26-211-01: MikroTik RouterOS
Aviso oficial de CISA que incluye CVE-2026-14227, relacionado con la conservación de permisos en sesiones API después de modificar los privilegios del usuario.
https://www.cisa.gov/news-events/ics-advisories/icsa-26-211-01
Registro CVE:
https://www.cve.org/CVERecord?id=CVE-2026-14227
[33] INCIBE-CERT — CVE-2026-7668
Vulnerabilidad del endpoint SCEP de RouterOS 6.49.8. INCIBE-CERT documenta la lectura fuera de límites, la disponibilidad de una PoC y un CVSS v4 de 5,5.
https://www.incibe.es/en/incibe-cert/early-warning/vulnerabilities/cve-2026-7668
Registro CVE:
https://www.cve.org/CVERecord?id=CVE-2026-7668
[34] SI-CERT — CVE-2025-42611
Investigación sobre la validación de certificados y el uso compartido del trust store de RouterOS entre OpenVPN, CAPsMAN, 802.1X y otros servicios. Fue divulgada públicamente por SI-CERT en abril de 2026.
https://www.cert.si/en/cve-2025-42611/
Registro CVE:
https://www.cve.org/CVERecord?id=CVE-2025-42611
