Il progetto OpenWrt ha rilasciato le versioni 24.10.8 e 25.12.5 per chiudere una vulnerabilità critica in odhcpd, il demone che sui dispositivi OpenWrt gestisce DHCPv6, i router advertisement e il proxy NDP. La falla, identificata come CVE-2026-53921 e valutata 9.8 su scala CVSS 3.1, permette a un attaccante non autenticato di sovrascrivere un buffer sullo stack inviando un singolo pacchetto UDP verso la porta 547.

I fatti tecnici

L'advisory pubblicato sul repository GitHub del progetto (GHSA-7fwx-hhrg-3496) descrive due punti di overflow indipendenti, entrambi raggiungibili dalla rete nella stessa catena di chiamate, entrambi nel file dhcpv6-ia.c.

Il primo si trova nella funzione build_ia(). Quando una richiesta di indirizzo entra nel percorso di errore, il codice verifica che nel buffer di risposta ci siano almeno 16 byte liberi, ma poi ne scrive 22, perché aggiunge una sotto-opzione di stato da 6 byte senza ricontrollare lo spazio residuo. Con una REQUEST costruita ad arte (cinque assegnazioni valide seguite da sette richieste destinate a fallire) il buffer da 512 byte si riempie fino a lasciare solo 20 byte, e la scrittura successiva esce dai margini.

Il secondo riguarda la gestione dell'opzione RECONF_ACCEPT: 36 byte complessivi, quattro di opzione e trentadue di record di autenticazione, vengono scritti senza alcun controllo preventivo sullo spazio disponibile. La sottrazione senza segno che aggiorna la lunghezza residua va in underflow, corrompendo anche tutta la contabilità successiva delle dimensioni.

Il dettaglio che sposta il giudizio da "grave" a "critico" sta nell'ambiente di esecuzione. odhcpd gira come root, e i target embedded su cui OpenWrt viene installato spesso non dispongono di stack canary né di ASLR. In quelle condizioni un overflow controllato sullo stack non si esaurisce nel crash del servizio: diventa una strada realistica verso l'esecuzione di codice con i privilegi massimi sul dispositivo. L'advisory include proof of concept in Python funzionanti per entrambi i percorsi, il che accorcia parecchio la distanza fra pubblicazione e sfruttamento.

Nella stessa finestra sono state pubblicate altre falle in odhcpd. La più rilevante è CVE-2026-62948 (CVSS 9.6), corretta in 25.12.5: un client DHCPv6 non autenticato può iniettare caratteri di a capo attraverso l'opzione FQDN 39, forgiando righe fasulle nel file /tmp/odhcpd.leases e facendo renderizzare HTML arbitrario nella pagina "Active DHCPv6 Leases" dell'interfaccia LuCI. Da sola non porta a root, ma falsifica esattamente ciò che l'amministratore guarda per capire chi c'è in rete.

Cosa significa per le aziende italiane

Va detto subito qual è il confine reale del rischio, perché il numero 9.8 da solo fa più rumore di quanto meriti in molti scenari: per sfruttare la falla bisogna poter parlare con il server DHCPv6 del dispositivo, quindi trovarsi sulla rete locale o su un segmento adiacente. Non è una vulnerabilità che espone il router alla scansione di massa da Internet.

Questo però non la rende teorica, e anzi in Italia tocca una configurazione molto comune. OpenWrt non è solo il firmware degli appassionati: è la base di numerosi apparati commerciali usati nelle PMI, nei router industriali per la connettività di stabilimento, nei gateway 4G/5G delle sedi remote e nei CPE forniti da integratori. Molte di queste installazioni vivono in armadi di rete di cui nessuno tiene un inventario aggiornato, ricevono aggiornamenti solo quando smettono di funzionare e restano in servizio per otto o dieci anni.

Il vero scenario da considerare non è quindi l'attacco iniziale, ma la seconda fase: un dispositivo IoT compromesso, un portatile di un fornitore collegato in sala riunioni, un ospite sulla Wi-Fi non segmentata. In tutti questi casi l'attaccante è già dentro il broadcast domain e con un pacchetto ottiene root sul router. E il router è la peggiore posizione da cedere: da lì si riscrive il DNS, si intercetta e si reindirizza il traffico, si osservano le sessioni VPN, si mantiene una persistenza che nessun EDR sugli endpoint vedrà mai perché su quel dispositivo l'EDR non c'è.

Sul piano normativo, per i soggetti che ricadono nel perimetro NIS2 questa è materia da articolo 21: la gestione delle vulnerabilità e degli aggiornamenti e la sicurezza delle reti sono misure minime esplicite, e "non sapevamo quanti router avessimo" non è una posizione difendibile davanti a un'autorità di vigilanza. Se poi la compromissione del gateway porta a intercettazione di traffico contenente dati personali, si apre anche il capitolo notifica al Garante entro 72 ore. Per chi invece produce o rivende apparati basati su OpenWrt, il Cyber Resilience Act sposta l'onere della gestione delle vulnerabilità sul fabbricante, e una falla di questo tipo nel componente di rete è precisamente ciò che l'obbligo di supporto vuole intercettare.

Cosa fare subito

  • Aggiornare: chi è sul ramo 24.10 deve installare la 24.10.8, chi è sul ramo 25.12 la 25.12.5. Sono release di sicurezza, non feature release.
  • Verificare il firmware degli apparati OEM: molti router commerciali sono basati su OpenWrt ma seguono il ciclo di rilascio del produttore, che può essere in ritardo di mesi. Aprire un ticket al vendor chiedendo esplicitamente la versione di odhcpd inclusa.
  • Disattivare DHCPv6 dove non serve: se l'IPv6 non è in uso, impostare il server DHCPv6 su "disabled" nell'interfaccia interessata riduce la superficie a zero per questa specifica catena.
  • Limitare l'esposizione dell'interfaccia LuCI: nessun pannello di amministrazione raggiungibile dalla VLAN utenti o dalla rete ospiti, e nessuno raggiungibile da Internet.
  • Segmentare le reti ospiti e IoT: è la mitigazione che vale su tutta la classe di attacchi di prossimità, non solo su questa CVE.
  • Costruire l'inventario: se non esiste un elenco dei dispositivi di rete con modello, firmware e data dell'ultimo aggiornamento, nessuna patch policy può funzionare. È il punto da cui partire, prima ancora di questa vulnerabilità.