CVE-2026-81642 è una vulnerabilità critica nel validatore DNSSEC di Unbound che può causare heap buffer overflow durante l'elaborazione di un record DNSKEY malevolo. NLnet Labs l'ha resa pubblica il 16 settembre 2026 e indica come impatto denial of service e possibile esecuzione di codice remoto. Sono interessate le versioni fino alla 1.26.0 inclusa; la correzione è nella 1.26.1.

Il dettaglio che rende il problema interessante non è soltanto la severità. L'attaccante non deve necessariamente compromettere il resolver: secondo l'advisory del vendor può controllare una zona DNS malevola e indurre un Unbound vulnerabile a interrogarla.

Dove nasce il bug

DNSSEC usa i record DNSKEY per distribuire le chiavi pubbliche con cui il resolver verifica le firme della zona. Durante la validazione Unbound deve decodificare e trasformare i nomi DNS presenti nei record prima di calcolare i digest.

Nel caso descritto da NLnet Labs, un DNSKEY costruito con un owner compression pointer che punta al proprio RDATA può far sì che la decompressione produca dati oltre la capacità prevista dal buffer destinazione. La scrittura successiva supera il limite del buffer heap.

Questo punto è importante: non stiamo parlando di una firma DNSSEC debole o di una chiave compromessa. Il difetto è nella gestione della memoria mentre il resolver interpreta input DNS controllato dall'esterno.

Condizioni di attacco e impatto

L'advisory ufficiale indica tre elementi centrali:

  • il resolver esegue una versione di Unbound fino alla 1.26.0;
  • l'attaccante controlla una zona in grado di restituire il DNSKEY costruito ad hoc;
  • il resolver vulnerabile viene portato a effettuare una query verso quella zona.

L'overflow può terminare il processo e produrre un denial of service. NLnet Labs classifica inoltre come possibile la remote code execution perché parte dei dati coinvolti è controllata dall'attaccante. Questo non equivale a dire che ogni installazione vulnerabile sia sfruttabile in modo affidabile per ottenere RCE: allocator, build, mitigazioni del sistema operativo e layout della memoria incidono sull'esito. La classificazione corretta resta quella del vendor: critical, DoS e possible RCE.

Come verificare se il resolver è vulnerabile

La prima verifica è la versione installata:

unbound -V

Su un host gestito tramite package manager conviene verificare anche quale pacchetto sia effettivamente installato, perché il numero della distribuzione può includere backport di sicurezza:

# Debian / Ubuntu
dpkg-query -W unbound

# Fedora / RHEL
rpm -q unbound

Un numero inferiore a 1.26.1 non dimostra da solo che il pacchetto della distribuzione sia vulnerabile: alcuni maintainer applicano patch senza cambiare la versione upstream nello stesso modo. Va quindi controllato l'advisory della distribuzione o il changelog del pacchetto.

Per installazioni compilate dai sorgenti, unbound -V è invece un'indicazione diretta della release upstream usata.

Correzione nella 1.26.1

NLnet Labs ha corretto CVE-2026-81642 verificando la capacità del buffer interessato dopo la decompressione e prima della scrittura. La 1.26.1, pubblicata il 16 settembre 2026, contiene anche altre correzioni di sicurezza: aggiornare l'intera release è preferibile all'applicazione isolata di una singola patch quando l'ambiente lo consente.

Il percorso più semplice dipende da come Unbound è stato installato. Con un repository che ha già distribuito la versione corretta:

sudo apt update
sudo apt upgrade unbound
unbound -V

Dopo l'aggiornamento è utile validare la configurazione prima del riavvio:

sudo unbound-checkconf
sudo systemctl restart unbound
systemctl --no-pager --full status unbound

Chi mantiene una build sorgente può passare alla 1.26.1 oppure applicare una delle patch pubblicate da NLnet Labs. Il vendor mette a disposizione sia una patch minima sia una variante accompagnata da miglioramenti e test.

Cosa controllare dopo l'aggiornamento

Un resolver DNS è infrastruttura, quindi la patch non finisce con un systemctl restart. Conviene verificare che la risoluzione normale e la validazione DNSSEC continuino a funzionare e osservare i log per eventuali errori introdotti da configurazioni locali.

dig @127.0.0.1 example.org A
dig @127.0.0.1 example.org A +dnssec
journalctl -u unbound --since '10 minutes ago'

Il test non dimostra che CVE-2026-81642 sia stata corretta: serve a intercettare regressioni operative dopo l'aggiornamento. La verifica della vulnerabilità deve basarsi sulla release o sulla presenza della patch del vendor, non sull'invio di payload offensivi a un resolver di produzione.

Perché disabilitare DNSSEC non è una buona mitigazione

La vulnerabilità si trova nel percorso di validazione DNSSEC, ma spegnere la validazione come soluzione permanente elimina una proprietà di sicurezza del resolver per evitare un bug che dispone già di una patch. È una scelta peggiore dell'aggiornamento.

Se un sistema non può essere aggiornato immediatamente, la strada documentata da NLnet Labs è applicare la patch fornita per CVE-2026-81642. In ambienti gestiti da una distribuzione va seguito l'advisory del maintainer, soprattutto quando usa backport.

Risorse

La 1.26.1 risolve più problemi pubblicati nello stesso security release. Se gestisci resolver Unbound esposti a traffico non fidato, trattare l'aggiornamento come una normale patch di manutenzione rimanda inutilmente una correzione che il vendor classifica critica.