La patch di BIND 9 corregge 14 difetti del server DNS, uno causa un crash DoH

L'Internet Systems Consortium (ISC), l'organizzazione che mantiene BIND 9, ha rilasciato BIND 9.20.29 e 9.21.26 per correggere quattordici difetti di sicurezza nel software server DNS open source, tutti divulgati il 16 settembre. Uno di essi riguarda qualsiasi server BIND 9 che risponde a DNS-over-HTTPS (DoH), un modo di trasportare le risoluzioni DNS, il sistema che trasforma un nome di dominio nell'indirizzo di un server, all'interno del normale traffico web cifrato. ISC afferma nei suoi avvisi che un mittente senza alcuna credenziale può mandare in crash il processo del server, named, con una singola richiesta che porta una firma SIG(0) non valida, a condizione che il mittente chiuda la connessione prima che named finisca di verificare quella firma. ISC aggiunge che non è a conoscenza di nessuno dei quattordici difetti sfruttato.

Quale aggiornamento corregge cosa dipende da quale ramo è in esecuzione. BIND 9.20.29, sul ramo stabile attuale, corregge tutti e quattordici. BIND 9.21.26, sul ramo di sviluppo, ne corregge tredici, perché CVE-2026-19662 non riguarda 9.21. La Supported Preview Edition per i clienti con supporto, 9.20.29-S1, corregge tutti e quattordici, corrispondendo agli intervalli -S1 elencati negli avvisi di ISC. ISC non elenca alcuna soluzione alternativa per nessuno dei quattordici, quindi applicare l'aggiornamento è l'unico rimedio che offre.

Le installazioni più vecchie si trovano in una posizione più difficile. Dodici dei quattordici riguardano il ramo 9.18, fino a includere 9.18.50, la sua versione finale. ISC ha terminato il supporto per 9.18 alla fine di giugno e non elenca alcuna versione 9.18 che li corregga. A maggio ha detto che gli utenti di 9.18 dovrebbero pianificare di passare a 9.20 il prima possibile, e la sua matrice delle vulnerabilità afferma che le versioni a fine vita dovrebbero essere considerate vulnerabili ai nuovi CVE, gli identificatori standard assegnati ai difetti di sicurezza catalogati pubblicamente. I pacchetti dei sistemi operativi sono una questione separata: Debian 12 fornisce un pacchetto basato su 9.18.49, e il suo security tracker non aveva elencato nessuno dei quattordici alle 06:20 UTC del 17 settembre.

Due dei quattordici possono essere attivati da una sola richiesta, senza che l'attaccante gestisca un proprio server DNS, ed entrambi riguardano solo i rami 9.20 e 9.21. Il crash DoH è CVE-2026-77692. Il secondo, CVE-2026-76163, consente a una query di tipo TKEY, un tipo di record usato dai name server per negoziare chiavi tra loro, di mandare in crash named quando il file di configurazione del server, named.conf, non ha un blocco di opzioni globali.

Per la maggior parte degli altri, l'attaccante ha bisogno di un resolver ricorsivo, il tipo di server che risolve i nomi per conto dei client, che riceva dati costruiti ad arte da un server controllato dall'attaccante. Una singola risposta costruita ad arte può mandare in crash un resolver con configurazione predefinita (CVE-2026-19667, una risposta negativa di esattamente 65.536 byte inviata da un server gestito dall'attaccante), un resolver che usa dns64 con break-dnssec yes (CVE-2026-19666, dove la risposta malformata viene servita dalla cache), o un resolver che convalida, cioè che controlla le firme crittografiche allegate ai dati DNS, che riceve una risposta wildcard che porta sia prove NSEC che NSEC3 sullo stesso nome (CVE-2026-80274, che può anche produrre un SERVFAIL o un record di negazione errato). Un quarto, CVE-2026-19662, richiede un ordine e una tempistica particolari delle risposte da una zona firmata gestita dall'attaccante e non riguarda 9.21.

Altri quattro dei quattordici consumano CPU o memoria di un resolver invece di mandarlo in crash. Due di essi funzionano tramite record alias SVCB o HTTPS in cache: con CVE-2026-81563 la cache cresce oltre il suo limite finché la risoluzione fallisce, dopo che un resolver segue ripetutamente un alias SVCB o HTTPS con più di tredici record di destinazione, e con CVE-2026-81736 un albero di alias in cache può esaurire il processore quando ai client è consentita la ricorsione e l'attaccante gestisce una zona. CVE-2026-19668 esaurisce la CPU di un resolver che convalida tramite una zona con molti tag di chiave e nessuna corrispondenza valida, e ISC nota che i limiti predefiniti sui record riducono l'esposizione. CVE-2026-75029 spinge l'uso di memoria oltre i limiti configurati quando una risposta ripete molte volte lo stesso record SOA, CNAME o DNAME. ISC classifica sette dei quattordici come High, tutti a 7.5 su CVSS 3.1, una scala di gravità standard dove 10 è il peggiore: i crash descritti sopra tranne CVE-2026-19662, più i due difetti SVCB e HTTPS. Gli altri sette sono Medium, da 5.3 a 6.5.

Gli altri quattro difetti riguardano l'integrità dei dati DNS, ciò che un server distribuisce o ciò che un resolver accetta, piuttosto che crash o esaurimento. ISC li classifica tutti e quattro come Medium, e ciascuno viene con condizioni su dove si trova l'attaccante o su cosa controlla già.

Due di essi consentono a un resolver che convalida di accettare la prova DNSSEC sbagliata. Con CVE-2026-19941, un record NSEC firmato da una zona non correlata può passare come prova che non esiste un wildcard. Un attaccante posizionato sul percorso di rete, o un forwarder malevolo, che controlla una zona firmata potrebbe usarlo per far accettare una risposta NXDOMAIN falsificata per un nome che dovrebbe risolversi tramite un wildcard, e la risposta falsificata supererebbe la convalida DNSSEC. Con CVE-2026-77119, un record NSEC3 firmato da una zona sorella non correlata può passare come prova che una delega non è firmata, e un attaccante in grado di iniettare risposte alle query del resolver potrebbe quindi far accettare una risposta non firmata falsificata per i nomi sotto quella delega. ISC descrive entrambi gli esiti come cache poisoning, cioè dati falsi conservati e riutilizzati da un resolver.

CVE-2026-19033 riguarda un server secondario, che copia una zona di record DNS da un server primario e accetta solo trasferimenti firmati con una chiave TSIG, un segreto condiviso usato per autenticare tali trasferimenti. Durante un trasferimento incrementale multi-messaggio (IXFR) su TCP, named poteva iniziare a servire i nuovi dati della zona prima che arrivasse il messaggio finale che portava la firma, e non tornava indietro se quella firma non arrivava mai. Una parte in grado di consegnare un tale trasferimento potrebbe far servire contenuti di zona non autorizzati senza possedere la chiave. La correzione richiede una TSIG su ogni messaggio di un trasferimento in entrata, e ISC dice che i name server moderni già firmano ogni messaggio, quindi non si aspetta cambiamenti in pratica.

CVE-2026-78301 richiede più accesso degli altri: un attaccante che può far caricare una zona malformata su un server autoritativo, per esempio tramite un trasferimento di zona. Una zona contenente un nodo NS o DNAME sopra la propria origine viene quindi trattata come un taglio di zona, così le query per nomi all'interno della zona restituiscono una delega fuori zona invece dei dati della zona stessa. Se il server fa anche ricorsione, può seguire quella delega e mettere in cache record forniti dall'attaccante per nomi al di fuori della zona, e l'effetto dura finché la zona malformata rimane caricata.

Ciascuno dei quattordici avvisi di ISC, pubblicati il 16 settembre, dice che l'organizzazione non è a conoscenza di alcuno sfruttamento attivo. Nessuno dei quattordici appare nel catalogo Known Exploited Vulnerabilities di CISA alla versione del catalogo rilasciata lo stesso giorno. CISA è la United States Cybersecurity and Infrastructure Security Agency. I test che riproducono i difetti sono però pubblici. ISC ha detto a maggio che ora rilascia test di riproduzione quando pubblica una vulnerabilità, e l'albero dei sorgenti 9.20.29 aggiunge test di sistema per almeno sei dei quattordici, incluso uno che invia una richiesta SIG(0) non valida su DoH, chiude la connessione e verifica che named sopravviva. Questi sono test che confermano la correzione piuttosto che strumenti di attacco, ma specificano le condizioni di attivazione.

Quattordici è il più grande dei cinque rilasci di sicurezza BIND di ISC quest'anno, dopo un difetto a gennaio, quattro a marzo, sei a maggio e nove a luglio. ISC ha avvertito a maggio che "gli utenti dovrebbero aspettarsi correzioni di sicurezza in ogni rilascio di manutenzione mensile di BIND" per il resto del 2026, un cambiamento che ha detto essere stato guidato da una valanga di segnalazioni di vulnerabilità generate da modelli linguistici di grandi dimensioni, sia da ricercatori che da attaccanti. Le correzioni arrivano in 9.20.29 invece che in 9.20.28 perché ISC ha ritirato 9.20.28 prima del rilascio dopo che i test pre-rilascio hanno trovato una regressione.

Quattro dei quattordici sono stati trovati nei test interni di ISC. Gli altri sono stati segnalati da Vitaly Simonovich (CVE-2026-77692), Rintaro Kawasugi (CVE-2026-19666 e CVE-2026-19667), Samy Medjahed, noto anche come Ap4sh (CVE-2026-19662 e CVE-2026-81563), Henrique Pereira (CVE-2026-78301 e CVE-2026-81736), Owais Lone, noto anche come thesecguy (CVE-2026-76163), un ricercatore accreditato come hythyt (CVE-2026-80274), e Zuyao Xu e Xiang Li della Nankai University (CVE-2026-19668).

Per i proprietari di siti web e i team IT, la lettura pratica è semplice: questo è software lato server, non qualcosa che un visitatore o un sistema di gestione dei contenuti attiva dall'esterno. Se la vostra organizzazione gestisce i propri name server, l'aggiornamento è tutta la storia, perché ISC non ha pubblicato alcuna soluzione alternativa. Se il vostro hosting o servizio DNS è gestito per voi, la domanda che vale la pena porre è se quel fornitore è già passato a 9.20.29 o 9.21.26 e cosa sta facendo per i server ancora sul ramo 9.18 non supportato, che ISC dice dovrebbe essere considerato vulnerabile a nuovi difetti. Un crash di un resolver non è di per sé un furto di dati, ma può mettere offline un nome di dominio per tutti coloro che cercano di raggiungerlo, e i quattro difetti di integrità mostrano che le risposte sbagliate conservate nella cache di un resolver sono il tipo di problema molto più difficile da notare di un'interruzione. I lettori che preferirebbero non gestire e correggere il proprio livello di risoluzione dei nomi possono guardare alle opzioni gestite: AEU DNS è un servizio DNS privato e sicuro, un modo per affidare la gestione delle risoluzioni a un fornitore invece di tenerla sui propri server. Ciò che conta in ogni caso è sapere chi è responsabile della patch e avere una risposta che si può verificare.