MikroTik RouterOS: la catena “MikroTrick” è sfruttata attivamente, patch urgente

Bastano un servizio SSH esposto su Internet e nessuna credenziale. Con questi soli requisiti, almeno dal 2 settembre, alcuni attaccanti prendono il controllo completo di dispositivi MikroTik RouterOS e lasciano come firma un account amministrativo chiamato ops . Lo ha confermato il 5 settembre 2026 CERT Polska, il team che ha scoperto le vulnerabilità e ha chiamato la catena “MikroTrick”. MikroTik ha pubblicato le versioni corrette su tutti i canali e raccomanda di aggiornare subito.

Cosa è successo

Il team polacco ha individuato sei vulnerabilità in RouterOS, due delle quali critiche, e ne ha coordinato la divulgazione. Combinandone due, un attaccante ottiene privilegi amministrativi completi senza autenticarsi, purché il dispositivo esponga SSH su rete pubblica. Le falle riguardano il server e il client SSH, il servizio bandwidth-test, la gestione dei certificati X.509 e l’interfaccia WebFig.

Secondo i record NVD, sono interessate tutte le release RouterOS 6.x precedenti alla 6.49.21, le 7.x precedenti alla 7.23.4 e la 7.24 precedente alla 7.24.2. I punteggi che seguono sono i CVSS 4.0 assegnati da CERT Polska, ente assegnatario delle CVE; NVD non ha ancora pubblicato una propria valutazione.

Le tre vulnerabilità principali sono:

• CVE-2026-67276 (CVSS 9.2): elusione dell’autenticazione SSH. RouterOS non confrontava per intero la chiave pubblica RSA associata a un utente. Chi conosceva il nome utente e il modulo pubblico della chiave poteva costruire una chiave diversa e autenticarsi senza la chiave privata, con i privilegi dell’account bersaglio.
• CVE-2026-86060 (CVSS 9.2): elevazione dei privilegi di sessione tramite un nome utente costruito ad arte. Il meccanismo di login SSH gestiva male i nomi utente che iniziano con un carattere non ammesso; l’attaccante poteva così modificare la maschera dei permessi e ottenere una sessione con pieni diritti amministrativi.
• CVE-2026-67277 (CVSS 8.8): il servizio bandwidth-test permetteva a una connessione non autenticata di raggiungere uno stato riservato agli utenti autenticati. Insieme a due ulteriori difetti (esposizione di dati non inizializzati e integer underflow nella verifica delle dimensioni), consentiva di leggere memoria del kernel o di provocare un riavvio remoto del sistema.

L’elenco completo delle sei CVE è disponibile su una pagina dedicata di CERT Polska. Il team spiega di aver anticipato la pubblicazione per una ragione precisa: i pacchetti corretti erano già pubblici e il confronto tra le versioni aveva permesso alla comunità di ricostruire alcune correzioni. Non ha diffuso codice di exploit né dettagli utili ad automatizzare gli attacchi.

Gli attacchi osservati e gli indicatori di compromissione

CERT Polska dichiara di aver ricevuto conferma che la catena MikroTrick viene usata per assumere il controllo di dispositivi con SSH esposto e che le patch bloccano gli attacchi osservati. Gli attacchi riusciti, compresa la creazione dell’account ops , provengono dall’indirizzo IP 82.192.72.4 e risalgono almeno al 2 settembre. Un secondo indirizzo, 103.102.31.18, è stato usato in tentativi di sfruttamento della stessa catena.

Nei log di RouterOS l’attacco lascia due tracce riconoscibili: un accesso fallito per l’utente -2 via SSH, seguito dalla creazione di un nuovo utente da parte di ssh:-2@<ip> . La presenza di uno qualsiasi di questi elementi va indagata subito. La loro assenza, avverte il team, non esclude un’attività non autorizzata.

La risposta del vendor

Il bollettino di sicurezza MikroTik, datato 3 settembre 2026, definisce l’aggiornamento importante e afferma che la maggior parte delle configurazioni non è a rischio. Conferma che la correzione è inclusa in RouterOS 7.25beta3, 7.24.2, 7.23.4 e 6.49.21. Il 4 settembre è uscita anche la 7.23.5 per il ramo long-term: non aggiunge correzioni di sicurezza, ma risolve una regressione del DHCP IPv6 introdotta dalla 7.23.4, ed è quindi la versione a cui puntare. Il vendor non ha ancora pubblicato dettagli tecnici, per dare tempo agli amministratori di aggiornare. Per gli utenti domestici, scrive, il rischio non è immediato, ma consiglia comunque a tutti di aggiornare. CERT Polska riferisce inoltre che MikroTik, per la prima volta, ha inviato una notifica push agli utenti dell’app mobile ufficiale.

Le release corrette utilizzano anche il meccanismo Flagged, presente da tempo nel device-mode di RouterOS. All’avvio il sistema analizza la configurazione alla ricerca di segni noti di modifiche non autorizzate; disabilita le voci sospette, scrive un messaggio critico nel log e imposta lo stato “Flagged”, descritto nella pagina dedicata del manuale. CERT Polska precisa però tre cose: il meccanismo rileva solo alcune tracce; l’assenza del marcatore non prova che il dispositivo sia integro; non si può escludere che il vendor abbia corretto anche vulnerabilità ignote al team e non descritte nelle note di rilascio.

Perché conta per l’Italia

RouterOS è usato, in Italia come altrove, da operatori ISP e WISP, in reti aziendali e di PMI e in contesti edge. La catena colpisce esattamente i dispositivi che espongono SSH su Internet. Un dato di contesto, datato ma indicativo, viene dal rapporto Eclypsium del dicembre 2021: su oltre due milioni di dispositivi MikroTik con interfacce di gestione raggiungibili dalla rete, circa 300.000 risultavano vulnerabili a falle note. L’Italia figurava tra i cinque Paesi più interessati, con Cina, Brasile, Russia e Indonesia.

Al momento non risultano vittime italiane confermate pubblicamente e CSIRT Italia non ha pubblicato un avviso su questa catena. Lo stesso CSIRT era però già intervenuto sull’ecosistema MikroTik nell’ultimo anno. Il 29 ottobre 2025 ha pubblicato un alert sul componente WebFig di RouterOS e SwitchOS; il 17 gennaio 2025 un bollettino su una botnet di dispositivi MikroTik compromessi.

Un router o gateway compromesso offre all’attaccante persistenza a livello di rete, intercettazione o deviazione del traffico, tunnel verso l’esterno e movimento laterale verso i sistemi interni. È il modello, ormai documentato, dei dispositivi di rete usati come infrastruttura offensiva. Va aggiunta una considerazione normativa: gli obblighi di notifica NIS2 al CSIRT Italia sono operativi dal 15 gennaio 2026, quindi un dispositivo di frontiera compromesso può diventare rapidamente un incidente da segnalare per i soggetti in perimetro.

Cosa fare subito

1. Aggiornare senza attendere a RouterOS 7.24.2 (stable), 7.23.5 (long-term; la 7.23.4 contiene la stessa correzione ma soffre della regressione DHCP IPv6), 6.49.21 (long-term v6) o 7.25beta3, o a versioni successive.
2. Dopo l’aggiornamento, controllare nel log l’eventuale messaggio di compromissione e il valore del marcatore Flagged con /system/device-mode/print . Verificare la presenza di utenti sconosciuti (in particolare ops ), script, attività dello scheduler, proxy e tunnel non riconosciuti.
3. Se la patch non è applicabile subito, disattivare i servizi esposti o limitarne l’accesso alle sole reti di gestione fidate, in particolare SSH, WWW/WWW-SSL e il server bandwidth-test. Evitare di avviare connessioni TLS dal dispositivo non aggiornato e di usare i client SSH integrati ( /system ssh e /system ssh-exec ) verso host o reti non fidati. Sono misure temporanee che non sostituiscono la patch.
4. In caso di compromissione sospetta o confermata, isolare il dispositivo e mettere al sicuro log e configurazione prima di qualsiasi ripristino. Segnalare l’evento al CSIRT competente. Ripristinare le impostazioni di fabbrica, riconfigurare da una configurazione verificata e cambiare password, chiavi e altri segreti. Non ripristinare alla cieca una copia di sicurezza completa proveniente da un dispositivo potenzialmente compromesso; non cancellare lo stato Flagged prima di aver completato l’analisi.

Vulnerabilità trovate con l’aiuto degli LLM

Un dettaglio di metodo merita attenzione. CERT Polska riferisce di aver individuato le vulnerabilità con il supporto dei modelli GPT-5.5-cyber e GPT-5.6-sol, disponibili al team nell’ambito del programma OpenAI Government and Trust Agency Collaboration. I modelli hanno lavorato in un ambiente di ricerca agentico su un laboratorio isolato. Hanno automatizzato la creazione delle macchine di prova, il confronto tra versioni e l’analisi di RFC e codice binario. Particolarmente efficace, secondo il team, è stata la modellazione dei protocolli come macchine a stati, per verificare cosa accade quando una fase viene saltata, ripetuta o eseguita nell’ordine sbagliato.

Ogni ipotesi ha però richiesto conferma su sistemi RouterOS reali, test di controllo negativi e valutazione d’impatto da parte dei ricercatori. I modelli, conclude CERT Polska, hanno accelerato l’analisi senza sostituire la verifica umana. È una lezione coerente con quella portata al Forum ICT Security 2025 dal Politecnico di Torino sugli agenti AI applicati all’individuazione delle CVE: l’architettura dell’agente e il controllo umano pesano più del modello.