NLnet Labs ha rilasciato Unbound 1.26.1 correggendo nove vulnerabilità in un colpo solo. La più grave, CVE-2026-81642, è un heap buffer overflow nel validatore DNSSEC che l'organizzazione classifica come critica, con punteggio CVSS 4.0 pari a 9.1. Tutte le versioni fino alla 1.26.0 inclusa sono affette: nessuna esclusa, nessuna condizione di configurazione dichiarata.

Il difetto: un DNSKEY che punta a sé stesso

Il problema si manifesta mentre il validatore calcola il digest di un record DNSKEY. Se il nome del proprietario del record è un puntatore di compressione che rimanda ai dati del record stesso, il buffer del digest va in overflow. L'impatto dichiarato da NLnet Labs è il denial of service, con esecuzione di codice remoto possibile «attraverso dati controllati dall'attaccante».

Il prerequisito è semplice da soddisfare: serve controllare una zona ostile e fare in modo che il resolver la interroghi. Il vettore è di rete, non richiede privilegi né interazione dell'utente. Basta indurre il resolver a risolvere un nome sotto una zona che l'attaccante governa — cosa che, in un resolver ricorsivo aperto ai client interni, è alla portata di chiunque possa inviare una query, quindi di qualunque dispositivo della rete aziendale.

Due precisazioni sono doverose. Il 9.1 è il punteggio assegnato dal manutentore: al momento della divulgazione l'NVD riportava il CVE come «Awaiting Analysis», e la voce CISA per CVE-2026-81642 indicava sfruttamento «none». Non risultano quindi attacchi in corso. E la correzione critica rilasciata a maggio, CVE-2026-33278, riguardava un difetto diverso: chi si è aggiornato alla 1.25.1 allora non è protetto adesso.

Fra le altre otto falle merita una riga CVE-2026-82717, corruzione di heap nella sintesi dei CNAME, classificata High e anch'essa potenzialmente sfruttabile per esecuzione di codice «su certi sistemi e con certe opzioni di compilazione». È stata segnalata da Ben Morris di Anthropic. Le restanti sei vanno da Medium a Low e portano a denial of service o degrado del servizio, con condizioni più specifiche: alcune richiedono build con --with-libngtcp2 e porta QUIC configurata, altre --with-libnghttp2 con https-port, un'altra l'uso di zonemd-check: yes su zone sotto — ma non coincidenti con — un trust anchor.

Da segnalare un cambio di comportamento predefinito introdotto dalla correzione degli attacchi di complessità algoritmica ReTrap: val-clean-additional ora è disattivato, quindi Unbound non valida più per impostazione predefinita i dati DNSSEC nella sezione additional delle risposte. Chi ha politiche di validazione stringenti dovrebbe verificarlo prima di considerare l'aggiornamento indolore.

Cosa significa per le aziende italiane

Unbound non è un prodotto che si compra: è un componente che ci si ritrova. Gira dentro pfSense e OPNsense, che nelle PMI italiane sono la scelta standard quando il firewall commerciale non rientra nel budget. Gira sui resolver ricorsivi di molti provider e data center regionali. Gira nelle appliance di rete e negli apparati di fornitori che non lo menzionano nella scheda prodotto. La conseguenza pratica è che l'esposizione reale di un'azienda a questo CVE è quasi sempre maggiore di quanto risulti dall'inventario software, perché Unbound arriva incorporato.

Il secondo punto riguarda la posizione del resolver nell'architettura. Un resolver DNS interno è un sistema che, per definizione, parla con tutta la rete e risolve verso tutta Internet. Chi ottiene esecuzione di codice lì si trova in una posizione privilegiata: può osservare ogni risoluzione — cioè ricostruire la mappa dei servizi usati dall'azienda — e può manipolare le risposte, dirottando client verso infrastrutture controllate. È il tipo di compromissione che non genera allarmi evidenti e che sopravvive a lungo. Vale la pena ricordare che il resolver, di solito, non è coperto dalle stesse attenzioni riservate ai server applicativi: raramente ha EDR, spesso non è nel perimetro di scansione delle vulnerabilità, quasi mai è oggetto di revisione delle configurazioni.

Il terzo punto è la distribuzione. Il security tracker di Debian, il giorno dopo il rilascio, elencava unbound 1.26.1-1 come corretto solo in unstable, con i rami bookworm, trixie e forky ancora vulnerabili. Chi aspetta l'aggiornamento dal repository della propria distribuzione aspetterà, e per pfSense e OPNsense la tempistica dipende dai rispettivi rilasci. Questo è esattamente lo scenario in cui la patch del manutentore esiste ma non è ancora arrivata al parco installato, e la finestra va gestita in modo esplicito invece di essere subita.

Sul piano normativo, per i soggetti NIS2 italiani il resolver DNS rientra a pieno titolo fra i sistemi critici la cui gestione delle vulnerabilità l'articolo 21 richiede di presidiare: il punto non è avere applicato la patch il primo giorno, ma poter dimostrare di aver saputo dell'avviso, di aver valutato l'esposizione e di aver deciso con un criterio. Chi fornisce servizi DNS ricorsivi a terzi — provider, data center, gestori di reti per la pubblica amministrazione — ha inoltre un profilo di rischio amplificato: una compromissione del resolver è un incidente che si propaga a valle su tutti i clienti serviti, con le conseguenti valutazioni sulla significatività e sui termini di notifica al CSIRT Italia (24 ore per la pre-notifica, 72 per la notifica).

Cosa fare subito

  • Aggiornare a Unbound 1.26.1, disponibile come sorgente con checksum e firma PGP e come installer e binari per Windows.
  • Se l'aggiornamento completo non è praticabile, applicare le patch fornite da NLnet Labs: esistono una patch minimale e una completa per la sola CVE-2026-81642, e una patch combinata per tutte e nove le correzioni. Il manutentore dichiara che le patch autonome per CVE-2026-81642 e CVE-2026-82717 sono state testate sulla 1.26.0.
  • Censire dove gira Unbound, non dove è stato installato: firewall pfSense e OPNsense, appliance di rete, container, immagini di sistema, apparati forniti da terzi. È la parte più lunga del lavoro ed è quella che determina se la patch serve a qualcosa.
  • Verificare se la propria distribuzione ha già rilasciato il pacchetto corretto sul ramo in uso. Se non l'ha fatto, decidere fra compilazione dalle patch e attesa documentata, senza lasciare la scelta implicita.
  • Limitare chi può interrogare il resolver: un ricorsivo raggiungibile solo dalle reti interne riduce la platea di chi può innescare la risoluzione verso una zona ostile. Un ricorsivo aperto su Internet è, in questo scenario come in molti altri, un problema a sé.
  • Verificare l'impatto del nuovo valore predefinito di val-clean-additional sulle proprie politiche di validazione prima di promuovere l'aggiornamento in produzione.
  • Riesaminare il monitoraggio del resolver: crash, riavvii inattesi del processo, picchi di memoria. L'impatto primario dichiarato è il denial of service, e i sintomi di un tentativo si vedono lì prima che altrove.

Non c'è sfruttamento noto e non c'è ragione di trattare questo avviso come un'emergenza. C'è ottima ragione, invece, per trattarlo come il promemoria che il DNS resta l'infrastruttura più critica e meno curata di una rete aziendale: quando si scopre che il componente che la regge sta anche dentro il firewall, l'inventario diventa la vera attività di sicurezza.