CISA añadió CVE-2026-67279 de MikroTik RouterOS a Known Exploited Vulnerabilities el 25 de septiembre de 2026. La actualización del Centro Canadiense de Ciberseguridad confirma ese hito, mientras MikroTik ya había publicado versiones corregidas y recomienda no exponer SSH a redes no confiables. Para una empresa española con routers en sedes, proveedores o enlaces remotos, la acción es localizar dispositivos, actualizar la rama correcta y revisar configuración y registros. KEV prueba explotación de la vulnerabilidad, no compromiso de todos los routers ni víctimas en España.

MikroTik RouterOS CVE-2026-67279: qué cambió

El aviso original de MikroTik es del 3 de septiembre. El Centro Canadiense actualizó su alerta el 25 para registrar que CISA incorporó CVE-2026-67279 al catálogo de explotación conocida. La fecha nueva no significa que el defecto se descubriera ese día. Significa que la prioridad de revisión cambió para una organización que había decidido esperar. Otros problemas de la familia MikroTrick ya figuraban en alertas previas; este artículo se centra en la incorporación de la CVE específica y la respuesta operativa.

Hay que conservar una distinción técnica: el fabricante no publica en su página todos los detalles de explotación y señala que la mayoría de configuraciones no están en riesgo inmediato. Esto no justifica ignorar la actualización. El equipo debe comprobar si SSH está accesible desde redes no confiables, qué versión exacta ejecuta el dispositivo y si aparecen señales de modificación no autorizada. No se debe presentar un mecanismo universal de ataque más detallado que las fuentes oficiales disponibles.

Qué versiones corregidas indica MikroTik

La página de seguridad del fabricante indica correcciones en 6.49.21, 7.23.4, 7.24.2 y 7.25 beta 3. El aviso canadiense enumera ramas anteriores a esas compilaciones como afectadas en su tabla. Seleccione la actualización apropiada para el canal y hardware concretos; un número de versión de una rama no se compara linealmente con el de otra. Pida al operador exportación de versión y fecha del cambio por cada router.

Una empresa puede tener dispositivos gestionados por equipos diferentes: oficinas, tiendas, enlaces de respaldo, Wi-Fi, proveedores de internet o instalaciones de clientes. El inventario debe distinguir propiedad y responsabilidad de administración. Un router de contingencia que permanece apagado puede volver a operación con firmware antiguo durante una emergencia. Incluya repuestos y equipos de laboratorio con conectividad externa.

Por qué la administración SSH merece atención

MikroTik recomienda que SSH no esté abierto a redes no confiables y recuerda que su configuración por defecto bloquea el puerto desde internet. Si se abrió manualmente, aconseja limitarlo a direcciones confiables o utilizar una VPN robusta, como WireGuard, para administrar sin exponer puertos de gestión. Una IP permitida no es garantía absoluta cuando la red de origen está comprometida; el principio es reducir el camino de acceso y controlar quién lo usa.

Revise también otras interfaces de gestión, aunque la orientación concreta de esta alerta se enfoca en SSH. Una excepción hecha para soporte de un proveedor puede quedar activa después de terminar el contrato. Registre cada regla de firewall, su propósito, responsable y fecha de revisión. Antes de cerrar puertos, confirme cómo se recuperará acceso al equipo remoto para que el cambio no deje una sede sin administración durante una incidencia.

Mapa de routers que protege procesos, no solo cajas

Para cada dispositivo registre modelo, serial interno, ubicación, versión RouterOS, canal, dirección de gestión, exposición externa, configuración de SSH, cuentas, proveedor y proceso que soporta. Clasifique los routers que conectan pagos, ERP, VPN corporativa, telefonía o sedes. La criticidad empresarial no siempre coincide con el costo del equipo: un dispositivo pequeño puede ser el único punto de entrada a un almacén o a una oficina remota.

Los proveedores pueden operar routers cuyo firmware no aparece en el inventario de TI del cliente. Solicite versión y evidencia de actualización, sin exigir credenciales de administración por correo. Si una filial o franquicia gestiona su propio equipo, acuerde quién coordina el cambio y cómo se demuestra que las reglas de acceso se aplicaron. Una lista incompleta es una de las razones por las que una vulnerabilidad corregida sigue apareciendo meses después.

Plan de actualización segura

Conserve copia de configuración y documente la versión actual. Prepare ventana, acceso alternativo y contacto local para recuperar un dispositivo si la actualización falla. Instale la versión corregida de su rama y verifique que el router volvió a prestar conectividad, VPN, reglas de firewall y rutas. Compruebe desde una red no confiable que SSH no está abierto si no debe estarlo. Registre hora, operador, resultado y cualquier excepción.

Un firmware nuevo no demuestra por sí solo que el router estuvo siempre íntegro. MikroTik aconseja revisar la configuración tras actualizar en busca de scripts, usuarios u otros elementos desconocidos. La página del fabricante menciona un estado «Flagged» en el log cuando detecta determinadas señales de compromiso, pero la ausencia de esa marca no sustituye una revisión de configuración. Si aparece una anomalía, preserve evidencia antes de restaurar de fábrica.

Qué revisar cuando hubo exposición

Examine registros de administración, inicios de sesión, usuarios añadidos, scripts, tareas programadas, reglas NAT y firewall, DNS, túneles y destinos de tráfico inesperados. Compare con una configuración de referencia firmada o conservada antes del incidente. Una regla creada por un proveedor puede parecer anómala si el inventario es pobre; obtenga confirmación y fecha. Una modificación no explicada que abre acceso o redirige tráfico exige investigación.

La retención de logs en un router puede ser limitada. Envíe eventos relevantes a un repositorio protegido y correlacione con registros de VPN y de los sistemas a los que da acceso. Si no hay trazas suficientes, consigne la limitación. Un equipo que responde a la última versión y muestra un estado normal no puede demostrar por sí mismo que nunca se usó la vulnerabilidad durante la ventana anterior.

Evite que el parche corte una sede

Un cambio en un router puede interrumpir conectividad de una tienda, fábrica o centro de atención. Planifique pruebas antes y después: enlace principal, respaldo, VPN, telefonía, acceso de proveedores y monitoreo. Si la actualización requiere reinicio, comunique la ventana a los equipos operativos. El costo de no actualizar debe compararse con una intervención planificada, no con la idea de que el equipo funciona hoy y por tanto está seguro.

Cuando un modelo no soporta la versión corregida o el proveedor no ofrece una ruta viable, la empresa necesita un plan de reemplazo o aislamiento con plazo. La excepción debe estar aprobada por un responsable de riesgo y revisada. No deje una regla temporal de bloqueo sin fecha; se olvida con facilidad cuando cambia el administrador.

Preguntas que hacer al operador de red

Solicite una relación de dispositivos administrados, versión previa y posterior, exposición de SSH, resultado de inspección de configuración, respaldo y prueba de conectividad. Pregunte si existen equipos instalados en clientes o sucursales que no aparecen en la consola central. Aclare quién conserva logs y quién puede intervenir fuera de horario. Un «todos los routers están actualizados» debe tener evidencias por activo.

Si detecta acceso no autorizado, la coordinación con proveedor es parte de la respuesta. Rotar credenciales, retirar cuentas e inspeccionar túneles puede afectar servicios legítimos. El Análisis Forense Digital ayuda a delimitar cambios antes de una reconstrucción, mientras el equipo de redes asegura continuidad.

Lectura para organizaciones de España

La inclusión en KEV es una señal global; las fuentes citadas no identifican una campaña española ni víctimas locales. La aplicabilidad para España depende de si una organización opera RouterOS afectado y de cómo expone su administración. Pymes con varias sedes, proveedores de servicios y empresas con equipos remotos pueden dar prioridad a dispositivos accesibles desde internet, sin afirmar que todos están comprometidos.

Un Análisis de Vulnerabilidades puede ayudar a localizar versiones y exposición; un Ethical Hacking autorizado puede validar segmentación y acceso de administración tras corregir. La prueba debe respetar disponibilidad y alcance acordados: no se ensaya explotación destructiva sobre el router de producción sin un plan específico.

Lo que debe quedar resuelto

Centralice inventario de firmware, reglas de administración y propietarios de cada equipo. Establezca un plazo de evaluación de avisos que combine explotación confirmada, exposición y función de negocio. Pruebe recuperación de configuración en un equipo de reserva. Revise cuentas de proveedores, registros enviados a un sistema central y cambios de firewall aprobados. Una próxima alerta debería poder responderse con una consulta del inventario, no con llamadas improvisadas a todas las sedes.

Documente además las decisiones que no pudo cerrar: equipos sin soporte, ubicaciones sin acceso local y proveedores sin evidencia. Asigne presupuesto y fecha. La corrección de una CVE concreta pierde valor si el proceso vuelve a crear routers con SSH abierto o firmware antiguo. El resultado buscado es una gestión sostenida del perímetro, no solo una actualización de fin de semana.

Preguntas frecuentes

¿Todos los routers MikroTik están comprometidos?

No. CISA registra explotación de una vulnerabilidad; versión, configuración y evidencia determinan el estado de cada equipo.

¿Cerrar SSH basta?

Reduce una superficie recomendada por el fabricante, pero no sustituye el firmware corregido ni la revisión de configuración histórica.

¿El estado «Flagged» es una prueba completa?

Es una señal que MikroTik aconseja revisar. Su ausencia no demuestra que no existieron cambios no autorizados.

Ordene sus routers por exposición real

Fuentes y límites

La señal de explotación es global. No se afirma afectación de organizaciones españolas sin evidencia local.