OpenWrt, un buffer overflow degli anni '90 apre i router al…

Una vulnerabilità critica nel server DHCPv6 di OpenWrt permette RCE pre-autenticazione sui router. Il PoC è pubblico e l'hardware embedded manca di protezioni base.

Il 28 luglio 2026 OpenWrt ha reso pubblica una vulnerabilità critica nel proprio server DHCPv6 che permette a un attaccante di rete non autenticato di ottenere esecuzione di codice come root. Il difetto, tracciato come CVE-2026-53921 con punteggio CVSS 9.8 secondo l'advisory GitHub del progetto, sfrutta un classico stack buffer overflow nella serializzazione delle risposte IA di DHCPv6. La combinazione di un exploit di rete pre-autenticazione, un proof-of-concept Python già disponibile e l'assenza di mitigazioni moderne su hardware embedded rende la minaccia immediatamente concreta per router e dispositivi SOHO.

Punti chiave

CVE-2026-53921 è una stack buffer overflow nel server DHCPv6 odhcpd di OpenWrt con CVSS 9.8 (Critical) secondo l'advisory GitHub del progetto.
L'attaccante invia un pacchetto DHCPv6 REQUEST craftato a UDP port 547; due percorsi di overflow indipendenti sovrascrivono un buffer stack fisso di 512 byte.
L'advisory include codice PoC Python pubblico per entrambi i percorsi di exploit documentati.
L'hardware embedded tipicamente manca di stack canaries e ASLR, rendendo l'esecuzione di codice come root una conseguenza realistica secondo la stessa fonte del progetto.

Il meccanismo: come un pacchetto DHCPv6 diventa esecuzione arbitraria

Le funzioni vulnerabili sono dhcpv6_ia_handle_IAs() e build_ia(), entrambe nel percorso di processing delle richieste DHCPv6 di odhcpd. Secondo l'advisory citato, il server utilizza un buffer stack fisso di 512 byte per serializzare le risposte IA (Identity Association). Quando processa opzioni IA craftate in un pacchetto REQUEST, il codice appende dati di risposta senza sufficienti controlli sui limiti, sovrascrivendo il buffer.

Esistono due percorsi di trigger indipendenti. Il primo richiede cinque IA_NA bindings preceduti da un messaggio SOLICIT; il secondo si attiva con un singolo REQUEST opportunamente costruito. In entrambi i casi, l'attaccante non ha bisogno di autenticazione: il pacchetto finale è un DHCPv6 REQUEST standard inviato a UDP port 547.

Il server odhcpd gira con privilegi di root. Una volta sovrascritto il buffer, il flusso di esecuzione può essere rediretto verso shellcode injected dal pacchetto. L'advisory del progetto riporta esplicitamente che "embedded hardware commonly lacks stack canaries and address space layout randomization (ASLR), making code execution a realistic outcome on typical devices".

"embedded hardware commonly lacks stack canaries and address space layout randomization (ASLR), making code execution a realistic outcome on typical devices" — OpenWrt GitHub advisory, riportato da The Hacker News

Perché il PoC pubblico cambia la linea temporale del rischio

L'advisory include codice PoC Python pubblico per entrambi i percorsi di overflow documentati. Questo elemento trasforma CVE-2026-53921 da vulnerabilità teorica a arma immediatamente replicabile: non serve reverse engineering del firmware né competenze di exploit development avanzate per costruire un attacco funzionante.

La pubblicazione del codice exploit è una scelta deliberata del progetto OpenWrt, probabilmente finalizzata a forzare l'aggiornamento dato che il fix esiste già da settimane. Le release notes della versione 25.12.5, datate 1 luglio 2026, elencano già CVE-2026-53921 come "Critical: stack buffer overflow in the DHCPv6 IA reply serialization, triggerable with crafted DHCPv6 REQUEST". Il gap di quasi quattro settimane tra release del patch e divulgazione pubblica completa suggerisce un embargo responsabile, ma espone ora i dispositivi non aggiornati.

Al 28 luglio 2026 non emergono segnalazioni di exploit in-the-wild nel CISA KEV catalog versione 2026.07.27. L'assenza da questo catalogo non costituisce tuttavia prova di non sfruttamento: il KEV è retrospettivo per definizione e i dispositivi IoT/embedded raramente dispongono di telemetria di rilevamento.

Il "perfect storm" del firmware embedded: quando le mitigazioni mancano

Il nucleo della gravità non sta solo nella vulnerabilità stessa, ma nell'ecosistema che la circonda. I router consumer e i dispositivi SOHO che eseguono OpenWrt sono costruiti su piattaforme MIPS e ARM a basso costo dove le mitigazioni moderne sono spesso disabilitate per ragioni di prestazioni o semplicemente non implementate dal bootloader.

Stack canaries richiedono supporto del compilatore e del runtime; ASLR richiede un MMU funzionale e un kernel che randomizzi lo spazio degli indirizzi. Su molti SoC embedded, queste condizioni non esistono. Il risultato è che un buffer overflow degli anni '90—un attacco che su sistemi general-purpose moderni sarebbe intercettato o reso impraticabile—resta letale nel 2026.

Il servizio DHCPv6 server è inoltre abilitato di default su molte configurazioni OpenWrt che forniscono IPv6 sulla LAN o ricevono prefissi delegati dall'ISP. Questo espone la superficie di attacco non solo alla rete locale ma potenzialmente a segmenti upstream in scenari di provider, se il firewall non filtra adeguatamente UDP 547 sulla WAN.

Percorso di aggiornamento e fine vita del branch 24.10

Il fix è disponibile nel commit e432dd6 del branch master di odhcpd. Per gli utenti stabili, le versioni patchate sono la 24.10.8 per il branch 24.10 e la 25.12.5 per il branch 25.12, quest'ultima rilasciata il 1 luglio 2026.

Il branch 24.10 è in manutenzione di sicurezza con fine vita prevista per settembre 2026. Gli utenti che rimangono su questa versione affrontano una doppia pressione: la vulnerabilità attiva e l'imminente cessazione del supporto. La fonte non specifica se il fix del 25.12.5 sia stato backportato correttamente nella 24.10.8 o se quest'ultima contenga regressioni non ancora documentate.

Perché è importante

Il brief non specifica misure correttive o controlli operativi da attivare oltre all'aggiornamento del firmware. Non emerge dalla fonte alcuna raccomandazione su monitoraggio specifico di UDP 547, segmentazione di rete o verifica della configurazione DHCPv6. Il dossier non quantifica il numero di dispositivi effettivamente esposti con il server abilitato su interfaccia WAN anziché solo LAN.

Resta inoltre incerto se la variante RECONF_ACCEPT menzionata nell'advisory faccia parte di CVE-2026-53921 o costituisca una vulnerabilità separata senza identificatore assegnato. La fonte non chiarisce questo mapping, né documenta se esistano condizioni di attacco con vettore di accesso adjacente (AV:A) oltre a quello di rete (AV:N) già citate.

La natura del rischio—infrastruttura di rete critica con patch esistente ma distribuzione frammentata, combinata con PoC pubblico e assenza di mitigazioni hardware—crea condizioni tecniche per un compromesso sistemico. La velocità di adozione dell'aggiornamento 24.10.8 nei prossimi giorni sarà il parametro determinante per contenere o meno un potenziale evento di massa.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti