MikroTik cerraba ese puerto de fábrica: la vulnerabilidad es suya, la excepción es tuya

Desde por lo menos el 2 de septiembre hay quien entra en routers MikroTik sin saber la contraseña. Hay parche desde el 3 y aviso público desde el 5. Pero la frase que más dice de todo este asunto no la escribió CERT Polska: la escribió MikroTik, y no habla del fallo. Habla de un pero.

La frase completa es esta: «MikroTik default configuration blocks this port from the internet by default, but if you have manually opened this port…». La configuración de fábrica cierra el SSH hacia internet. El resto del párrafo del fabricante es lo que hay que hacer si alguien lo abrió a mano.

Algún día concreto, hace meses o hace años, alguien de tu equipo —o de la empresa que llevaba esto antes— tecleó esa regla. Esa regla es el tema de este artículo. El CVE es la ocasión.

Lo que pasó, con fechas

CERT Polska publicó el 5 de septiembre de 2026 la coordinación de seis vulnerabilidades en RouterOS. Detalla tres, y las dos primeras son las que importan:

• CVE-2026-67276 (CVSS 9,2), «SSH authentication bypass»: RouterOS no verificaba correctamente las claves públicas RSA en la autenticación SSH.
• CVE-2026-86060 (CVSS 9,2), «SSH session privilege manipulation via a crafted username»: RouterOS «did not properly handle usernames beginning with a disallowed character», y con un nombre preparado se escalaba privilegio.
• CVE-2026-67277 (CVSS 8,8), «memory disclosure and crash via bandwidth-test»: acceso sin autenticar a estado privilegiado, con fuga de memoria y caída del equipo.

Las dos primeras se encadenan y el conjunto tiene nombre: MikroTrick. Combinadas, en palabras del propio CERT, «allows an attacker to take full control of the device without authentication if the device supports remote access using the SSH protocol». Sin credenciales, sin usuario, sin nada: basta con llegar al puerto.

MikroTik publicó las versiones corregidas el 3 de septiembre: 7.25beta3, 7.24.2, 7.23.4 y 6.49.21, cuatro builds repartidas por cuatro líneas de versión. Ese día el fabricante dijo dos cosas y calló una tercera a propósito: «This is an important security update. Most configurations are not at risk, but upgrading is highly recommended» y, acto seguido, «To give time to update your systems, we are not currently publishing detailed information». El detalle llegó el 5, con el aviso de CERT Polska. Y entre medias el CERT ya estaba viendo lo que describe sin adornos: «In recent days we have been observing attacks against RouterOS devices accessible from the internet», con actividad desde al menos el 2 de septiembre. Es decir: los ataques son anteriores al parche.

Hay un gesto de ese 3 de septiembre que no hemos visto comentado en ninguna parte y que dice bastante de cómo de urgente era esto por dentro. Lo cuenta CERT Polska: «Along with this update, for the first time in history, MikroTik sent a push notification to the phones of users who had the MikroTik app installed». Por primera vez. Un fabricante que publica notas de versión secas y deja que te enteres cuando mires decidió esta vez que había que despertar a la gente en el móvil.

Hay un detalle en el origen que ya no sorprende y hace un año habría sido titular: las vulnerabilidades «were discovered by Sławomir Rozbicki from the CERT Polska team using the GPT-5.5-cyber and GPT-5.6-sol models», en un entorno de laboratorio automatizado. Seis fallos en un producto muy auditado, encontrados por un equipo con modelos haciendo el trabajo de barrido. Ya escribimos sobre lo que eso le hace a tus plazos y esto es otra confirmación: la parte que se acelera es la de encontrar, no la de arreglar.

El catálogo de CISA se quedó con la mitad de la cadena

Descargamos el fichero del catálogo KEV de CISA (versión 2026.09.16, 1.713 entradas) y lo miramos entrada a entrada. El 10 de septiembre entraron dos de estos tres: CVE-2026-86060 y CVE-2026-67277, ambas con fecha límite de corrección el 13 de septiembre. Tres días.

El que no está es CVE-2026-67276: el salto de autenticación, la mitad que abre la cadena. No cambia nada de lo que hay que hacer, porque el paquete que corrige una corrige las tres y la acción es idéntica. Pero sí cambia lo que ve quien ordena la cola de parcheo mirando el catálogo: verá el escalado de privilegios y la fuga de memoria del bandwidth-test, y no verá el fallo que permite entrar. Ya dijimos, con el CVE medio que entró antes que el crítico, que el catálogo no ordena tu cola; aquello iba de un orden raro, esto va de una pieza que falta. Si tu informe mensual se genera cruzando inventario contra KEV —y el de mucha gente se genera así—, el informe de este mes no menciona la puerta.

En el mismo fichero hay un campo que casi nadie mira y que aquí separa las dos entradas: forensicTriage. En CVE-2026-86060 vale Yes; en CVE-2026-67277, No. Es decir: para la que da privilegio por SSH, CISA no considera suficiente parchear y pide además triaje forense bajo la BOD 26-04. Para la del bandwidth-test, no. Si necesitas un argumento para justificar ante dirección por qué dedicas una mañana a mirar registros en vez de veinte minutos a actualizar, ahí está, escrito por CISA y en un campo JSON.

122.500, y el fabricante diciendo que de fábrica está cerrado

La cifra que circuló es de Shadowserver, y conviene citarla entera porque el paréntesis final es la mitad del dato: «At least 122,500 MikroTik devices with SSH accessible found per 24 hour scan window on 2026-09-05 (no vulnerability check)». Ciento veintidós mil quinientos equipos con el servicio de administración contestando a quien llame, contados en una sola ventana de veinticuatro horas. No son 122.500 equipos vulnerables: son 122.500 que responden. El propio que cuenta lo aclara.

Y al lado, la otra cosa que dijo MikroTik, que es de una tranquilidad reveladora: «For regular home device users the issue does not pose an immediate risk, but we still suggest all users to upgrade». Traducido: el que compró la caja y la enchufó tal cual está razonablemente a salvo. El riesgo vive donde alguien tomó una decisión.

Conviene no estirar ese número más de lo que da. No sabemos cuántos de esos 122.500 son equipos de empresa, cuántos son CPE que gestiona un operador con su propia red de administración, cuántos son instancias CHR en un proveedor cloud —que no arrancan con la configuración de un RouterBOARD— y cuántos están publicados a propósito y con criterio. Nadie publica ese desglose. Lo que sí está escrito por el fabricante es que su configuración de fábrica no los deja así, de modo que en cada uno de los que sí lo está hay, en algún punto de la cadena, una mano.

Y hay que acotar esto antes de seguir, porque si no el artículo entero se lee torcido. Las seis vulnerabilidades no van todas del puerto de entrada: según CERT Polska «affect the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface». El cliente SSH también. Por eso su segunda medida temporal es «Do not initiate TLS connections from an unpatched device or use the built-in SSH clients (/system ssh and /system ssh-exec)». Traducido: un equipo sin un solo puerto abierto hacia fuera no está a salvo si es él quien se conecta. Todo lo que viene a continuación va de la exposición, que es la parte que decides tú; actualizar hay que actualizar igual.

Quien abrió ese puerto tenía razón aquel día

Aquí es donde se suele resbalar hacia la moralina, y no toca. Las excepciones de administración no se abren por dejadez. Se abren porque son la respuesta correcta a un problema concreto, un día concreto: la sede está a noventa kilómetros, la línea principal está caída y hay que entrar por la de respaldo, el instalador necesita acceso el sábado, la monitorización nueva tiene que llegar a la API, el operador quiere ver el equipo para diagnosticar. Se escribe la regla, funciona, se cierra la incidencia y todo el mundo se va a su casa habiendo hecho bien su trabajo.

Lo que no ocurre nunca es la otra mitad. Nadie escribe cuándo deja de hacer falta. Las excepciones temporales son el único cambio de configuración que se crea con fecha de caducidad en la cabeza de quien lo hace y se guarda sin ella en el aparato. Por eso, tres años después, la regla sigue ahí y ya no hay nadie en la empresa que sepa decir por qué. Y cuando aparece una cadena como MikroTrick, lo que encuentra no es un descuido de esta semana: encuentra una decisión de hace tres años que nadie volvió a mirar.

Hay una variante de esa regla que merece nombre propio porque es la más común: mover el puerto. Pasar el SSH del 22 al 2222 y darlo por resuelto. Quita ruido de fondo —los barridos masivos y perezosos dejan de llamar—, y eso tiene un valor real en los registros. Lo que no cambia es quién puede llegar al servicio, que es la pregunta de verdad. Un ataque dirigido contra una cadena que da control total del aparato se permite el lujo de buscar el puerto. Esto es criterio nuestro, no un dato: nos parece que el puerto movido ha dado a mucha gente la sensación de haber cerrado algo que sigue abierto.

Si estuvo abierto, el parche no cierra el asunto

Ya hemos defendido aquí que actualizar no es limpiar, y no vamos a repetir el argumento. Lo que cambia hoy es que aquí el parche sí te ayuda a detectar, y conviene saber exactamente hasta dónde. RouterOS corregido revisa la configuración al arrancar, desactiva las entradas sospechosas, deja avisos en el registro y marca el equipo como Flagged, un estado que se consulta con /system/device-mode/print. Es una función excelente y la frase que la acompaña en el aviso de CERT Polska es la que hay que leer dos veces: «the absence of the marker is not proof that the device is safe». Que no salga la marca no significa nada; que salga, sí.

Por eso las dos líneas de registro que publica CERT Polska valen más que la marca, y son dos, no una: login failure for user -2 from <ip> via ssh y, la que de verdad prueba algo, user <name> added by ssh:-2@<ip>. La primera dice que lo intentaron. La segunda dice que crearon una cuenta. Y en la configuración, un usuario privilegiado llamado ops que nadie dio de alta. Lo que hay que revisar lo enumera el mismo aviso: usuarios, scripts, tareas del programador, servidores proxy y túneles. Las tareas del programador son las que más se olvidan y las que mejor sobreviven a un reinicio.

MikroTik lo remata con una frase que parece de trámite y no lo es, precisamente por su primera mitad: «Even if your device is not in Flagged state, after upgrading your RouterOS, inspect your device configuration for any unknown scripts, users or other config you do not recognise». El fabricante que acaba de darte un detector te está diciendo, en la misma línea, que no te fíes solo de él.

Los dos últimos son los que nos quitarían el sueño en un router de frontera, y no por su sofisticación. Un túnel o un proxy en el equipo que separa tu red de internet sobrevive a que cambies todas las contraseñas, no aparece en ningún antivirus porque no hay antivirus ahí, y desde dentro de la LAN no se ve: para verlo hay que mirar la configuración del propio router, que es justo el sitio donde nadie mira dos veces. Un cambio de contraseña da una sensación de haber actuado que, en este escenario, no se corresponde con nada.

Lo que haríamos esta semana

Nosotros también tenemos RouterOS en casa —lo usamos, incluido CHR—, así que esta lista no es un consejo para otros. Es la nuestra.

• Actualizar, y saber en qué línea de versión está cada caja antes de intentarlo. Las cuatro builds corregidas viven en cuatro líneas distintas, tres de ellas de producción: un parque real tiene equipos en 6.49, en 7.23 y en 7.24 a la vez, y el salto entre líneas no es el mismo trabajo que el salto dentro de una. Esa lista sale del sistema, no del diagrama; si sale del documento ya sabes cómo acaba, porque el Excel miente.
• Guardar el registro antes de tocar nada, si el equipo estuvo expuesto. Aquí nos separamos del orden que recomiendan las dos fuentes —ambas dicen actualizar primero y mirar después—, y lo decimos en voz alta para que se pueda discutir: un equipo con poco espacio de registro que se reinicia puede perder justo las líneas que buscas. Copiar el registro fuera y anotar la lista de usuarios cuesta un minuto y decide si esto es una actualización o una respuesta a incidente, que son dos calendarios y dos conversaciones distintas con dirección. Después, actualizar sin esperar.
• Listar las reglas que publican administración, y ponerles dos cosas que RouterOS ya deja escribir gratis. En el comentario de cada regla: quién la pidió y en qué fecha muere. Con eso, una revisión mensual deja de ser una auditoría y pasa a ser una lista de nombres y fechas vencidas. No hace falta herramienta nueva, hace falta escribirlo. Es lo más barato de toda esta lista y lo que evita que dentro de tres años el siguiente aviso encuentre la misma regla. Y no, RouterOS no caduca reglas solo: la fecha la hace cumplir una persona mirando una lista.
• Y luego el camino que recomienda el propio fabricante, que es el que seguimos nosotros. Sus palabras: «use a strong VPN like WireGuard to access your router and do not open any management ports at all». La frase completa ofrece las dos opciones y las ordena: primero «make sure only trusted IP can access it» y después ese «or better yet». No es una idea nuestra ni un argumento de venta: es el fabricante diciendo que filtrar el puerto está bien y no tenerlo está mejor. Sobre cuándo WireGuard y cuándo IPsec ya escribimos una comparativa honesta, incluido en qué casos el segundo sigue ganando.
• Y el bandwidth-test, que es el olvidado. CERT Polska lo nombra junto al SSH y al WWW/WWW-SSL entre los servicios a desactivar o restringir a redes de confianza mientras se actualiza. Es un servicio que se enciende una tarde para medir un enlace y se queda encendido para siempre, igual que la regla del cortafuegos. Misma historia, otro renglón.

Cerrar la administración tampoco es gratis

Sería deshonesto terminar con el «ciérralo todo» y dejarlo ahí. Si cierras la administración desde internet, necesitas otra vía para entrar el día que la línea principal esté caída, que es precisamente el día que hay que entrar. Eso cuesta: un módem 4G con su tarifa, una línea de reserva, un acceso fuera de banda, o alguien con llave a una hora razonable. Quien abrió el puerto hace tres años, muchas veces, lo abrió porque esa partida no estaba en el presupuesto. Discutir el puerto sin discutir la vía alternativa es atarle las manos a alguien.

Y hay un caso en el que esta lista no se puede aplicar: cuando el router no es tuyo. Si lo gestiona tu operador, tú no tocas ni la versión ni las reglas. Ahí el entregable no es una regla, es una pregunta por escrito —qué versión corre, cuándo la actualizáis, desde dónde se administra— y una fecha para la respuesta. Que la caja sea de otro no traslada la avería a otro: el que se queda sin servicio sigues siendo tú.

El fallo es inevitable; la avería es una decisión de diseño. En este caso la decisión de diseño no la tomó MikroTik el día que publicó el CVE. La tomó alguien de tu lado, una tarde cualquiera, resolviendo algo que había que resolver. La culpa no es suya. La revisión sí es tuya.

Lo que no afirmamos

No decimos que RouterOS sea menos seguro que otros: no tenemos ninguna cifra comparativa que ponga a un fabricante por encima de otro, y tampoco sabemos cuánto tardó MikroTik desde que recibió el reporte hasta que publicó el arreglo, porque esa fecha no está publicada. No sabemos cuántos de los 122.500 equipos contados por Shadowserver están mal configurados; sabemos cuántos responden, que no es lo mismo, y el propio recuento avisa de que no comprueba si son vulnerables. No afirmamos que la cadena se haya usado contra ninguna empresa concreta ni conocemos víctimas con nombre. Tampoco somos parte interesada: no revendemos MikroTik ni ningún otro fabricante de red. Y las dos direcciones IP que cita CERT Polska no las reproducimos: un indicador de esa clase envejece en días y publicarlo como lista de bloqueo hace más daño que bien.

Nota de fuentes

Todo consultado el 18 de septiembre de 2026. Uno: el aviso de CERT Polska «Critical vulnerabilities in MikroTik RouterOS are being actively exploited» (5 de septiembre de 2026), de donde salen las seis vulnerabilidades coordinadas y los componentes que afectan («the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface»), los tres CVE detallados con sus puntuaciones CVSS y descripciones literales, el nombre MikroTrick, la frase sobre el control total sin autenticación, la observación de ataques desde al menos el 2 de septiembre, la notificación push de MikroTik por primera vez en su historia, el mecanismo Flagged con /system/device-mode/print y su advertencia «the absence of the marker is not proof that the device is safe», las dos líneas de registro y el usuario ops, la lista de qué revisar (usuarios, scripts, tareas del programador, proxies y túneles), las medidas temporales —desactivar o restringir SSH, WWW/WWW-SSL y bandwidth-test, y no iniciar conexiones TLS ni usar los clientes SSH internos desde un equipo sin parchear—, y la atribución del hallazgo a Sławomir Rozbicki con los modelos GPT-5.5-cyber y GPT-5.6-sol. Dos: la página de seguridad de MikroTik sobre la vulnerabilidad de septiembre de 2026, de donde salen las cuatro versiones corregidas con fecha del 3 de septiembre y las frases citadas: la del «important security update», la de no publicar detalle todavía, la del bloqueo por defecto del puerto, la de WireGuard, la del usuario doméstico y la de inspeccionar la configuración aunque el equipo no esté en estado Flagged. Tres: el fichero JSON del catálogo KEV de CISA, versión 2026.09.16 con 1.713 entradas, descargado y filtrado por nosotros: de ahí salen las fechas de alta (10 de septiembre) y el plazo de corrección (13 de septiembre) de CVE-2026-86060 y CVE-2026-67277, la ausencia de CVE-2026-67276 y el campo forensicTriage de cada entrada. Cuatro: la cifra de Shadowserver del 5 de septiembre de 2026, citada literalmente —con su paréntesis— en la cobertura del caso; no la hemos podido comprobar en el panel original. Lo que es opinión nuestra y va marcado como tal en el cuerpo: que el puerto movido da sensación de cierre sin serlo, que las excepciones temporales se crean con caducidad y se guardan sin ella, la lista de lo que haríamos esta semana y la decisión de guardar el registro antes de actualizar, que se aparta del orden que recomiendan las fuentes.