Ataque a routers MikroTik: qué es MikroTrick y qué vulnerabilidades explota

Un ataque contra routers MikroTik ha puesto el foco sobre RouterOS después de que CERT Polska confirmara ataques reales contra dispositivos accesibles desde Internet. El problema no es una única vulnerabilidad aislada: el nombre MikroTrick identifica una cadena de fallos que puede llevar desde una conexión SSH no autenticada hasta el control administrativo del router. El caso es especialmente relevante porque los investigadores observaron indicios de explotación antes de que se publicaran los parches.

La situación merece una explicación cuidadosa. MikroTik publicó el 3 de septiembre de 2026 una actualización de seguridad urgente, pero inicialmente no detalló las vulnerabilidades para dar tiempo a los administradores a actualizar. CERT Polska publicó después el análisis y confirmó que había observado ataques contra RouterOS expuesto a Internet. Por tanto, no estamos ante una simple vulnerabilidad teórica descubierta en un laboratorio: existe evidencia de explotación de determinadas configuraciones vulnerables. El aviso inicial puede consultarse en la comunicación de seguridad de MikroTik y en el aviso de CERT Polska sobre la explotación activa.

Qué es exactamente el ataque MikroTrick contra MikroTik

MikroTrick es el nombre que CERT Polska dio a una cadena de vulnerabilidades de RouterOS. Su elemento central afecta al acceso SSH del router y, en determinadas versiones, permite avanzar por el protocolo hasta una fase que debería estar disponible únicamente después de una autenticación correcta. Un segundo fallo permite manipular el proceso que crea la sesión para conseguir privilegios administrativos.

Lo importante para entender el riesgo es que no se trata simplemente de «un fallo de SSH». La primera vulnerabilidad de la cadena, CVE-2026-67279, afecta al manejo de una renegociación de claves durante la autenticación. Según el análisis de CERT Polska, RouterOS podía pasar a la fase de sesión antes de que el usuario hubiera completado la autenticación. Esa transición indebida dejaba disponible una capacidad que normalmente solo aparece después de identificarse correctamente.

El segundo componente, CVE-2026-86060, afecta al tratamiento de determinados nombres de usuario durante el inicio de sesión SSH. El problema podía hacer que información controlada por el atacante terminara influyendo en los privilegios con los que se iniciaba la sesión. Combinadas, las dos vulnerabilidades podían proporcionar acceso administrativo sin conocer la contraseña ni disponer de una clave SSH válida.

Este matiz es importante porque algunas informaciones publicadas inicialmente relacionaron MikroTrick con CVE-2026-67276. CERT Polska aclaró posteriormente que esa vulnerabilidad es diferente: afecta a la validación de claves públicas RSA y puede permitir suplantar una cuenta concreta cuando se conocen determinados datos de su clave. No es la misma cadena que permitió el acceso administrativo observado en MikroTrick.

La cadena MikroTrick combina fallos relacionados con el manejo de SSH en RouterOS.

Qué vulnerabilidades de RouterOS se han descubierto

La investigación de CERT Polska identificó seis vulnerabilidades en RouterOS. No todas tienen el mismo impacto ni forman parte de la cadena MikroTrick, y distinguirlas evita presentar el incidente como si existiera un único fallo que afectara de la misma manera a todos los routers.

CVE-2026-67279: acceso a la fase de sesión SSH sin autenticación completa

Este fallo afecta a la máquina de estados del servidor SSH. RouterOS podía gestionar de forma incorrecta una renegociación de claves iniciada durante la autenticación y pasar a la fase de canales antes de haber recibido una autenticación válida. CERT Polska explica que ese comportamiento era un requisito previo para la siguiente vulnerabilidad de la cadena.

En términos sencillos, el router podía llegar a comportarse como si una parte del proceso de autenticación ya hubiera terminado cuando todavía no había concedido realmente la identidad al usuario. Esa diferencia entre el estado real y el estado que asumía el software es el núcleo del problema.

CVE-2026-86060: escalada de privilegios en el proceso de inicio de sesión

El segundo fallo estaba relacionado con la forma en que RouterOS pasaba determinados parámetros al componente que crea la consola. Un nombre de usuario especialmente manipulado podía ser interpretado de una forma que alteraba la máscara de políticas utilizada para determinar los privilegios.

La consecuencia, cuando se combinaba con CVE-2026-67279, era especialmente grave: una conexión que no había completado la autenticación podía terminar con privilegios administrativos. CERT Polska asignó a esta vulnerabilidad una puntuación CVSS de 9,2 y confirmó que había sido utilizada dentro de la cadena MikroTrick.

CVE-2026-67276: un problema diferente con las claves RSA

Esta vulnerabilidad también afecta a SSH, pero su funcionamiento es distinto. RouterOS no verificaba todos los componentes de una clave pública RSA al relacionarla con la clave autorizada de un usuario. En determinadas circunstancias, conocer el nombre de la cuenta y el módulo público permitía construir una clave diferente que superara la comprobación.

El acceso conseguido correspondía a la cuenta atacada, por lo que el impacto dependía de los privilegios de esa cuenta. CERT Polska la calificó con CVSS 9,2. Es una vulnerabilidad seria, pero no debe confundirse con la cadena MikroTrick que proporciona privilegios administrativos sin autenticación completa.

CVE-2026-67277: el servicio bandwidth-test

Otra vulnerabilidad afectaba al servicio de pruebas de ancho de banda de RouterOS. CERT Polska documentó un problema que permitía a una conexión no autenticada alcanzar un estado que debía requerir autenticación, con posibilidades de provocar exposición de información de memoria y reinicios del sistema.

Este fallo tampoco debe presentarse como sinónimo de MikroTrick. Forma parte de la investigación general sobre RouterOS y fue una de las vulnerabilidades incorporadas posteriormente al catálogo de vulnerabilidades explotadas conocidas de CISA, según el análisis publicado por CERT Polska.

CVE-2026-67278 y CVE-2026-67281: certificados y WebFig

La investigación también encontró un problema en la validación de determinadas firmas RSA, identificado como CVE-2026-67278, que afectaba a servicios relacionados con TLS/X.509 y autenticación SSH basada en RSA. CERT Polska señala que las versiones 7.23.4 y 7.24.2 contenían una corrección incompleta y que posteriormente se publicaron correcciones adicionales en 7.23.6 y 7.24.3.

Por otra parte, CVE-2026-67281 afectaba a WebFig y podía permitir lectura no autenticada de archivos en determinadas condiciones. Son problemas importantes, pero forman parte del conjunto de vulnerabilidades descubiertas durante la investigación, no de una única explotación que deba atribuirse automáticamente a todos los routers MikroTik.

Qué routers están realmente expuestos

La palabra clave es exposición. CERT Polska confirmó ataques contra dispositivos RouterOS cuya interfaz SSH estaba accesible desde redes públicas. MikroTik, por su parte, señala que la configuración predeterminada bloquea el acceso desde Internet y que la mayoría de configuraciones domésticas no estaban en riesgo inmediato. Eso no significa que la actualización pueda ignorarse: significa que el nivel de exposición depende de la configuración concreta.

El riesgo aumenta cuando un administrador ha abierto SSH hacia Internet para poder gestionar el router remotamente. Una práctica más segura consiste en mantener los servicios de administración fuera de Internet y acceder mediante una VPN cuando sea necesario. MikroTik recomienda expresamente no exponer los puertos de administración a redes no confiables.

También conviene evitar una conclusión demasiado simple del tipo «si SSH no está abierto, no pasa nada». La investigación descubrió otras vulnerabilidades con superficies de ataque diferentes. La seguridad de RouterOS no depende de un único puerto, sino de mantener el sistema actualizado y reducir los servicios innecesarios o expuestos.

Cómo se detectaron los ataques

Uno de los aspectos más interesantes del caso es que los investigadores no se limitaron a estudiar el código corregido. CERT Polska comparó versiones vulnerables y parcheadas de RouterOS, revisó registros publicados por administradores y relacionó cambios internos del sistema con indicadores observados en dispositivos reales.

Entre los indicios aparecía una secuencia de eventos asociada a un intento de inicio de sesión SSH y a la creación de una cuenta administrativa denominada ops. El análisis posterior relacionó esos registros con la cadena MikroTrick. CERT Polska sitúa los primeros registros públicos disponibles el 2 de septiembre, antes de la publicación de los parches del día siguiente. El análisis técnico posterior de CERT Polska explica con más detalle cómo se reconstruyó la cadena y cómo se relacionaron los registros observados con las vulnerabilidades.

El análisis técnico de CERT Polska sobre MikroTrick describe además cómo la comparación entre versiones parcheadas y vulnerables ayudó a identificar el segundo componente de la cadena.

MikroTik incorporó además comprobaciones en RouterOS para detectar determinadas configuraciones sospechosas y activar el estado Flagged. La documentación oficial explica que este mecanismo analiza la configuración durante el arranque y puede deshabilitar elementos considerados sospechosos. Si aparece ese estado, el fabricante indica que debe asumirse que el dispositivo puede haber sido comprometido y realizar una auditoría completa antes de volver a utilizarlo con normalidad.

Actualizar RouterOS y revisar la configuración son pasos complementarios ante un posible compromiso.

La respuesta de MikroTik: parches y detección de compromiso

MikroTik publicó el 3 de septiembre de 2026 las versiones corregidas para las ramas mantenidas que figuraban en su aviso inicial: 7.25 beta 3, 7.24.2, 7.23.4 y 6.49.21. El fabricante calificó la actualización como importante y recomendó actualizar incluso a los usuarios domésticos.

La respuesta no terminó con la publicación de los parches. MikroTik indicó que RouterOS podía comprobar si el dispositivo presentaba signos de compromiso y marcarlo como Flagged. También recomendó revisar después de la actualización la existencia de usuarios, scripts o configuraciones desconocidas.

Hay, además, una evolución relevante en las versiones. La investigación posterior de CERT Polska estableció que CVE-2026-67278 necesitaba una corrección adicional: las versiones 7.23.4 y 7.24.2 no resolvían completamente ese problema y las correcciones correspondientes quedaron incorporadas en 7.23.6 y 7.24.3. Por eso, cuando se hable del estado actual de RouterOS, no basta con repetir el número de versión del primer aviso de septiembre: hay que comprobar la rama y la versión concreta instalada.

El fabricante también publicó posteriormente información sobre otra vulnerabilidad, CVE-2026-52346, relacionada con la inspección de tráfico TLS en determinadas reglas de firewall. MikroTik indica que fue corregida en 7.22.2 y 7.21.4 y que el escenario de explotación es más limitado. Este problema es posterior al aviso de MikroTrick y conviene mantenerlo separado para no mezclar incidentes distintos.

Qué debería comprobar un administrador de MikroTik

La primera medida es comprobar la versión de RouterOS y actualizar a una versión corregida y mantenida. No se trata únicamente de instalar el parche y dar el incidente por cerrado: si el dispositivo ya hubiera sido comprometido antes de la actualización, la vulnerabilidad puede haber sido utilizada para modificar su configuración.

Después de actualizar, conviene revisar especialmente las cuentas de usuario, tareas programadas, scripts, reglas y servicios que no reconozca el administrador. MikroTik recomienda realizar esta comprobación incluso cuando el dispositivo no aparezca marcado como Flagged. El mecanismo de detección es una ayuda, no una sustitución de la auditoría. MikroTik explica el funcionamiento de este sistema en su documentación actual sobre Device Mode y el estado Flagged.

También es importante revisar la exposición de SSH y de las interfaces de administración. Si el acceso remoto es necesario, MikroTik recomienda utilizar una VPN como WireGuard en lugar de dejar los puertos de administración abiertos a Internet. La configuración predeterminada del firewall ya bloquea el acceso WAN en muchos escenarios, pero una modificación manual puede cambiar por completo ese nivel de protección.

Por último, si el dispositivo aparece en estado Flagged, no conviene limitarse a desactivar la marca. La documentación de MikroTik indica que primero debe revisarse toda la configuración, asumirse un posible compromiso, cambiar las contraseñas y actualizar RouterOS antes de devolver el equipo a su funcionamiento habitual.

Qué significa el caso para una pequeña empresa

Un router suele quedar fuera de las revisiones de seguridad porque funciona durante años y apenas requiere atención. Esta misma lógica aparece en la guía sobre seguridad de WordPress y dependencias de terceros: una infraestructura mantenida exige revisar también aquello que normalmente funciona en segundo plano. Sin embargo, en una pequeña empresa puede ser uno de los dispositivos más importantes de la red: controla el acceso a Internet, aplica reglas de firewall, puede proporcionar VPN y, dependiendo de la configuración, participa en túneles y otros servicios de infraestructura.

El caso MikroTrick demuestra por qué el mantenimiento del firmware debe formar parte de la seguridad general. Es una idea relacionada con la que desarrollamos al hablar de cómo están cambiando las amenazas digitales en 2026: el ataque puede ser sofisticado, pero muchas defensas básicas siguen siendo decisivas. Tener una contraseña fuerte no compensa una vulnerabilidad que permite saltarse la autenticación. Del mismo modo, instalar un firewall no elimina el riesgo de un servicio que el propio administrador haya decidido exponer para facilitar la gestión remota.

La lección es especialmente aplicable a una web profesional o a una pequeña oficina con varios servicios conectados. La seguridad funciona mejor como una cadena: sistema actualizado, superficie de exposición reducida, autenticación adecuada, copias de seguridad, registros y una revisión periódica de los cambios. Una sola medida rara vez resuelve todo el problema. Para una visión más general, también resulta útil revisar los principios básicos para mantener una web segura, aunque el router y el sitio web tengan superficies de ataque diferentes.

Una vulnerabilidad de router no equivale a que todos los MikroTik estén comprometidos

Los titulares sobre ataques a dispositivos de red pueden transmitir la impresión de que cualquier router de la marca está automáticamente infectado. La evidencia disponible no permite afirmar eso. CERT Polska describe ataques observados contra dispositivos accesibles desde Internet, mientras que MikroTik señala que las configuraciones domésticas predeterminadas no estaban en riesgo inmediato por el vector SSH concreto.

La distinción importa porque permite actuar con criterio. Un dispositivo actualizado y con la administración correctamente restringida tiene un escenario muy diferente al de un RouterOS vulnerable con SSH expuesto públicamente. La prioridad debe ser conocer la configuración real del equipo y no asumir que todos los dispositivos presentan el mismo riesgo.

Conclusión: MikroTrick deja una lección que va más allá de MikroTik

El incidente MikroTrick es relevante porque muestra cómo varios errores aparentemente concretos pueden combinarse hasta producir un resultado mucho más grave. En este caso, un problema en la gestión del estado de SSH y otro en el tratamiento de parámetros del proceso de inicio de sesión llegaron a formar una cadena capaz de proporcionar privilegios administrativos sin autenticación completa.

También deja una segunda lección: publicar un parche no significa que el trabajo haya terminado. Cuando existe explotación previa, es necesario comprobar si el dispositivo fue modificado antes de actualizarlo. El estado Flagged de RouterOS, la revisión de usuarios y configuraciones y la reducción de servicios expuestos forman parte de esa segunda fase.

Para cualquier administrador de una red pequeña, la conclusión práctica es sencilla: RouterOS debe mantenerse actualizado, la administración no debería quedar expuesta innecesariamente a Internet y cualquier indicio de modificación desconocida debe investigarse antes de considerar el incidente cerrado. La documentación oficial de MikroTik y los avisos de CERT Polska son las referencias que conviene consultar para comprobar el estado concreto de cada versión.

Preguntas frecuentes sobre el ataque a MikroTik

¿Qué es MikroTrick?

MikroTrick es el nombre dado por CERT Polska a una cadena de vulnerabilidades de RouterOS que podía permitir acceso administrativo sin autenticación completa cuando el servicio SSH estaba expuesto y se combinaban determinados fallos.

¿Todos los routers MikroTik están afectados?

No. El riesgo depende de la versión de RouterOS, de los servicios habilitados y de cómo esté expuesto el dispositivo. El vector principal observado por CERT Polska afectaba especialmente a equipos con SSH accesible desde redes públicas.

¿Actualizar RouterOS es suficiente?

Es una medida esencial, pero no siempre suficiente si existe sospecha de compromiso previo. Después de actualizar hay que revisar usuarios, scripts y configuraciones desconocidas y prestar atención al estado Flagged del dispositivo.

¿Qué hago si mi MikroTik aparece como Flagged?

Debe tratarse como una posible evidencia de compromiso. MikroTik recomienda auditar la configuración, cambiar las credenciales y actualizar el sistema antes de retirar el estado de protección.

En proyectos web profesionales, la seguridad del router, del alojamiento y del propio WordPress forman parte de una misma cadena. Una arquitectura bien diseñada y mantenida reduce los puntos de exposición y facilita detectar problemas antes de que se conviertan en incidentes mayores.