MikroTik RouterOS sotto attacco: le falle SSH sfruttate e cosa fare subito

Il 3 settembre 2026 MikroTik ha pubblicato un aggiornamento di sicurezza per RouterOS, il sistema operativo dei suoi router, definendolo “importante” e senza spiegare cosa correggesse. Due giorni dopo CERT Polska, il centro di risposta agli incidenti informatici polacco che aveva scoperto e segnalato i problemi, ha rotto il silenzio: sei vulnerabilità, due delle quali combinate permettono a chiunque di prendere il controllo completo del router senza conoscere alcuna password, a patto che il servizio SSH sia raggiungibile da internet. La catena di attacco ha un nome, MikroTrick, ed è già in uso: le intrusioni ricostruite risalgono almeno al 2 settembre, il giorno prima delle patch.

I router MikroTik sono ovunque dove serve un apparato di rete solido a un prezzo contenuto: uffici, studi professionali, piccoli provider, sedi collegate in VPN, rack di colocation. Spesso li ha installati un tecnico anni fa, funzionano, e nessuno li ha più aperti. È esattamente il profilo del dispositivo che questa vicenda mette a rischio.

Qui sotto: cosa è stato scoperto, chi è esposto davvero e chi no, come capire se un router è già stato violato, come si aggiorna e cosa cambiare in configurazione perché non capiti di nuovo. Le informazioni vengono dal bollettino MikroTik, dall’avviso di CERT Polska e dalla documentazione ufficiale, linkati in fondo.

Cosa è stato scoperto: sei falle, due bastano per entrare senza password

Le due vulnerabilità che formano la catena MikroTrick riguardano entrambe il server SSH di RouterOS, il servizio che permette di amministrare il router da riga di comando a distanza. Sono classificate con gravità 9,2 su 10.

CVE-2026-67276: quando un utente si autentica con una chiave crittografica invece che con una password, RouterOS non verificava la chiave per intero, ma solo una sua parte. Chi conosce la parte pubblica della chiave di un utente autorizzato può costruirne una diversa che il router accetta lo stesso, ed entrare come quell’utente senza possederne la chiave privata. È come una serratura che controlla la forma della chiave ma non i denti.
CVE-2026-86060: la procedura di accesso via SSH gestiva male i nomi utente che iniziano con un carattere non ammesso. Con un nome costruito ad arte, una sessione che dovrebbe avere permessi limitati ottiene i privilegi di amministratore completo.

Prese una alla volta hanno dei prerequisiti. Combinate, secondo CERT Polska, consentono “il controllo completo del dispositivo senza autenticazione”. Le altre quattro falle sono meno gravi ma non trascurabili: una nel servizio bandwidth-test (lo strumento di misura della banda, porta 2000) permette senza autenticazione di leggere frammenti di memoria del sistema o di far riavviare il router; una nell’interfaccia web WebFig permette di leggere file riservati, compresi archivi di configurazione con credenziali; le ultime due toccano il client SSH integrato e la gestione dei certificati X.509.

Un dettaglio che spiega la corsa contro il tempo: MikroTik ha rilasciato la correzione senza dettagli, ma le patch di RouterOS sono pubbliche e confrontabili. Il 4 settembre era già online un’analisi indipendente che, mettendo a confronto la versione 7.23.3 con la 7.23.4, aveva ricostruito il meccanismo delle falle. A quel punto tacere non serviva più a nessuno, e CERT Polska ha pubblicato l’avviso il 5.

Chi è a rischio davvero (e chi no)

MikroTik scrive che “la maggior parte delle configurazioni non è a rischio”. È vero, con una precisazione importante. La configurazione predefinita di un router MikroTik blocca l’accesso ai servizi di gestione dalla porta WAN, quindi un apparato installato con le impostazioni di fabbrica non espone SSH a internet e non è attaccabile da fuori.

Il problema sono tutti gli altri: i router configurati da zero da un tecnico, quelli in cui le regole del firewall sono state rimosse “per far funzionare una cosa”, quelli in cui SSH è stato aperto per comodità di gestione remota, quelli dei provider e dei datacenter. La Shadowserver Foundation, una fondazione che scandaglia internet per conto dei CERT nazionali, il 5 settembre contava circa 122.500 router MikroTik con SSH raggiungibile da chiunque. Ognuno di quelli, se non aggiornato, si prende con uno script.

Le versioni coinvolte sono tante. Alla domanda di un utente sul forum ufficiale se anche le 7.20 e 7.21 fossero vulnerabili, lo staff MikroTik ha risposto che sono coinvolte “molte annate di versioni”: la correzione esiste solo dalle release del 3 settembre. Non conta quanto è recente il router, conta quanto è recente il sistema operativo.

Come capire se il router è già stato violato

Prima di aggiornare vale la pena guardare, perché l’aggiornamento chiude la porta ma non caccia chi è già entrato. CERT Polska descrive cosa lasciano dietro di sé gli attacchi osservati:

nel registro eventi compaiono righe come login failure for user -2 from <ip> via ssh e subito dopo user <nome> added by ssh:-2@<ip>: quel -2 al posto del nome utente è la firma della falla sfruttata;
viene creato un utente amministratore sconosciuto, nei casi osservati chiamato ops;
compaiono script, attività pianificate, proxy o tunnel che nessuno ha configurato.

Dalla console del router i controlli sono questi:

/log/print where message~"-2"
/system/history/print
/user/print
/system/script/print
/system/scheduler/print
/ip/proxy/print
/ip/socks/print

Se il registro è già stato sovrascritto, e su un router lo è in fretta, l’assenza di righe sospette non prova nulla: contano gli utenti, gli script e le regole che non riconosci.

MikroTik ha aggiunto una rete di sicurezza in più. Le versioni corrette, al primo avvio, esaminano la configurazione alla ricerca di tracce note di compromissione: se le trovano, disattivano le voci sospette, scrivono un messaggio critico nel registro e impostano il router in stato Flagged. Si controlla con /system/device-mode/print. In quello stato il router continua a funzionare, ma non permette di creare nuove attività pianificate, proxy, tunnel VPN o condivisioni finché non si interviene di persona: per togliere il marcatore serve un comando confermato premendo il tasto fisico di reset o spegnendo l’apparato. La documentazione è chiara su due punti: lo stato Flagged non cancella la configurazione, che va comunque ispezionata riga per riga, e il meccanismo riconosce solo tracce note, quindi un router non marcato non è per forza pulito.

Cosa fare adesso: aggiornare, poi verificare

Le versioni corrette sono 7.24.2 (canale stable), 7.23.4 (long-term), 6.49.21 per chi è ancora sulla vecchia serie 6 e la 7.25beta3 per chi usa il canale di sviluppo. Dalla console:

/system/package/update/check-for-updates
/system/package/update/install

Il router si riavvia da solo al termine: su un apparato in produzione serve una finestra di pochi minuti. Prima dell’aggiornamento conviene esportare la configurazione con /export file=prima-aggiornamento e scaricare il file, per la stessa ragione per cui si fanno i backup prima di ogni intervento: se qualcosa va storto, si torna indietro.

Dopo l’aggiornamento, non prima:

controllare /system/device-mode/print e il registro eventi per il messaggio Flagged;
ripetere i controlli della sezione precedente su utenti, script, attività pianificate, proxy e tunnel;
cambiare tutte le password del router e rigenerare le chiavi SSH degli utenti, perché un attaccante che ha avuto accesso amministrativo può aver letto la configurazione completa, credenziali comprese;
se il router faceva da concentratore VPN, considerare compromesse anche le chiavi dei tunnel e rigenerarle.

Se un router mostra segni di compromissione e non si è in grado di ricostruire cosa è stato toccato, la strada più sicura è un ripristino alle impostazioni di fabbrica con la versione corretta e una riconfigurazione da un export verificato di prima dell’incidente.

Chi non può aggiornare subito ha una sola alternativa temporanea, indicata sia da MikroTik sia da CERT Polska: rendere irraggiungibili dall’esterno SSH, l’interfaccia web (WWW e WWW-SSL) e il servizio bandwidth-test. Riduce la superficie, non risolve.

Non basta aggiornare: l’accesso di gestione non va esposto

La lezione più utile di questa storia non riguarda MikroTik. Le interfacce di amministrazione di un router (SSH, WebFig, Winbox, l’API) non dovrebbero mai essere raggiungibili da internet, a prescindere dalle falle del momento. È lo stesso principio per cui la porta SSH dei server non si espone e per cui i tentativi automatici di indovinare le password, migliaia al giorno su qualunque cosa risponda, colpiscono anche i router: già a luglio la CISA, l’agenzia statunitense per la sicurezza informatica, aveva pubblicato due avvisi sull’API di RouterOS, uno dei quali segnala che non limita i tentativi di accesso falliti.

Nella pratica, la configurazione che consigliamo e applichiamo:

/ip/firewall/address-list/add list=gestione address=192.168.10.0/24
/ip/firewall/filter/add chain=input protocol=tcp dst-port=22,80,443,2000,8291,8728,8729 src-address-list=!gestione action=drop place-before=0
/ip/service/disable telnet,ftp,www,api,api-ssl
/tool/bandwidth-server/set enabled=no
/ip/ssh/set strong-crypto=yes

La prima regola scarta qualunque connessione ai servizi di gestione che non provenga dalla rete interna di amministrazione. Le altre spengono ciò che non serve. Lo staff MikroTik, sempre sul forum, ha precisato che limitare l’indirizzo sorgente nel servizio (/ip/service/set ssh address=...) è meno efficace di una regola firewall, perché il firewall scarta il pacchetto prima che il servizio lo riceva.

Per gestire il router da remoto la risposta giusta è una VPN come WireGuard, che RouterOS integra da anni: si entra nel tunnel con una chiave, e solo da dentro il tunnel si raggiunge SSH. È anche la raccomandazione esplicita del bollettino MikroTik. Il resto è disciplina: un inventario degli apparati con versione e data dell’ultimo aggiornamento, e una regola per cui gli aggiornamenti di sicurezza di un router si applicano entro pochi giorni, come per qualsiasi altro software che regge la produzione.

In sintesi

Sei falle in RouterOS, due delle quali insieme permettono di prendere un router MikroTik con SSH esposto senza alcuna credenziale, sono sfruttate in rete dal 2 settembre 2026. Le versioni 7.24.2, 7.23.4 e 6.49.21 le correggono e aggiungono un controllo automatico che marca come Flagged i router con tracce note di compromissione. La configurazione di fabbrica non è esposta, ma decine di migliaia di router configurati a mano lo sono. Si verifica il registro e gli utenti, si aggiorna, si cambiano le password, e si chiude per sempre l’accesso di gestione da internet, spostandolo dentro una VPN.

# MikroTik RouterOS sotto attacco: le falle SSH sfruttate e cosa fare subito