Il 5 settembre 2026 CERT Polska, il CSIRT nazionale polacco che opera all'interno di NASK, ha pubblicato un avviso urgente: sei vulnerabilità in MikroTik RouterOS, due delle quali, combinate, permettono di prendere il controllo completo di un router senza alcuna autenticazione, a condizione che il servizio SSH sia raggiungibile da Internet. Alla catena è stato dato il nome MikroTrick.

Non si tratta di uno scenario teorico. Gli attacchi sono in corso dal 2 settembre, e il team polacco ha confermato di aver osservato compromissioni riuscite.

I fatti

MikroTik ha rilasciato le correzioni il 3 settembre nelle versioni 7.25beta3, 7.24.2, 7.23.4 e 6.49.21. Per la prima volta nella sua storia l'azienda lettone ha accompagnato l'aggiornamento con una notifica push inviata agli utenti che hanno installato l'app MikroTik: un segnale della gravità attribuita al problema.

Le tre vulnerabilità principali sono:

  • CVE-2026-67276 (CVSS 9.2) — bypass dell'autenticazione SSH. RouterOS non confrontava l'intera chiave pubblica RSA associata a un utente, ma soltanto il modulo. Un attaccante che conoscesse il nome utente e il modulo della sua chiave poteva costruire una chiave diversa e accedere via SSH senza possedere la chiave privata, ottenendo i privilegi dell'account preso di mira.
  • CVE-2026-86060 (CVSS 9.2) — manipolazione dei privilegi di sessione. RouterOS non gestiva correttamente i nomi utente che iniziano con un carattere non consentito: usando un nome costruito ad arte era possibile ottenere una sessione con privilegi amministrativi completi.
  • CVE-2026-67277 (CVSS 8.8) — divulgazione di memoria e crash via bandwidth-test. Il servizio consentiva a una connessione non autenticata di raggiungere uno stato riservato agli utenti autenticati; combinato con la lettura di dati non inizializzati dal buffer dei pacchetti e con un integer underflow nella validazione delle dimensioni, permetteva di leggere memoria kernel o di provocare il riavvio del dispositivo.

Le altre tre falle, di gravità inferiore, riguardano il client SSH, la gestione dei certificati X.509 e l'interfaccia WebFig.

La Shadowserver Foundation ha misurato, in una finestra di scansione di 24 ore chiusa il 5 settembre, almeno 122.500 dispositivi MikroTik con SSH accessibile da Internet. È il numero degli esposti, non dei vulnerabili: la rilevazione non verificava la versione. Ma è la dimensione della superficie su cui MikroTrick funziona.

Indicatori di compromissione

CERT Polska ha pubblicato indicatori concreti. Nei log di RouterOS gli attacchi osservati lasciano tracce di questo tipo:

login failure for user -2 from <ip> via ssh
user <nome> added by ssh:-2@<ip>

Un ulteriore indicatore è la presenza di un utente con privilegi elevati chiamato ops. Le compromissioni riuscite analizzate, inclusa la creazione di quell'account, provenivano dall'indirizzo 82.192.72.4, attivo almeno dal 2 settembre; un secondo indirizzo, 103.102.31.18, è stato usato in tentativi di sfruttamento della stessa catena.

Le versioni corrette introducono un meccanismo che all'avvio analizza la configurazione alla ricerca di segni noti di modifiche non autorizzate, disabilita le voci sospette riconosciute, scrive un messaggio critico nel log e imposta un marcatore Flagged, verificabile con /system/device-mode/print. Attenzione però: il meccanismo rileva solo alcune tracce, e l'assenza del marcatore non è una prova che il dispositivo sia integro.

Il dettaglio che merita attenzione: come sono state trovate

CERT Polska ha dichiarato di aver individuato le vulnerabilità utilizzando i modelli GPT-5.5-cyber e GPT-5.6-sol, nell'ambito del programma di collaborazione di OpenAI con agenzie governative. Il team ha precisato che non si è trattato di un singolo prompt: ogni ipotesi ha richiesto conferma su sistemi RouterOS reali, test di controllo negativi, ripetizione su macchine pulite e valutazione d'impatto da parte dei ricercatori. La parte più laboriosa è rimasta la costruzione del laboratorio e la verifica dei risultati.

Per chi difende, la conseguenza operativa è comunque netta: la ricerca di vulnerabilità su firmware proprietari si sta industrializzando. E il team polacco ha scelto di pubblicare in anticipo proprio perché, essendo le patch già pubbliche, l'analisi comparativa dei binari stava permettendo alla comunità di ricostruire i bug corretti. La finestra fra patch e sfruttamento di massa si sta accorciando, e i piani di aggiornamento tarati su cicli mensili non reggono più.

Cosa significa per le aziende italiane

MikroTik in Italia è ovunque, ed è ovunque proprio dove è più difficile da governare. È la scelta standard dei WISP e dei piccoli operatori che portano connettività nelle aree non coperte dalla fibra; è il router che molti integratori installano nelle PMI perché costa una frazione di un apparato enterprise e fa le stesse cose; è l'apparato che gestisce la VPN dello studio professionale, del capannone, della filiale.

Il problema non è il prodotto, che è tecnicamente valido. Il problema è il modello di manutenzione che gli si costruisce attorno. Un router MikroTik viene tipicamente configurato una volta, in fase di installazione, da un tecnico che poi non torna. Non ha un contratto di manutenzione software, non è nell'inventario degli asset, non ha un responsabile che riceva i bollettini del produttore. La lunghissima coda di installazioni ancora su RouterOS 6.x — per le quali esiste una patch, la 6.49.21 — racconta esattamente questo.

C'è poi la questione di cosa perde chi perde il router. Un attaccante con privilegi amministrativi su RouterOS non ottiene un singolo sistema: ottiene il punto attraverso cui passa tutto il traffico dell'azienda. Può modificare le impostazioni DNS e dirottare la risoluzione dei nomi, creare tunnel verso l'esterno, aggiungere regole NAT che espongono sistemi interni, installare script e scheduler che sopravvivono al riavvio, e naturalmente osservare o deviare il traffico non cifrato. Se il router è anche il concentratore VPN, l'attaccante è dentro la rete, con l'aggravante che il traffico dei dipendenti in smart working transita da un dispositivo che non è più affidabile.

Va sottolineato l'aspetto più oneroso e meno compreso: aggiornare non basta. Se il dispositivo è stato compromesso, la patch chiude la falla ma non rimuove le modifiche già introdotte — utenti aggiunti, script pianificati, tunnel, proxy, regole di firewall. CERT Polska è esplicito: un dispositivo con indicatori di compromissione va isolato, i log e la configurazione vanno messi in sicurezza per l'analisi, e solo dopo il router va riportato alle impostazioni di fabbrica e riconfigurato da una configurazione verificata. Non va ripristinato un backup completo proveniente dal dispositivo potenzialmente compromesso, perché il backup contiene anche ciò che l'attaccante ha aggiunto.

Per una PMI questo significa fermo del collegamento, riconfigurazione da zero e rotazione di tutte le credenziali e chiavi in uso. È il motivo per cui vale la pena verificare oggi, prima che il numero di dispositivi da ricostruire diventi ingestibile.

Il quadro normativo

Chi fornisce reti pubbliche di comunicazione elettronica o servizi di comunicazione elettronica accessibili al pubblico rientra fra i soggetti in perimetro NIS2 (D.Lgs. 138/2024): i WISP e gli operatori locali che usano massicciamente RouterOS sono quindi tenuti alla notifica al CSIRT Italia degli incidenti significativi, con pre-notifica entro 24 ore e notifica entro 72 ore. Con la scadenza del 31 ottobre 2026 per la piena operatività delle misure di sicurezza di base previste dalle determinazioni ACN, un parco di apparati non inventariato e non aggiornato è una non conformità documentabile, non solo un rischio tecnico.

Per le aziende che il router se lo ritrovano in sede, il tema è l'articolo 32 del GDPR: la compromissione dell'apparato che vede tutto il traffico è di per sé un evento che impone una valutazione ai sensi dell'articolo 33, tanto più perché stabilire quali dati siano stati effettivamente osservati richiede log che, sulla maggior parte di questi dispositivi, non vengono conservati.

Cosa fare subito

  • Aggiornare RouterOS a una delle versioni corrette: 7.25beta3, 7.24.2, 7.23.4 o 6.49.21. Vale anche per i dispositivi che si ritengono non esposti.
  • Verificare il marcatore Flagged con il comando /system/device-mode/print e cercare nei log il messaggio di compromissione. Ricordando che l'assenza del marcatore non esclude nulla.
  • Cercare gli indicatori pubblicati: le voci di log con l'utente -2, la presenza di un utente ops con privilegi elevati, e connessioni dagli indirizzi 82.192.72.4 e 103.102.31.18.
  • Ispezionare la configurazione alla ricerca di utenti, script, attività dello scheduler, server proxy e tunnel che non si riconoscono. Questo passaggio va fatto anche sui dispositivi aggiornati in tempo.
  • Se non è possibile aggiornare subito, disabilitare o restringere alle sole reti di gestione fidate i servizi esposti — in particolare SSH, WWW/WWW-SSL e il server bandwidth-test — ed evitare di avviare connessioni TLS o di usare i client SSH integrati (/system ssh, /system ssh-exec) da un dispositivo non aggiornato. Sono misure temporanee: non sostituiscono la patch.
  • In caso di compromissione accertata o sospetta, isolare il dispositivo, mettere in sicurezza log e configurazione prima del reset, ripristinare le impostazioni di fabbrica, riconfigurare da una base verificata e cambiare tutte le password, le chiavi e i segreti in uso. Non cancellare il marcatore Flagged prima di aver completato l'analisi.
  • Segnalare l'incidente al CSIRT Italia se si rientra fra i soggetti obbligati, seguendo le procedure ACN.
  • Chiudere la causa a monte: portare l'amministrazione dei router dentro il perimetro di gestione, con un inventario, un responsabile e un canale che riceva i bollettini di sicurezza del produttore.