MikroTik CVE-2026-14227: la tua chiave privata WireGuard è leggibile, e disattivare l'API non lo annulla

Il 30 luglio 2026 la CISA ha pubblicato l'avviso ICSA-26-211-01 relativo alla CVE-2026-14227, un difetto nella gestione delle sessioni dell'API di MikroTik RouterOS. La conseguenza riportata è abbastanza precisa da riguardare chiunque ospiti un tunnel in proprio: la chiave privata WireGuard del router può essere letta in chiaro da una sessione API che non dovrebbe avere quel livello di accesso.

Gran parte della copertura si è fermata al titolo. Ciò che decide cosa devi fare sta più in basso.

In che cosa consiste il difetto

Il servizio API di RouterOS ascolta sulla porta TCP 8728 in chiaro e sulla 8729 via TLS. La vulnerabilità è classificata come scadenza insufficiente delle sessioni: le sessioni attive mantengono i permessi che avevano all'apertura, quindi ridurre i diritti di un utente o lasciare scadere una sessione non ha necessariamente effetto su una connessione già stabilita.

Ne risulta un disallineamento di privilegi. Una sessione che avrebbe dovuto essere declassata continua a leggere configurazione che non dovrebbe più vedere e, su un router che termina un tunnel WireGuard, quella configurazione contiene la chiave privata statica.

Perché il punteggio inganna

La gravità pubblicata è moderata: CVSS 4.0 base 6,9 e CVSS 3.1 base 4,9 secondo la scheda Rapid7. Diverse testate l'hanno chiamata critica. Non è ciò che dice il punteggio, e ripetere l'aggettivo più rumoroso non ti aiuterebbe.

Ma leggere il numero come se fosse tutta la storia è l'errore opposto. Un punteggio CVSS misura quanto è difficile sfruttare qualcosa e fin dove arriva. Non misura quanto è permanente la conseguenza. Un difetto valutato medio che espone un token di sessione rotante è un pomeriggio storto. Un difetto valutato medio che espone un'identità crittografica statica appartiene a un'altra categoria di problema, perché l'esposizione non invecchia.

La parte che si salta: la chiave non scade

Questo è il cuore pratico. In WireGuard ogni peer possiede una coppia di chiavi statica, ed è a quell'identità che l'altro lato dà fiducia. Una password si cambia, un token scade, una sessione muore. Una chiave privata depositata nella configurazione di un router non fa nulla di tutto ciò da sola.

Così la sequenza che seguono in molti, disattivare l'API e considerarla risolta, chiude la porta senza cambiare la serratura. Se la chiave era leggibile mentre l'API era esposta, disattivare l'API dopo non la de-trapela. La rotazione è il passo che ripristina davvero il rapporto di fiducia, ed è quello che si rimanda più spesso perché obbliga a toccare ogni peer.

Che cosa copre e che cosa non copre la forward secrecy

Vale la pena essere precisi, perché la formula decifratura di tutto il traffico associato è stata ripetuta ovunque ed è facile leggerla come peggiore di quanto sia.

L'handshake di WireGuard deriva chiavi di sessione effimere, ed è ciò che dà al protocollo la forward secrecy. Un attaccante che possiede la tua chiave privata statica, e nient'altro, non può decifrare retroattivamente il traffico catturato in precedenza. Quella proprietà resta intatta.

Ciò che la chiave statica gli dà è identità. Può presentarsi come quel peer, completare handshake e intercettare attivamente nuove sessioni. In pratica significa impersonificazione e intercettazione attiva d'ora in avanti, non un archivio leggibile del passato. Serio, ma è una minaccia diversa, e la distinzione cambia la tua risposta: non stai valutando danni su traffico vecchio, stai revocando un'identità.

Che cosa fare, nell'ordine

Stabilisci se l'API fosse anche solo raggiungibile. Se il servizio era disattivato, o legato solo a un'interfaccia che un attaccante non avrebbe mai potuto toccare, la tua esposizione è teorica. Verifica prima di allarmarti e prima di ricostruire qualsiasi cosa.

Disattiva il servizio API se non ti serve. È l'aggiramento indicato dall'avviso e, in un'installazione domestica o con un solo amministratore, l'API è spesso attiva senza essere mai usata.

Disconnetti gli utenti quando ne riduci i diritti. L'indicazione di MikroTik è che un utente con permessi ridotti debba essere disconnesso completamente perché la nuova politica si applichi. Merita di entrare nella tua procedura, non di essere fatto una volta sola, perché è esattamente il comportamento che il difetto sfrutta.

Ruota le chiavi se l'esposizione era plausibile. Genera una nuova coppia sul router, aggiorna ogni peer con la nuova chiave pubblica ed elimina quella vecchia. È il passo noioso ed è l'unico che chiude l'esposizione invece di metterla in pausa.

Non fidarti di un intervallo di versioni letto di seconda mano. La stampa dice che tutte le versioni con l'API attiva sono interessate; la scheda Rapid7 non indica alcun intervallo. Controlla il tuo dispositivo invece di ritenerti al sicuro perché un numero letto in un articolo non coincideva con il tuo.

Il punto più ampio per chi ospita in proprio

Far girare il proprio tunnel significa che la chiave vive su hardware che controlli, il che è esattamente l'attrattiva ed esattamente l'esposizione. La sicurezza di un VPN self-hosted è quella della macchina su cui gira, comprese le interfacce di amministrazione che avevi dimenticato fossero in ascolto.

Non è un argomento contro il self-hosting, è un argomento per trattare il piano di amministrazione come parte del VPN. Se stai verificando la tua installazione, la nostra guida alla risoluzione dei problemi di handshake WireGuard spiega come leggere lo stato dei peer, e il glossario del VPN self-hosted definisce i termini usati sopra.

In breve

La CVE-2026-14227 è valutata media ed espone qualcosa che non scade. Verifica se la tua API fosse raggiungibile, disattivala se non la usi, disconnetti gli utenti quando cambiano i loro diritti e ruota la chiave se l'esposizione era plausibile. La forward secrecy protegge il tuo traffico passato; nulla protegge un'identità che lasci al suo posto dopo che è stata letta.