La risposta in breve
ISC ha corretto 14 vulnerabilità in BIND 9 e una di esse consente a chiunque su Internet di mandare in crash il vostro server DNS con una singola richiesta. CVE-2026-77692 (CVSS 7.5) abusa di DNS-over-HTTPS: una richiesta artefatta con un record SIG(0) non valido, seguita da una chiusura prematura della connessione, innesca una dereferenziazione di puntatore NULL e interrompe il processo named. Nessuna autenticazione, nessuna credenziale valida, nessun accesso preliminare — solo un pacchetto malformato. Se il DNS cade, cade tutto ciò che risolve attraverso di esso, ed è per questo che va in cima alla vostra coda di patch cloud e DevOps questa settimana.
La correzione è semplice — l'aggiornamento a BIND 9.20.29 o 9.21.26 — ma la lezione è più ampia. Il DNS autoritativo e ricorsivo è infrastruttura critica che molti team trattano come « imposta e dimentica ». Questa release ricorda di applicare le patch con la stessa cadenza dello stack applicativo, di monitorarlo per i crash e di assicurarsi che una singola richiesta di frontiera non possa abbattere un servizio da cui dipende l'intera azienda.
Cosa ha corretto ISC — e la falla da tenere d'occhio
Il 16 settembre l'Internet Systems Consortium — l'organizzazione no-profit che mantiene BIND, il software server DNS più diffuso su Internet — ha rilasciato BIND 9.20.29 e 9.21.26, chiudendo 14 falle di sicurezza in un colpo solo. Sette sono ad alta gravità e sette a media. Il gruppo ad alta gravità può essere sfruttato da remoto per innescare crash del programma, esaurimento della memoria o esaurimento delle risorse, mentre i problemi a media gravità includono cache poisoning, esaurimento della CPU e iniezione di dati arbitrari nelle zone DNS.
La più significativa è CVE-2026-77692, valutata CVSS 7.5. Consente a un aggressore remoto non autenticato di terminare il demone named inviando una singola richiesta DNS-over-HTTPS (DoH) che trasporta un record SIG(0) crittograficamente non valido, per poi chiudere bruscamente la connessione di trasporto prima che la validazione sia completata. Il risultato è una dereferenziazione di puntatore NULL che interrompe il processo — un denial of service netto senza login, senza sessione e senza firma valida. Per i resolver esposti a Internet è quasi il peggior rapporto sforzo/impatto possibile.
ISC afferma di non essere a conoscenza di alcuna delle 14 vulnerabilità sfruttata in-the-wild. È rassicurante ma limitato nel tempo: il consorzio nota anche che i test che riproducono le falle sono pubblici, cosa che abbassa nettamente il lavoro necessario per trasformarle in arma. Quando un percorso di proof-of-concept è già documentato, « non ancora sfruttata » è un dettaglio di pianificazione, non un motivo per rinviare. Chiunque gestisca BIND dovrebbe trattarla come un intervento della stessa settimana e inserirla in una disciplinata routine di sicurezza e patch.
Perché DNS-over-HTTPS ha ampliato la superficie d'attacco
DNS-over-HTTPS è stato progettato per migliorare la privacy avvolgendo le query DNS in traffico HTTPS cifrato, e la sua adozione tra i resolver aziendali e i provider DNS pubblici è cresciuta costantemente. Ma ogni nuovo trasporto che un server parla è codice nuovo che analizza input non attendibili, e CVE-2026-77692 risiede proprio in quella giuntura: la gestione delle firme di transazione SIG(0) sul trasporto DoH. La falla non è nella logica di risoluzione DNS in sé, ma in come il server gestisce una connessione interrotta a metà validazione.
Questo schema — un crash innescato da input malformato più una disconnessione prematura — è una classe di bug ricorrente nei demoni di rete, ed è esattamente il motivo per cui l'analisi degli input sui servizi esposti a frontiera merita un'attenzione supplementare. Se i vostri resolver espongono DoH, sono raggiungibili tramite le porte HTTPS ordinarie che i firewall di solito lasciano aperte; il modello mentale del « servizio interno » quindi non vi protegge. In pratica, sappiate quali trasporti parla realmente ogni endpoint DNS e trattate ciascuno come una superficie d'attacco da patchare e monitorare.
Rafforza anche un principio di progettazione per qualsiasi servizio che termina connessioni non attendibili: presumete che i client si comportino male, si disconnettano in anticipo e inviino dati non validi di proposito. Una gestione robusta del ciclo di vita delle connessioni — e la supervisione con riavvio in caso di crash come rete di sicurezza — non è un lusso; è la differenza tra un errore registrato a log e un disservizio a livello aziendale.
Cosa significa per i team in Italia
La prima implicazione è un problema di raggio d'impatto. Il DNS è una dipendenza di quasi tutto: service discovery, chiamate API, posta elettronica, validazione dei certificati e traffico verso i clienti presuppongono tutti che la risoluzione funzioni. Un crash di named non manda in errore una singola funzionalità; può propagarsi in timeout su un'intera piattaforma. Per i team di FinTech, HealthTech o e-commerce, dove la disponibilità è contrattuale e il downtime si misura in ricavi ed esposizione normativa, un DoS DNS non autenticato è una questione di continuità operativa, non un semplice ticket ops.
In Italia si aggiunge una dimensione regolatoria: l'Agenzia per la Cybersicurezza Nazionale (ACN) e il suo CSIRT Italia pubblicano propri bollettini di allerta per avvisi di questo tipo su BIND, e i soggetti inclusi nel Perimetro di Sicurezza Nazionale Cibernetica o rientranti nel recepimento della NIS 2 devono garantire disponibilità e tracciabilità dei servizi DNS. Se gestite resolver in un perimetro di questo tipo, questa patch non va solo applicata tecnicamente: documentate la data di correzione, i sistemi interessati e le misure compensative, perché sono proprio gli elementi attesi in caso di verifica o di notifica di incidente.
La seconda implicazione riguarda la responsabilità. Molte organizzazioni non sanno chi applica le patch al proprio DNS. Può essere un provider gestito, un team di piattaforma, un appliance o un'immagine di container che nessuno ricostruisce da mesi. Questa release è un buon fattore di spinta per rispondere a una domanda semplice: per ogni resolver DNS e server autoritativo da cui dipendiamo, chi è responsabile dell'applicazione di BIND 9.20.29 o 9.21.26, ed entro quando? Una responsabilità poco chiara è il modo in cui una falla documentata e correggibile sopravvive per mesi.
La terza implicazione è la resilienza per impostazione predefinita. Anche dopo la patch, il prossimo bug DNS prima o poi arriverà. I team che eseguono named sotto un supervisore di processo, distribuiscono la risoluzione su istanze ridondanti, applicano rate limiting agli endpoint DoH e generano alert sui riavvii ripetuti assorbiranno la prossima falla di tipo crash con un sussulto anziché un disservizio. È la postura che integriamo in ogni piattaforma di software su misura: i servizi critici sono supervisionati, ridondanti e osservabili, così un singolo guasto degrada in modo controllato invece di abbattere il sistema.
Cosa fare ora
- Inventariate il vostro parco BIND. Individuate ogni server ricorsivo e autoritativo, inclusi appliance e immagini di container. Non si può patchare ciò che non si è localizzato.
- Aggiornate alla release corretta. Passate a BIND 9.20.29 o 9.21.26 (oppure 9.20.29-S1 per la Supported Preview Edition) sul ramo che utilizzate. Verificate la versione in esecuzione dopo il deployment, non solo quella del pacchetto.
- Riducete l'esposizione DoH. Limitate quali client possono raggiungere gli endpoint DNS-over-HTTPS e ponete i resolver dietro rate limiting e controlli di rete, così che un flusso di richieste artefatte non possa mandare in crash il servizio ripetutamente.
- Supervisionate e monitorate
named. Eseguitelo sotto systemd o un equivalente che lo riavvia automaticamente e generate alert sui crash ripetuti anziché scoprirli da una segnalazione dei clienti. - Assegnate una responsabilità chiara. Nominate il team responsabile delle patch DNS e inserite BIND nella stessa cadenza di revisione delle vostre dipendenze applicative, così che il prossimo avviso sia routine e non un'emergenza.
Domande frequenti
Che cosa ha corretto ISC in BIND 9 il 16 settembre 2026?
ISC ha rilasciato BIND 9.20.29 e 9.21.26 per correggere 14 vulnerabilità — sette ad alta gravità e sette a media. I problemi ad alta gravità possono provocare crash da remoto, esaurimento della memoria o esaurimento delle risorse; quelli a media includono cache poisoning, esaurimento della CPU e iniezione di dati arbitrari nelle zone DNS.
Che cos'è la CVE-2026-77692?
È una falla ad alta gravità (CVSS 7.5) che consente a un aggressore remoto non autenticato di mandare in crash il servizio named con una singola richiesta DNS-over-HTTPS. L'aggressore invia una richiesta DoH artefatta con un record SIG(0) crittograficamente non valido e chiude la connessione in anticipo, innescando una dereferenziazione di puntatore NULL e un denial of service.
Quali versioni di BIND 9 sono interessate e corrette?
CVE-2026-77692 interessa BIND 9.20.0 fino a 9.20.27, 9.21.0 fino a 9.21.25 e la Supported Preview Edition 9.20.9-S1 fino a 9.20.27-S1. Le correzioni sono incluse in BIND 9.20.29, 9.21.26 e 9.20.29-S1. Aggiornate alla release corretta del ramo che utilizzate.
La CVE-2026-77692 è sfruttata in-the-wild?
ISC ha dichiarato di non essere a conoscenza di alcuna delle 14 vulnerabilità sfruttata in-the-wild. Ha però osservato che i test che riproducono le falle sono pubblici, cosa che riduce lo sforzo necessario per trasformarle in arma; gli operatori dovrebbero quindi applicare le patch tempestivamente anziché attendere.
Cosa fare se non possiamo applicare subito la patch a BIND?
Riducete l'esposizione mentre pianificate l'aggiornamento: limitate chi può raggiungere gli endpoint DoH, ponete i resolver dietro rate limiting e controlli di rete, eseguite named sotto un supervisore che lo riavvia automaticamente e monitorate i crash ripetuti. Queste misure limitano il raggio d'impatto ma non sostituiscono l'applicazione di BIND 9.20.29 o 9.21.26.
Fonti
ISC — CVE-2026-77692: Unauthenticated remote crash of named via a single DoH SIG(0) request
SecurityWeek — ISC Patches 14 Vulnerabilities in BIND 9 Security Update
The Hacker News — BIND 9 Update Fixes 14 Flaws, Including an Unauthenticated Crash Over DNS-over-HTTPS