MikroTik RouterOS, falle critiche già sfruttate: disponibile l'aggiornamento

Un router compromesso può diventare il punto privilegiato a partire dal quale un aggressore osserva il traffico, modifica regole di rete, crea tunnel, crea account persistenti o usa la connessione della vittima per attaccare altri sistemi. È per questo che le vulnerabilità scoperte in MikroTik RouterOS meritano particolare attenzione. CERT Polska ha documentato 6 falle e ha confermato che almeno due di esse sono già sfruttate per mettere insieme attacchi reali contro apparati con il servizio SSH raggiungibile via Internet. La catena di attacco ha ricevuto il nome MikroTrick.

L’accesso remoto ai router tramite SSH esiste da decenni ed è uno strumento fondamentale per amministratori, provider e gestori di infrastrutture distribuite. Proprio l’esposizione delle interfacce di gestione, però, continua a rappresentare uno dei problemi più delicati.

Nel caso MikroTik la superficie potenziale non è piccola: secondo i dati della Shadowserver Foundation, il 5 settembre 2026 risultavano circa 122.500 dispositivi MikroTik con SSH esposto pubblicamente. Il dato non equivale al numero di sistemi vulnerabili o già compromessi, ma rende bene l’idea della scala sulla quale un exploit automatizzato potrebbe operare.

MikroTrick: due vulnerabilità SSH portano al controllo completo del router

La parte più grave della vicenda nasce dall’unione di due difetti distinti: il primo, CVE-2026-67276, ha un punteggio CVSS di 9,2 e interessa l’autenticazione SSH basata su chiavi RSA. RouterOS, sistema operativo montato sui router MikroTik, confrontava la chiave presentata dal client con quella associata all’utente, ma non verificava tutti i suoi parametri.

Una chiave pubblica RSA non coincide semplicemente con un numero: secondo l’analisi di CERT Polska, RouterOS verificava il tipo della chiave e il modulo, ma ometteva il confronto dell’esponente. Ancora più importante: la successiva verifica della firma utilizzava la chiave presentata dal client. Proprio di recente abbiamo parlato della fattorizzazione del numero RSA-260.

Conoscendo il nome dell’utente e il modulo pubblico della sua chiave RSA, un aggressore poteva costruire una chiave differente, impostare opportunamente l’esponente e produrre una firma accettata dal dispositivo. Non serviva conoscere la chiave privata originale. CERT Polska descrive esplicitamente la possibilità di usare un esponente pari a 1, ottenendo così l’apertura di un canale SSH con i privilegi dell’account preso di mira.

La seconda falla più grave, CVE-2026-86060, anch’essa classificata CVSS 9,2, fornisce invece i privilegi amministrativi.

MikroTik ha pubblicato le correzioni il 3 settembre 2026 nelle versioni RouterOS 7.25beta3, 7.24.2, 7.23.4 e 6.49.21. Due giorni dopo CERT Polska ha diffuso i dettagli tecnici essenziali e la conferma degli attacchi. Secondo le osservazioni dell’agenzia polacca, attività riconducibili alla catena erano già in corso almeno dal 2 settembre: significa che gli aggressori avevano iniziato a sfruttare il problema prima della divulgazione pubblica completa.

Un nome utente costruito ad arte permette l’escalation dei privilegi

CVE-2026-86060 riguarda il modo in cui RouterOS tratta determinati nomi utente durante il login SSH. Un nome che inizia con un carattere proibito può alterare gli argomenti elaborati dal meccanismo interno di autenticazione.

Manipolando il nome utente, l’attaccante riesce a modificare le regole applicate alla sessione RouterOS e ad arrivare a privilegi amministrativi completi.

Da qui nasce l’attacco MikroTrick: CVE-2026-67276 consente di superare l’autenticazione tramite chiave RSA; CVE-2026-86060 trasforma poi la sessione ottenuta in un accesso amministrativo.

L’aspetto critico non è soltanto la presenza di due bug gravi, ma il modo in cui si completano a vicenda. Un controllo incompleto durante l’autenticazione e un problema nella gestione degli argomenti diventano, combinati, una strada verso il controllo del dispositivo senza disporre delle normali credenziali amministrative.

L’indagine ha portato, alla fine, alla scoperta di 6 vulnerabilità insite in RouterOS: oltre alle due già esaminate, CERT Polska ha documentato problemi nel servizio bandwidth-test, nel client SSH, nella validazione dei certificati X.509 e nell’interfaccia WebFig. Non tutte hanno lo stesso impatto né le stesse versioni interessate, ma alcune sono tecnicamente notevoli.

RouterOS introduce il controllo Flagged, ma non è un certificato di pulizia

Le nuove release del sistema operativo alla base del funzionamento dei router MikroTik includono anche un meccanismo destinato a individuare alcune modifiche sospette.

Durante l’avvio, RouterOS cerca tracce conosciute di manipolazioni non autorizzate della configurazione; se le riconosce può disabilitare determinate voci, registrare un messaggio critico nel log e impostare lo stato Flagged.

L’amministratore può verificarlo anche tramite il comando /system/device-mode/print, osservando il valore del parametro Flagged. Il meccanismo si integra con Device Mode, funzione che RouterOS usa per limitare alcune capacità del dispositivo e ridurre ciò che un eventuale aggressore può sfruttare.

Attenzione però a non interpretare un valore flagged: no come la prova che il router sia integro: il controllo riconosce soltanto alcune tracce note. Un aggressore potrebbe aver modificato elementi differenti, eliminato indicatori oppure usato tecniche non previste dal rilevatore.

Dopo l’aggiornamento conviene quindi controllare account, script, attività dello scheduler, proxy, tunnel, regole e altre modifiche che non trovano una spiegazione amministrativa.

Perché SSH non dovrebbe essere esposto su Internet

La vicenda MikroTrick riporta a una regola che dovrebbe essere quasi scontata nella gestione dei router: le interfacce amministrative non dovrebbero risultare direttamente raggiungibili da Internet, neppure quando usano protocolli cifrati come SSH.

Il fatto che SSH protegga la sessione da intercettazioni e supporti l’autenticazione mediante chiave pubblica non elimina infatti la superficie d’attacco del daemon che resta in ascolto sulla porta TCP 22.

Una vulnerabilità nel parser del protocollo, nella gestione dell’autenticazione o nella sequenza delle fasi del protocollo, come dimostrano proprio CVE-2026-67276 e CVE-2026-67279, può entrare in gioco prima ancora che le normali credenziali costituiscano una barriera efficace. Cambiare la porta SSH riduce al massimo il rumore prodotto dagli scanner più banali, ma non rappresenta una misura di sicurezza sostanziale.

Su RouterOS è preferibile bloccare l’accesso SSH dalla WAN attraverso il firewall e consentirlo soltanto dalla LAN di amministrazione o da una rete VPN dedicata.

MikroTik permette anche di restringere il servizio mediante /ip service specificando gli indirizzi ammessi, ma la stessa documentazione raccomanda il firewall per separare realmente le reti non fidate.

Per l’accesso remoto, una configurazione più robusta consiste nell’esporre soltanto l’endpoint WireGuard sulla WAN e rendere SSH raggiungibile dall’indirizzo o dalla subnet assegnata ai peer VPN autorizzati.