Aggiornamento. Questo articolo segue quello dell'8 settembre, MikroTrick: due falle in RouterOS consegnano i router MikroTik senza password. Lo scriviamo perché, nel frattempo, sono cambiati due elementi che incidono su ciò che chi gestisce questi apparati deve verificare.

Cosa è cambiato

Il primo sviluppo riguarda CISA. Il 25 settembre 2026 l'agenzia americana ha inserito nel catalogo delle vulnerabilità sfruttate attivamente (KEV) la CVE-2026-67279, un difetto di RouterOS classificato come applicazione impropria del flusso di lavoro comportamentale. Secondo le fonti consultate, consente a un client non autenticato di aprire canali di sessione e inviare richieste di esecuzione sul servizio SSH. Il punteggio CVSS attribuito è 6,9, cioè medio: un numero che, preso da solo, porterebbe molti team a rimandare l'intervento. Il fatto che sia in KEV dice il contrario.

Il secondo sviluppo è una correzione. Nell'avviso iniziale, CERT Polska aveva indicato che la catena MikroTrick combinava la CVE-2026-67276 (bypass dell'autenticazione SSH per chiave pubblica) con la CVE-2026-86060 (privilegi di sessione con nome utente costruito ad arte). Secondo quanto riportato da una fonte di analisi che ricostruisce la revisione, l'assessment è stato aggiornato il 22 settembre: la catena effettivamente usata negli attacchi abbina la CVE-2026-86060 alla CVE-2026-67279, non alla 67276. La 67276 resta una vulnerabilità distinta, che richiede di conoscere un account e concede un accesso limitato. Ricercatori di Bishop Fox hanno dimostrato prese di controllo amministrative su build RouterOS 7.x; sulla versione 6, la catena aggira l'autenticazione ma non arriva al controllo amministrativo.

Nota di prudenza: la correzione di CERT Polska emerge da una fonte secondaria, mentre la pagina primaria che abbiamo consultato riporta ancora il testo originale senza menzionare la CVE-2026-67279. Invitiamo a verificare direttamente il bollettino MikroTik e il catalogo CISA, dove la voce è presente.

Versioni corrette: nulla cambia, con un'aggiunta

Le versioni che chiudono la catena restano quelle già indicate: RouterOS 7.24.2, 7.23.4, 6.49.21 o successive (oltre alla 7.25beta3). Per la CVE-2026-67278, una delle altre falle del bollettino, servono invece 7.24.3 e 7.23.6: chi si era fermato alla 7.24.2 o alla 7.23.4 ha chiuso la catena principale ma non necessariamente tutto il pacchetto. Gli attacchi, ricostruiti da CERT Polska, sono iniziati il 2 settembre e le patch sono uscite il 3.

Le tracce osservate nelle compromissioni sono quelle già note: creazione di un account privilegiato chiamato ops, estrazione di file diagnostici che contengono la configurazione, e persistenza tramite script e attività pianificate.

Cosa significa per le aziende italiane

Questo aggiornamento serve a correggere una convinzione che si diffonde in fretta: ho già aggiornato a inizio mese, sono a posto. Sono cose diverse, e per tre motivi.

Primo, la finestra di esposizione è già trascorsa. Gli attacchi partono il 2 settembre, la patch il 3, l'inserimento in KEV il 25. In quei ventitré giorni, un router con SSH raggiungibile da Internet e non ancora aggiornato è stato un bersaglio; aggiornare oggi chiude la porta ma non dice nulla su chi è già entrato. Per il router di una PMI o di un piccolo provider locale, il criterio non è «ho la versione giusta» ma «ho verificato che nessuno si sia già stabilito».

Secondo, la classificazione CVSS non è la priorità. Una vulnerabilità con punteggio 6,9 diventa critica quando è parte di una catena sfruttata. Chi imposta la gestione delle patch soltanto sulla soglia di gravità, come fanno molti capitolati e molti fornitori di servizi gestiti, avrebbe messo questa voce in coda. Il catalogo KEV, e la sua controparte europea, sono un criterio di priorità più affidabile del solo punteggio.

Terzo, la scarsa tracciabilità degli errori di attribuzione. La correzione della catena mostra un problema pratico per chi fa audit e reportistica: se i vostri documenti di rischio citano la CVE-2026-67276 come «la» falla di MikroTrick, vanno aggiornati. Non cambia le azioni di correzione, ma cambia ciò che si scrive in un registro incidenti o in una notifica.

Il quadro normativo

Per i soggetti in perimetro NIS2 (tra cui gli operatori di comunicazioni elettroniche, e quindi molti WISP che usano RouterOS), la presenza in KEV di una vulnerabilità su un apparato di rete è un elemento oggettivo da considerare nell'analisi del rischio e nella gestione delle vulnerabilità richieste dall'art. 21. Se emergono indicatori di compromissione, valgono i termini di notifica al CSIRT Italia: pre-notifica entro 24 ore dalla conoscenza dell'incidente significativo e notifica entro 72 ore. Per le organizzazioni non NIS2 che trattano dati personali, resta la valutazione dell'art. 33 GDPR: un router compromesso da cui transita il traffico aziendale va valutato come possibile violazione.

Cosa fare subito

  • Confermare la versione: RouterOS 7.24.2, 7.23.4 o 6.49.21 come minimo; per la CVE-2026-67278, 7.24.3 o 7.23.6. Se siete alla versione minima, pianificate il salto successivo.
  • Cercare la persistenza anche sui router già aggiornati: utenti sconosciuti (in particolare ops), script e attività dello scheduler che non riconoscete, server proxy e tunnel non documentati.
  • Controllare nei log le voci con utente -2 e le connessioni dagli indirizzi 82.192.72.4 e 103.102.31.18, già indicati da CERT Polska.
  • Verificare il marcatore Flagged con /system/device-mode/print, sapendo che la sua assenza non prova l'integrità del dispositivo.
  • Ruotare i segreti che il router conosceva o custodiva: password di amministrazione, chiavi SSH, credenziali VPN, segreti condivisi.
  • Restringere SSH alle sole reti di gestione fidate, o disattivarlo sull'interfaccia pubblica se non serve.
  • Aggiornare il registro dei rischi con la coppia corretta di CVE (86060 e 67279) e con la data di inserimento in KEV.