MikroTik tancava aquell port de fàbrica: la vulnerabilitat és seva, l'excepció és teva

Des de com a mínim el 2 de setembre hi ha qui entra en routers MikroTik sense saber la contrasenya. Hi ha pedaç des del 3 i avís públic des del 5. Però la frase que més diu de tot aquest assumpte no la va escriure CERT Polska: la va escriure MikroTik, i no parla de la fallada. Parla d'un però.

La frase completa és aquesta: «MikroTik default configuration blocks this port from the internet by default, but if you have manually opened this port…». La configuració de fàbrica tanca l'SSH cap a internet. La resta del paràgraf del fabricant és el que cal fer si algú el va obrir a mà.

Algun dia concret, fa mesos o fa anys, algú del teu equip —o de l'empresa que ho portava abans— va teclejar aquella regla. Aquella regla és el tema d'aquest article. El CVE és l'ocasió.

Què va passar, amb dates

CERT Polska va publicar el 5 de setembre de 2026 la coordinació de sis vulnerabilitats a RouterOS. En detalla tres, i les dues primeres són les que importen:

• CVE-2026-67276 (CVSS 9,2), «SSH authentication bypass»: RouterOS no verificava correctament les claus públiques RSA en l'autenticació 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», i amb un nom preparat s'escalava privilegi.
• CVE-2026-67277 (CVSS 8,8), «memory disclosure and crash via bandwidth-test»: accés sense autenticar a estat privilegiat, amb fuita de memòria i caiguda de l'equip.

Les dues primeres s'encadenen i el conjunt té nom: MikroTrick. Combinades, en paraules del mateix CERT, «allows an attacker to take full control of the device without authentication if the device supports remote access using the SSH protocol». Sense credencials, sense usuari, sense res: n'hi ha prou amb arribar al port.

MikroTik va publicar les versions corregides el 3 de setembre: 7.25beta3, 7.24.2, 7.23.4 i 6.49.21, quatre builds repartides per quatre línies de versió. Aquell dia el fabricant va dir dues coses i en va callar una tercera a propòsit: «This is an important security update. Most configurations are not at risk, but upgrading is highly recommended» i, tot seguit, «To give time to update your systems, we are not currently publishing detailed information». El detall va arribar el 5, amb l'avís de CERT Polska. I enmig el CERT ja estava veient el que descriu sense adorns: «In recent days we have been observing attacks against RouterOS devices accessible from the internet», amb activitat des de com a mínim el 2 de setembre. És a dir: els atacs són anteriors al pedaç.

Hi ha un gest d'aquell 3 de setembre que no hem vist comentat enlloc i que diu força de com d'urgent era això per dins. Ho explica 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». Per primera vegada. Un fabricant que publica notes de versió seques i deixa que te n'assabentis quan miris va decidir aquesta vegada que calia despertar la gent al mòbil.

Hi ha un detall a l'origen que ja no sorprèn i fa un any hauria estat titular: les vulnerabilitats «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 entorn de laboratori automatitzat. Sis errors en un producte molt auditat, trobats per un equip amb models fent la feina de garbellar. Ja vam escriure sobre què li fa això als teus terminis i això n'és una altra confirmació: la part que s'accelera és la de trobar, no la d'arreglar.

El catàleg de CISA es va quedar amb la meitat de la cadena

Vam descarregar el fitxer del catàleg KEV de CISA (versió 2026.09.16, 1.713 entrades) i el vam mirar entrada a entrada. El 10 de setembre hi van entrar dos d'aquests tres: CVE-2026-86060 i CVE-2026-67277, tots dos amb data límit de correcció el 13 de setembre. Tres dies.

El que no hi és és CVE-2026-67276: el salt d'autenticació, la meitat que obre la cadena. No canvia res del que cal fer, perquè el paquet que en corregeix una les corregeix totes tres i l'acció és idèntica. Però sí que canvia el que veu qui ordena la cua de pedaços mirant el catàleg: veurà l'escalada de privilegis i la fuita de memòria del bandwidth-test, i no veurà la fallada que permet entrar. Ja vam dir, amb el CVE mitjà que va entrar abans que el crític, que el catàleg no ordena la teva cua; allò anava d'un ordre estrany, això va d'una peça que falta. Si el teu informe mensual es genera creuant inventari contra KEV —i el de molta gent es genera així—, l'informe d'aquest mes no esmenta la porta.

Al mateix fitxer hi ha un camp que gairebé ningú no mira i que aquí separa les dues entrades: forensicTriage. A CVE-2026-86060 val Yes; a CVE-2026-67277, No. És a dir: per a la que dona privilegi per SSH, CISA no considera suficient posar el pedaç i demana a més triatge forense sota la BOD 26-04. Per a la del bandwidth-test, no. Si necessites un argument per justificar davant direcció per què dediques un matí a mirar registres en comptes de vint minuts a actualitzar, és aquí, escrit per CISA i en un camp JSON.

122.500, i el fabricant dient que de fàbrica està tancat

La xifra que va circular és de Shadowserver, i convé citar-la sencera perquè el parèntesi final és la meitat de la dada: «At least 122,500 MikroTik devices with SSH accessible found per 24 hour scan window on 2026-09-05 (no vulnerability check)». Cent vint-i-dos mil cinc-cents equips amb el servei d'administració contestant a qui truqui, comptats en una sola finestra de vint-i-quatre hores. No són 122.500 equips vulnerables: són 122.500 que responen. El mateix que compta ho aclareix.

I al costat, l'altra cosa que va dir MikroTik, que és d'una tranquil·litat reveladora: «For regular home device users the issue does not pose an immediate risk, but we still suggest all users to upgrade». Traduït: qui va comprar la caixa i la va endollar tal qual està raonablement segur. El risc viu on algú va prendre una decisió.

Convé no estirar aquell número més del que dona. No sabem quants d'aquells 122.500 són equips d'empresa, quants són CPE que gestiona un operador amb la seva pròpia xarxa d'administració, quants són instàncies CHR en un proveïdor cloud —que no arrenquen amb la configuració d'un RouterBOARD— i quants estan publicats a propòsit i amb criteri. Ningú no publica aquell desglossament. El que sí que està escrit pel fabricant és que la seva configuració de fàbrica no els deixa així, de manera que en cadascun dels que sí que ho està hi ha, en algun punt de la cadena, una mà.

I cal acotar això abans de continuar, perquè si no l'article sencer es llegeix tort. Les sis vulnerabilitats no van totes del port d'entrada: segons CERT Polska «affect the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface». El client SSH també. Per això la seva segona mesura temporal és «Do not initiate TLS connections from an unpatched device or use the built-in SSH clients (/system ssh and /system ssh-exec)». Traduït: un equip sense ni un sol port obert cap a fora no està fora de perill si és ell qui es connecta. Tot el que ve a continuació va de l'exposició, que és la part que decideixes tu; actualitzar cal actualitzar igualment.

Qui va obrir aquell port tenia raó aquell dia

Aquí és on se sol relliscar cap a la moralina, i no toca. Les excepcions d'administració no s'obren per deixadesa. S'obren perquè són la resposta correcta a un problema concret, un dia concret: la seu és a noranta quilòmetres, la línia principal està caiguda i cal entrar per la de reserva, l'instal·lador necessita accés el dissabte, la monitorització nova ha d'arribar a l'API, l'operador vol veure l'equip per diagnosticar. S'escriu la regla, funciona, es tanca la incidència i tothom se'n va a casa havent fet bé la seva feina.

El que no passa mai és l'altra meitat. Ningú no escriu quan deixa de caldre. Les excepcions temporals són l'únic canvi de configuració que es crea amb data de caducitat al cap de qui el fa i es desa sense ella a l'aparell. Per això, tres anys després, la regla continua allà i ja no hi ha ningú a l'empresa que sàpiga dir per què. I quan apareix una cadena com MikroTrick, el que troba no és un descuit d'aquesta setmana: troba una decisió de fa tres anys que ningú no va tornar a mirar.

Hi ha una variant d'aquella regla que mereix nom propi perquè és la més comuna: moure el port. Passar l'SSH del 22 al 2222 i donar-ho per resolt. Treu soroll de fons —els escaneigs massius i mandrosos deixen de trucar—, i això té un valor real als registres. El que no canvia és qui pot arribar al servei, que és la pregunta de debò. Un atac dirigit contra una cadena que dona control total de l'aparell es permet el luxe de buscar el port. Això és criteri nostre, no una dada: ens sembla que el port mogut ha donat a molta gent la sensació d'haver tancat una cosa que continua oberta.

Si va estar obert, el pedaç no tanca l'assumpte

Ja hem defensat aquí que actualitzar no és netejar, i no repetirem l'argument. El que canvia avui és que aquí el pedaç sí que t'ajuda a detectar, i convé saber exactament fins on. RouterOS corregit revisa la configuració en arrencar, desactiva les entrades sospitoses, deixa avisos al registre i marca l'equip com a Flagged, un estat que es consulta amb /system/device-mode/print. És una funció excel·lent i la frase que l'acompanya a l'avís de CERT Polska és la que cal llegir dues vegades: «the absence of the marker is not proof that the device is safe». Que no surti la marca no vol dir res; que surti, sí.

Per això les dues línies de registre que publica CERT Polska valen més que la marca, i són dues, no una: login failure for user -2 from <ip> via ssh i, la que de debò prova alguna cosa, user <name> added by ssh:-2@<ip>. La primera diu que ho van intentar. La segona diu que van crear un compte. I a la configuració, un usuari privilegiat anomenat ops que ningú no va donar d'alta. El que cal revisar ho enumera el mateix avís: usuaris, scripts, tasques del programador, servidors proxy i túnels. Les tasques del programador són les que més s'obliden i les que millor sobreviuen a un reinici.

MikroTik ho remata amb una frase que sembla de tràmit i no ho és, precisament per la seva primera meitat: «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 fabricant que acaba de donar-te un detector t'està dient, a la mateixa línia, que no te'n refiïs només.

Els dos últims són els que ens traurien la son en un router de frontera, i no per la seva sofisticació. Un túnel o un proxy a l'equip que separa la teva xarxa d'internet sobreviu al fet que canviïs totes les contrasenyes, no apareix a cap antivirus perquè allà no hi ha antivirus, i des de dins de la LAN no es veu: per veure'l cal mirar la configuració del mateix router, que és justament el lloc on ningú no mira dues vegades. Un canvi de contrasenya dona una sensació d'haver actuat que, en aquest escenari, no es correspon amb res.

Què faríem aquesta setmana

Nosaltres també tenim RouterOS a casa —el fem servir, inclòs CHR—, així que aquesta llista no és un consell per a altres. És la nostra.

• Actualitzar, i saber en quina línia de versió és cada caixa abans d'intentar-ho. Les quatre builds corregides viuen en quatre línies diferents, tres d'elles de producció: un parc real té equips a 6.49, a 7.23 i a 7.24 alhora, i el salt entre línies no és la mateixa feina que el salt dins d'una. Aquella llista surt del sistema, no del diagrama; si surt del document ja saps com acaba, perquè l'Excel menteix.
• Desar el registre abans de tocar res, si l'equip va estar exposat. Aquí ens separem de l'ordre que recomanen les dues fonts —totes dues diuen actualitzar primer i mirar després—, i ho diem en veu alta perquè es pugui discutir: un equip amb poc espai de registre que es reinicia pot perdre justament les línies que busques. Copiar el registre fora i anotar la llista d'usuaris costa un minut i decideix si això és una actualització o una resposta a incident, que són dos calendaris i dues converses diferents amb direcció. Després, actualitzar sense esperar.
• Llistar les regles que publiquen administració, i posar-los dues coses que RouterOS ja deixa escriure de franc. Al comentari de cada regla: qui la va demanar i en quina data mor. Amb això, una revisió mensual deixa de ser una auditoria i passa a ser una llista de noms i dates vençudes. No cal cap eina nova, cal escriure-ho. És el més barat de tota aquesta llista i el que evita que d'aquí a tres anys el següent avís trobi la mateixa regla. I no, RouterOS no caduca regles tot sol: la data la fa complir una persona mirant una llista.
• I després el camí que recomana el mateix fabricant, que és el que seguim nosaltres. Les seves paraules: «use a strong VPN like WireGuard to access your router and do not open any management ports at all». La frase sencera ofereix les dues opcions i les ordena: primer «make sure only trusted IP can access it» i després aquell «or better yet». No és una idea nostra ni un argument de venda: és el fabricant dient que filtrar el port està bé i no tenir-lo està millor. Sobre quan WireGuard i quan IPsec ja vam escriure una comparativa honesta, inclòs en quins casos el segon continua guanyant.
• I el bandwidth-test, que és l'oblidat. CERT Polska l'anomena al costat de l'SSH i del WWW/WWW-SSL entre els serveis a desactivar o restringir a xarxes de confiança mentre s'actualitza. És un servei que s'encén una tarda per mesurar un enllaç i es queda encès per sempre, igual que la regla del tallafocs. Mateixa història, una altra línia.

Tancar l'administració tampoc no és gratis

Seria deshonest acabar amb el «tanca-ho tot» i deixar-ho aquí. Si tanques l'administració des d'internet, necessites una altra via per entrar el dia que la línia principal estigui caiguda, que és precisament el dia que cal entrar. Això costa: un mòdem 4G amb la seva tarifa, una línia de reserva, un accés fora de banda, o algú amb clau a una hora raonable. Qui va obrir el port fa tres anys, moltes vegades, el va obrir perquè aquella partida no era al pressupost. Discutir el port sense discutir la via alternativa és lligar-li les mans a algú.

I hi ha un cas en què aquesta llista no es pot aplicar: quan el router no és teu. Si el gestiona el teu operador, tu no toques ni la versió ni les regles. Allà l'entregable no és una regla, és una pregunta per escrit —quina versió corre, quan l'actualitzeu, des d'on s'administra— i una data per a la resposta. Que la caixa sigui d'un altre no trasllada l'avaria a un altre: el que es queda sense servei continues sent tu.

La fallada és inevitable; l'avaria és una decisió de disseny. En aquest cas la decisió de disseny no la va prendre MikroTik el dia que va publicar el CVE. La va prendre algú del teu costat, una tarda qualsevol, resolent una cosa que calia resoldre. La culpa no és seva. La revisió sí que és teva.

El que no afirmem

No diem que RouterOS sigui menys segur que d'altres: no tenim cap xifra comparativa que posi un fabricant per sobre d'un altre, i tampoc no sabem quant va trigar MikroTik des que va rebre el report fins que va publicar l'arranjament, perquè aquella data no està publicada. No sabem quants dels 122.500 equips comptats per Shadowserver estan mal configurats; sabem quants responen, que no és el mateix, i el mateix recompte avisa que no comprova si són vulnerables. No afirmem que la cadena s'hagi fet servir contra cap empresa concreta ni coneixem víctimes amb nom. Tampoc no som part interessada: no revenem MikroTik ni cap altre fabricant de xarxa. I les dues adreces IP que cita CERT Polska no les reproduïm: un indicador d'aquesta mena envelleix en dies i publicar-lo com a llista de bloqueig fa més mal que bé.

Nota de fonts

Tot consultat el 18 de setembre de 2026. Un: l'avís de CERT Polska «Critical vulnerabilities in MikroTik RouterOS are being actively exploited» (5 de setembre de 2026), d'on surten les sis vulnerabilitats coordinades i els components que afecten («the SSH server and client, the bandwidth-test service, X.509 certificate handling, and the WebFig interface»), els tres CVE detallats amb les seves puntuacions CVSS i descripcions literals, el nom MikroTrick, la frase sobre el control total sense autenticació, l'observació d'atacs des de com a mínim el 2 de setembre, la notificació push de MikroTik per primera vegada en la seva història, el mecanisme Flagged amb /system/device-mode/print i el seu advertiment «the absence of the marker is not proof that the device is safe», les dues línies de registre i l'usuari ops, la llista de què revisar (usuaris, scripts, tasques del programador, proxies i túnels), les mesures temporals —desactivar o restringir SSH, WWW/WWW-SSL i bandwidth-test, i no iniciar connexions TLS ni fer servir els clients SSH interns des d'un equip sense pedaç—, i l'atribució de la troballa a Sławomir Rozbicki amb els models GPT-5.5-cyber i GPT-5.6-sol. Dos: la pàgina de seguretat de MikroTik sobre la vulnerabilitat de setembre de 2026, d'on surten les quatre versions corregides amb data del 3 de setembre i les frases citades: la de l'«important security update», la de no publicar detall encara, la del bloqueig per defecte del port, la de WireGuard, la de l'usuari domèstic i la d'inspeccionar la configuració encara que l'equip no estigui en estat Flagged. Tres: el fitxer JSON del catàleg KEV de CISA, versió 2026.09.16 amb 1.713 entrades, descarregat i filtrat per nosaltres: d'allà surten les dates d'alta (10 de setembre) i el termini de correcció (13 de setembre) de CVE-2026-86060 i CVE-2026-67277, l'absència de CVE-2026-67276 i el camp forensicTriage de cada entrada. Quatre: la xifra de Shadowserver del 5 de setembre de 2026, citada literalment —amb el seu parèntesi— a la cobertura del cas; no l'hem poguda comprovar al tauler original. El que és opinió nostra i va marcat com a tal al cos: que el port mogut dona sensació de tancament sense ser-ho, que les excepcions temporals es creen amb caducitat i es desen sense ella, la llista del que faríem aquesta setmana i la decisió de desar el registre abans d'actualitzar, que s'aparta de l'ordre que recomanen les fonts.