MikroTik RouterOS: una vulnerabilidad crítica permite ejecutar código como root sin autenticación

Un router expuesto a Internet acaba de convertirse en una posible puerta de entrada completa a la red. CISA ha publicado este 29 de septiembre de 2026 el aviso ICSA-26-272-06 sobre una vulnerabilidad crítica en MikroTik RouterOS que permite a un atacante remoto no autenticado ejecutar código arbitrario como root o provocar una denegación de servicio mediante una única petición HTTP manipulada.

La vulnerabilidad es CVE-2026-84411, tiene una puntuación CVSS 3.1 de 9,8 y afecta, según la ficha de CISA, a las versiones de RouterOS anteriores a la 7.24. El fallo reside en el servicio de gestión web y puede explotarse antes de superar cualquier control de autenticación. Traducido a lenguaje operativo: si la interfaz vulnerable está accesible desde una red atacante, no hace falta tener credenciales, interacción del usuario ni una cadena especialmente sofisticada de exploits.

El aviso contiene además una inconsistencia que las empresas no deberían resolver a golpe de intuición. CISA identifica como afectadas las versiones RouterOS <7.24, pero la recomendación de MikroTik recogida en la misma alerta indica actualizar a la versión 7.23 o posterior. La 7.23 seguiría estando dentro del rango aparentemente vulnerable. Hasta que MikroTik o CISA aclaren ese punto, la referencia prudente es instalar una versión que esté expresamente confirmada como corregida y verificar el estado en los canales oficiales del fabricante. “Actualizar a 7.23” no es una instrucción suficientemente segura cuando la propia tabla de productos dice “menor que 7.24”.

Qué se sabe del fallo y por qué el riesgo es tan alto

CVE-2026-84411 es un integer underflow, clasificado como CWE-191. El error aparece en el tratamiento del cuerpo de las peticiones HTTP que recibe el servicio de gestión web de RouterOS. Un underflow de enteros se produce cuando una operación aritmética genera un valor inferior al mínimo que puede representar el tipo de dato utilizado. En código que calcula tamaños, desplazamientos o límites de memoria, ese resultado puede transformarse en una validación defectuosa y abrir la puerta a lecturas, escrituras o asignaciones de memoria incorrectas.

La ficha de CISA no describe públicamente una cadena técnica completa ni incluye un exploit de prueba. Sí confirma los elementos que determinan la gravedad operativa: el servicio es alcanzable antes de la autenticación, el atacante puede enviar una única petición especialmente construida y el resultado potencial es ejecución remota de código como root o denegación de servicio.

Esos cuatro datos importan más que la etiqueta “crítica”:

• Acceso remoto: el atacante no necesita estar físicamente conectado al dispositivo.
• Baja complejidad: el vector CVSS indica AC:L, es decir, no exige condiciones técnicas extraordinarias.
• Sin privilegios ni interacción: el vector recoge PR:N y UI:N.
• Impacto completo: confidencialidad, integridad y disponibilidad aparecen calificadas como altas.

El vector CVSS 3.1 publicado por CISA es CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, con una puntuación de 9,8. La métrica CVSS 4.0 asigna un 9,3 y mantiene el diagnóstico esencial: explotación por red, sin autenticación, sin interacción y con impacto alto sobre la confidencialidad, integridad y disponibilidad.

La ejecución como root es el detalle que cambia la conversación. No estamos ante una vulnerabilidad que permita únicamente modificar una opción concreta del panel de administración. En un dispositivo comprometido con privilegios máximos, el atacante puede intentar alterar la configuración de red, crear persistencia, manipular reglas de filtrado, redirigir tráfico, capturar credenciales, desactivar registros o utilizar el router como punto de salto hacia otros sistemas. CISA no afirma que todas esas acciones hayan sido observadas en ataques reales contra este CVE; son consecuencias técnicas plausibles de obtener ejecución remota con privilegios de root y deben formar parte del análisis de impacto.

El problema más peligroso puede ser la exposición, no el parche

La pregunta urgente no es solo qué versión ejecuta cada dispositivo. Es otra: ¿quién puede llegar al servicio de gestión web?

Los routers MikroTik suelen ocupar posiciones con una visibilidad privilegiada: oficinas pequeñas, sucursales, redes industriales, proveedores de servicios, enlaces remotos, centros de datos y entornos domésticos utilizados para acceder a recursos corporativos. La misma interfaz que facilita la administración remota puede convertir una dirección IP pública en una superficie de ataque permanente.

CISA recomienda minimizar la exposición de los dispositivos de control y sistemas asociados, situar las redes de control y los dispositivos remotos detrás de cortafuegos, aislarlos de las redes corporativas y utilizar métodos de acceso más seguros, como VPN actualizadas. La recomendación incluye una advertencia que suele desaparecer en las presentaciones corporativas: una VPN solo es tan segura como los dispositivos conectados a ella. Si el portátil desde el que se administra el router está comprometido, el túnel no convierte la operación en segura por arte de magia.

La exposición puede producirse de varias formas:

• La interfaz web de RouterOS publicada directamente en Internet.
• Un puerto de gestión accesible desde una red de proveedores o de mantenimiento.
• Una regla de cortafuegos demasiado amplia que permita tráfico desde cualquier origen.
• Una dirección IPv6 públicamente enrutable que no aparezca en los inventarios tradicionales.
• Un servicio de gestión accesible desde una red inalámbrica, una red de invitados o una VLAN mal segmentada.
• Un túnel VPN que transporte tráfico de administración sin restricciones adicionales.

Buscar únicamente dispositivos con una dirección IPv4 pública sería insuficiente. La verificación debe cubrir IPv4, IPv6, NAT, reglas de redirección de puertos, servicios de gestión alternativos y accesos desde redes de terceros. Un dispositivo “no expuesto” desde la oficina central puede estarlo desde el proveedor que mantiene una sucursal, desde una red de operaciones o desde una interfaz de administración olvidada.

Aquí aparece una ironía recurrente de la gestión de vulnerabilidades: muchas organizaciones creen que han reducido el riesgo porque nadie usa el panel web a diario. Eso no demuestra que el servicio no esté escuchando. La ausencia de usuarios legítimos no elimina la presencia de atacantes potenciales.

La contradicción de las versiones exige una decisión conservadora

La alerta publicada el 29 de septiembre de 2026 contiene dos indicaciones difíciles de reconciliar. En “Affected Products”, CISA identifica como afectados los productos MikroTik RouterOS <7.24. En “Remediations”, recoge que MikroTik recomienda actualizar a la versión 7.23 o posterior.

Puede tratarse de un error de transcripción, de una diferencia entre ramas de mantenimiento o de una actualización de la recomendación que todavía no se ha reflejado en la tabla. La fuente facilitada no lo explica. Por eso no sería responsable afirmar que 7.23 corrige CVE-2026-84411. La conclusión operativa, hasta disponer de una aclaración formal, debería ser:

1. Identificar todos los dispositivos que ejecuten una versión anterior a 7.24.
2. Consultar la página oficial de descargas y los avisos de MikroTik para confirmar cuál es la versión corregida.
3. Priorizar una versión que el fabricante declare expresamente no afectada, no simplemente una versión incluida en la frase “7.23 o posterior”.
4. Si no es posible actualizar de inmediato, retirar la exposición del servicio web y limitar la administración a una ruta de gestión controlada.
5. Registrar la decisión, la fuente consultada y la versión finalmente instalada.

La diferencia entre “7.23 o posterior” y “7.24 o posterior” no es un matiz editorial. Puede cambiar el resultado de un escaneo de cumplimiento, la cobertura de una campaña de parcheo y la conclusión de un auditor. También puede dejar a una organización con una falsa sensación de remediación mientras el activo continúa dentro del rango vulnerable descrito por CISA.

Las empresas no deberían sustituir una versión por otra sin validar compatibilidad. RouterOS puede integrarse con reglas de cortafuegos, BGP, OSPF, VLAN, colas de tráfico, autenticación externa, túneles y sistemas de monitorización. El parcheo de un router crítico exige copia de seguridad de la configuración, revisión de la ruta de recuperación, acceso alternativo y una ventana de cambio suficientemente controlada. Eso no significa aplazarlo indefinidamente. Significa evitar que una corrección de seguridad provoque una interrupción que nadie haya preparado para gestionar.

Qué debe hacer ahora un equipo de seguridad

La respuesta efectiva no empieza con un correo genérico pidiendo a todos los administradores que “revisen MikroTik”. Empieza con una fotografía fiable del parque instalado.

1. Localizar los activos, incluidos los que no aparecen en el CMDB

El inventario debe cruzar la base de activos con datos de descubrimiento de red, registros de proveedores, configuraciones de cortafuegos, sistemas de monitorización y contratos de conectividad. El objetivo es obtener, como mínimo, el modelo del dispositivo, número de serie o identificador interno, versión exacta de RouterOS, ubicación, propietario, dirección IP de gestión, exposición externa, función y dependencia de negocio.

Si la organización utiliza MikroTik en sucursales o instalaciones gestionadas por terceros, el activo no desaparece del perímetro de responsabilidad porque otra empresa pulse el botón de actualización. Hay que solicitar evidencia: versión instalada, fecha del cambio, copia del registro y confirmación de que el servicio web no queda accesible desde Internet.

La versión debe comprobarse en el propio dispositivo o mediante una fuente de gestión fiable. Un inventario con el dato “MikroTik, versión desconocida” no es una respuesta al CVE; es una tarea pendiente con formato de inventario.

2. Medir la exposición antes de clasificar la urgencia

Un RouterOS vulnerable con administración web accesible desde Internet debe ocupar la prioridad máxima. Uno vulnerable pero aislado en una red de gestión restringida sigue requiriendo parche, aunque el riesgo inmediato pueda ser menor. Un dispositivo utilizado para conectar una red industrial, un centro de datos, una entidad financiera o una infraestructura de comunicaciones merece una evaluación adicional por el impacto de una interrupción o una intrusión lateral.

La evaluación debe documentar quién puede llegar al servicio, desde qué rangos de red, mediante qué protocolo y con qué controles intermedios. No basta con afirmar que “hay firewall”. Debe existir una regla verificable que permita responder si el tráfico HTTP o HTTPS de administración está limitado a direcciones concretas y si los registros muestran intentos desde orígenes no autorizados.

3. Aplicar la contención que CISA ya recomienda

La primera medida es retirar la interfaz de gestión de Internet. Después, restringirla a una red de administración o a una VPN con autenticación robusta, segmentar el dispositivo de las redes corporativas y bloquear accesos innecesarios. La protección debe aplicarse también a las rutas IPv6 y a cualquier mecanismo de publicación indirecta.

Desactivar un servicio no utilizado puede reducir la superficie, pero no debe presentarse como sustituto universal del parche. La organización debe confirmar qué componente queda activo, qué puertos escucha y si otros servicios de RouterOS comparten el mismo proceso o superficie de gestión. Si el servicio web es necesario para una operación concreta, la alternativa no es dejarlo abierto: consiste en limitar los orígenes autorizados y planificar la actualización.

4. Parchear y validar la recuperación

Antes del cambio, conviene conservar una copia de la configuración y anotar la versión anterior, la fecha, el responsable y el método de recuperación. Después, hay que comprobar no solo que el router arranca, sino que mantiene las funciones críticas: encaminamiento, filtrado, resolución, VPN, redundancia, sincronización horaria, exportación de registros y conectividad con los sistemas dependientes.

La validación de seguridad debe incluir una nueva comprobación de versión, revisión de los servicios expuestos, comparación de reglas de cortafuegos y confirmación de que las credenciales y claves de administración siguen siendo las esperadas. Si el dispositivo estuvo expuesto durante un periodo desconocido, el parche no borra la posibilidad de compromiso previo.

Cómo investigar si ya hubo explotación

CISA indica que no se ha comunicado explotación pública específicamente dirigida contra esta vulnerabilidad en la fecha de publicación del aviso. Esa frase no equivale a “no ha ocurrido ningún ataque”. Significa que CISA no dispone de un informe público de explotación específica. La diferencia importa, especialmente cuando el activo puede haber estado expuesto a Internet.

La investigación debería empezar por la ventana de exposición: cuándo se instaló la versión afectada, cuándo fue accesible el servicio de gestión y cuándo se aplicaron cambios de red. A continuación, el equipo debe revisar:

• Registros HTTP y de gestión del router, si estaban habilitados y conservados.
• Peticiónes anómalas, errores repetidos, cuerpos HTTP inusuales o accesos desde orígenes no reconocidos.
• Cambios no autorizados en reglas de firewall, usuarios, grupos, rutas, DNS, NAT, scripts y tareas programadas.
• Creación o modificación de cuentas con privilegios administrativos.
• Conexiones salientes inesperadas desde el dispositivo.
• Cambios de configuración que puedan desviar tráfico o facilitar movimiento lateral.
• Alertas de sistemas situados detrás del router durante el mismo periodo.

La ausencia de logs no debe interpretarse como ausencia de actividad. En muchos dispositivos de red, la retención es limitada y los registros pueden sobrescribirse. Si existe sospecha razonable de compromiso, la organización debe preservar la configuración actual, exportar los registros disponibles, evitar cambios innecesarios y aplicar su procedimiento de respuesta a incidentes. Reiniciar o restaurar el equipo puede eliminar evidencias útiles, aunque a veces sea necesario para recuperar el servicio. La decisión debe tomarla el responsable de respuesta junto con el propietario operativo, no el primer administrador disponible.

Una intrusión con privilegios de root obliga a revisar algo más que el router. Deben rotarse las credenciales almacenadas o utilizadas para administrarlo, las claves de VPN y cualquier secreto que pudiera haber quedado accesible en la configuración. También conviene comprobar si el dispositivo tenía acceso a sistemas de autenticación, servidores de monitorización, redes de proveedores o segmentos que alberguen información sensible.

Qué significa para DORA, NIS2 y los controles internos

La alerta no convierte automáticamente a todas las organizaciones que usan MikroTik en entidades reguladas. Sí puede activar obligaciones o controles ya existentes si el dispositivo forma parte de un servicio sujeto a requisitos de resiliencia, gestión de riesgos o notificación de incidentes.

Para una entidad financiera dentro del ámbito de DORA, el análisis encaja principalmente con el capítulo de gestión del riesgo de las TIC y la gestión de incidentes. El artículo 6 del Reglamento (UE) 2022/2554 exige un marco de gestión del riesgo de las TIC; el artículo 17 regula el proceso de gestión y clasificación de incidentes relacionados con las TIC; y el artículo 19 establece la notificación de incidentes graves a la autoridad competente. No todo intento contra un router será un incidente grave notificable. La clasificación dependerá del impacto, los servicios afectados, la duración, los clientes y otros criterios aplicables. Pero una posible ejecución como root en un dispositivo que conecta sistemas críticos no debería cerrarse como “parche aplicado” sin análisis documentado.

DORA también exige controlar los riesgos asociados a terceros TIC. El artículo 28 obliga a las entidades financieras a gestionar el riesgo contractual y operativo de proveedores TIC. Si una red de sucursales o un dispositivo esencial es operado por un proveedor externo, el equipo de cumplimiento debería poder demostrar quién recibió el aviso, qué plazo de corrección se estableció, qué versión se instaló y cómo se comprobó la exposición residual.

En organizaciones sujetas a NIS2, el artículo 21 exige medidas técnicas, operativas y organizativas proporcionadas para gestionar los riesgos que afectan a la seguridad de las redes y sistemas de información. La gestión de vulnerabilidades, el tratamiento de incidentes, la continuidad y la seguridad de la cadena de suministro forman parte de ese análisis. El artículo 23 establece obligaciones de notificación para incidentes significativos, con un aviso temprano en un plazo de 24 horas desde que la entidad tenga conocimiento de un incidente significativo y una notificación de incidente en un plazo de 72 horas, además de un informe final posterior conforme al esquema de la directiva y su transposición nacional. Esos plazos no se activan por leer un CVE; se activan cuando existe un incidente que alcanza los umbrales aplicables.

Para SOX, el punto de conexión no es el CVE en sí, sino el impacto sobre controles de acceso, integridad de datos y disponibilidad de sistemas que soporten información financiera. Si el router proporciona conectividad a sistemas incluidos en el perímetro de control interno, un cambio no autorizado o una interrupción podría exigir evaluar si ha fallado un control relevante y si existen evidencias suficientes de revisión.

La respuesta, por tanto, no debería vivir únicamente en el equipo de infraestructura. Seguridad debe evaluar explotación y exposición; redes debe contener y actualizar; continuidad debe revisar dependencias; privacidad debe intervenir si hay indicios de acceso a datos personales; y compliance debe determinar si los hechos alcanzan algún umbral de notificación o evidencia regulatoria.

La evidencia que conviene conservar

Una organización que solo conserva una captura de pantalla de la versión final tendrá dificultades para demostrar cómo gestionó el riesgo. Para este tipo de vulnerabilidad conviene guardar un expediente breve, pero reproducible:

• Listado de activos MikroTik identificados y método utilizado para descubrirlos.
• Versión exacta de RouterOS antes y después de la corrección.
• Fuente oficial consultada y decisión adoptada ante la discrepancia entre “menor que 7.24” y “7.23 o posterior”.
• Resultado de la comprobación de exposición externa, incluyendo IPv4, IPv6, NAT y reglas de cortafuegos.
• Registro del cambio, responsable, fecha, ventana de mantenimiento y validaciones posteriores.
• Revisión de logs y conclusión sobre indicios de explotación.
• Acciones de rotación de credenciales o claves cuando hubiera exposición o sospecha de compromiso.
• Evaluación de impacto sobre servicios críticos, terceros y obligaciones de notificación.

Esta documentación no es burocracia ornamental. Permite distinguir tres situaciones que suelen mezclarse: un activo vulnerable pero no expuesto, un activo expuesto sin indicios conocidos de explotación y un activo posiblemente comprometido. Cada una exige una respuesta diferente. Tratar las tres como “parche pendiente” es una forma bastante eficaz de perder información crítica.

Lo que los equipos deberían preguntar a MikroTik y a sus proveedores

La inconsistencia de versiones hace recomendable solicitar una confirmación expresa. Las preguntas deberían ser concretas:

• ¿Qué versión exacta corrige CVE-2026-84411?
• ¿Está la versión 7.23 afectada o corregida?
• ¿La corrección depende de una rama concreta de RouterOS o del modelo de hardware?
• ¿Existe una recomendación específica para dispositivos gestionados por proveedores?
• ¿Qué logs o indicadores recomienda conservar para investigar explotación?
• ¿Hay cambios de configuración o incompatibilidades conocidas tras la actualización?

Mientras llega una respuesta, las empresas deberían evitar publicar el servicio web de gestión y elevar la prioridad de todos los dispositivos que cumplan el criterio de afectación de CISA. Si un proveedor afirma que un equipo está corregido, debe aportar la versión instalada y la referencia técnica que sustenta esa conclusión. La frase “lo hemos revisado” no es una evidencia técnica.

La lección para la arquitectura de red

CVE-2026-84411 es una vulnerabilidad de un producto concreto, pero expone un problema más amplio: la dependencia de dispositivos perimetrales con acceso privilegiado y visibilidad limitada. Un router no es un simple electrodoméstico de red. Puede decidir qué tráfico entra, qué tráfico sale, qué segmentos se ven entre sí y qué sistemas permanecen aislados durante un incidente.

La arquitectura defensiva debería asumir que cualquier interfaz de administración puede ser atacada y que cualquier dispositivo con privilegios de red puede ser un objetivo estratégico. Eso implica separar el plano de gestión, imponer listas de origen, utilizar autenticación fuerte, centralizar registros, limitar el acceso de proveedores y probar la recuperación de configuraciones. También implica retirar equipos abandonados y eliminar servicios que nadie sabe ya por qué siguen activos.

La segmentación no sustituye al parche. El parche tampoco sustituye a la segmentación. En este caso hacen falta ambas capas: corregir la vulnerabilidad y reducir las posibilidades de que un fallo similar vuelva a convertir una interfaz de administración en una entrada directa a la red.

Conclusión: parchear, pero sin cerrar los ojos

CISA ha publicado una alerta de máxima prioridad porque CVE-2026-84411 combina los ingredientes que suelen producir incidentes graves: acceso remoto, ausencia de autenticación, baja complejidad, impacto completo y ejecución potencial como root. La publicación del 29 de septiembre de 2026 no comunica explotación pública conocida, pero tampoco ofrece una razón para esperar a que aparezca.

La acción inmediata es identificar las versiones de RouterOS, retirar la exposición innecesaria, confirmar con MikroTik cuál es la versión corregida y actualizar con controles de recuperación. Después hay que investigar la ventana de exposición y documentar si el dispositivo sostenía servicios regulados o críticos.

La contradicción entre “menor que 7.24” y “7.23 o posterior” merece una aclaración formal. Hasta entonces, la decisión prudente no es elegir la cifra más cómoda, sino tratar como vulnerable cualquier versión que CISA incluya en el rango afectado y exigir confirmación del fabricante antes de cerrar la incidencia. En ciberseguridad, una versión ambigua no es una versión segura.