La risposta breve
Un resolver BIND non aggiornato può essere mandato in crash da una singola richiesta. Il 16 settembre 2026 ISC ha divulgato 14 vulnerabilità in BIND 9 — sette ad alta gravità (CVSS 7.5), sette medie — e ha rilasciato le correzioni in BIND 9.20.29 e 9.21.26. La più eclatante è la CVE-2026-77692: un attaccante non autenticato manda in crash il processo named inviando una richiesta DNS-over-HTTPS malformata con un record SIG(0) crittograficamente non valido e chiudendo presto la connessione. Altre falle abilitano esaurimento della memoria, cache poisoning e iniezione di dati arbitrari nelle zone DNS. ISC dichiara di non essere a conoscenza di sfruttamenti in the wild; la remediation è aggiornare immediatamente.
Per i team in Italia il punto non è una singola CVE — è che il DNS è la dipendenza sotto ogni altra dipendenza. Se la risoluzione dei nomi si ferma, si ferma tutto ciò che risolve un hostname, dal vostro API gateway al callback del vostro processore di pagamento. Ecco perché il DNS rientra nella stessa cadenza di patching e nello stesso progetto di resilienza del resto della vostra piattaforma cloud e DevOps, e non in una casella con la scritta «imposta e dimentica».
Cosa ha divulgato ISC
BIND 9 è l'implementazione open source di riferimento del Domain Name System, mantenuta dall'Internet Systems Consortium (ISC) e utilizzata da provider Internet, società di hosting, aziende e produttori di appliance in tutto il mondo. Il suo demone named risponde alle query DNS che trasformano gli hostname in indirizzi IP. Poiché così tante infrastrutture risolvono i nomi tramite BIND, un difetto al suo interno non resta in una sola rete — si propaga a tutto ciò che sta a valle della risoluzione.
Il 16 settembre 2026 ISC ha pubblicato un aggiornamento di sicurezza coordinato che copre 14 CVE e ha rilasciato BIND 9.20.29 e 9.21.26 per correggerle. Sette dei problemi sono classificati ad alta gravità con un punteggio CVSS di 7.5, e sette a gravità media. BIND 9.20.29 affronta tutte e quattordici; BIND 9.21.26 ne affronta tredici, perché una delle falle non riguarda il ramo di sviluppo 9.21. ISC ha inoltre rilasciato una corrispondente build Supported Preview Edition per i clienti su quel ramo.
La falla più clamorosa è la CVE-2026-77692 (CVSS 7.5), un crash remoto non autenticato. Un attaccante può terminare named trasmettendo una singola richiesta DNS-over-HTTPS (DoH) che contiene un record di firma SIG(0) crittograficamente non valido e poi chiudendo bruscamente la connessione di trasporto. Non servono autenticazione, credenziali valide né una catena di exploit in più fasi — una richiesta contraffatta basta a far cadere il resolver, esattamente il tipo di primitiva di denial-of-service economica e ripetibile che rende nervosi i team DNS. Gli altri problemi ad alta gravità sono anch'essi crash attivabili da remoto, esaurimento di memoria o saturazione delle risorse. Raggiungibile, a basso costo e mirato all'impianto centrale: è proprio questo il profilo di rischio che un penetration test e audit di sicurezza deve far emergere prima che lo faccia un attaccante. ISC ha dichiarato di non essere a conoscenza di alcuno sfruttamento dei bug risolti in the wild, e raccomanda di aggiornare senza indugio.
Perché un crash DNS è peggio di quanto sembri
Le falle di denial-of-service sono facili da sottovalutare. Non fanno trapelare dati né consegnano una shell all'attaccante, così vengono archiviate sotto i titoloni sull'esecuzione di codice remoto. Ma il DNS è l'eccezione che rompe questo istinto: è la dipendenza sotto ogni altra dipendenza. Quando named va in crash, la risoluzione dei nomi si ferma, e con essa si ferma tutto ciò che risolve un hostname — le chiamate interne servizio-a-servizio, le connessioni ai database indirizzate via DNS, gli endpoint delle API cloud, i callback dei webhook, il recapito delle e-mail e la porta d'ingresso a cui bussano i vostri clienti. Un'interruzione del resolver non degrada una funzionalità; può inghiottire un'intera piattaforma in un colpo solo.
Il crash DoH acuisce ulteriormente il problema. Il DNS-over-HTTPS è sempre più abilitato affinché i resolver siano raggiungibili tramite normale HTTPS, il che significa che la richiesta che provoca il crash sembra normale traffico web cifrato e può arrivare da ovunque l'endpoint sia raggiungibile. Un singolo pacchetto non autenticato che fa cadere il processo in modo affidabile è uno strumento di denial-of-service che un attaccante può lanciare ripetutamente, tenendo il resolver a terra alla stessa velocità con cui si riavvia. Se quel resolver è un resolver interno condiviso o un servizio esposto su Internet, il raggio d'impatto è ogni client dietro di esso.
I problemi a gravità media portano un rischio più silenzioso ma probabilmente più insidioso: cache poisoning e iniezione di dati arbitrari nelle zone DNS. Dove un crash è rumoroso ed evidente, una cache avvelenata è silenziosa — può indirizzare utenti e servizi verso indirizzi controllati dall'attaccante mentre ogni dashboard resta verde. È la differenza tra un'interruzione che notate in pochi secondi e una compromissione che potreste non notare per giorni — ed è per questo che queste falle con punteggio più basso meritano la stessa patch, non un rinvio.
Cosa significa per i team di sviluppo in Italia
La prima lezione è che il DNS è infrastruttura che possedete, non un servizio pubblico che affittate — anche quando sembra invisibile. Molti team applicano le patch alle dipendenze applicative con un calendario serrato, ma lasciano andare alla deriva il resolver fornito con un'immagine di base, un container o un'appliance di rete, perché «funziona e basta». BIND è presente in più punti di quanti ne registri di solito un inventario degli asset. Trovare ogni istanza — server autonomi, container e appliance integrate — è il lavoro ingrato che decide se questo aggiornamento arriva davvero ovunque debba arrivare.
La seconda lezione è resilienza by design, perché un crash non sia un'interruzione. Se il guasto di un singolo resolver fa cadere la vostra piattaforma, è un problema di architettura che questa CVE ha solo messo in luce. Resolver ridondanti, DNS gestito con failover automatico, health check che tolgono un named morto dalla rotazione e limiti stringenti su chi può raggiungere un endpoint DoH trasformano un crash da una richiesta da incidente di business in un non-evento. Presupponete che i componenti dell'infrastruttura si guasteranno; progettate in modo che la risoluzione dei nomi sopravviva quando uno di essi cede.
In terzo luogo, è un obbligo di disponibilità e integrità, non solo un ticket operativo. Per i team dell'UE, DORA rende espliciti la resilienza ICT e la gestione dei componenti di terze parti per le entità finanziarie, e la NIS2 — recepita in Italia con il D.lgs. 138/2024 — alza l'asticella per i servizi essenziali e importanti. Per i team in FinTech e sanità, disponibilità e integrità dei sistemi centrali rientrano direttamente nelle aspettative della vigilanza (Banca d'Italia/Consob), della ISO 27001 e delle misure minime di sicurezza ICT AgID. Un'interruzione DNS o una zona avvelenata è esattamente il tipo di evento che questi quadri chiedono di prevenire, rilevare e documentare. Poter dimostrare quali resolver eseguivano le versioni interessate, quando avete applicato la patch e come la risoluzione resta operativa durante il guasto di un componente è la prova che cercheranno gli auditor.
Cosa fare ora
- Inventariate ogni istanza di BIND. Individuate tutti i resolver e i server autoritativi che eseguono BIND 9 — host autonomi, container e immagini di base, nonché appliance o prodotti che lo integrano. Le istanze che dimenticate sono quelle che restano vulnerabili.
- Aggiornate alle build corrette. Passate a BIND 9.20.29 o 9.21.26 (o alla build Supported Preview Edition corrispondente). Trattate i resolver esposti su Internet e tutto ciò che espone DNS-over-HTTPS come priorità assoluta, poiché la CVE-2026-77692 richiede una sola richiesta non autenticata.
- Riducete l'esposizione dove non potete applicare subito la patch. Limitate quali reti e client possono raggiungere l'endpoint DoH, applicate rate-limiting e filtri al perimetro e assicuratevi che un resolver in crash venga automaticamente rimosso dalla rotazione, così i client fanno failover invece di rimanere bloccati.
- Sorvegliate il poisoning, non solo i crash. I problemi a gravità media possono iniettare silenziosamente dati in cache e zone. Monitorate i record inattesi, validate le risposte con DNSSEC dove possibile e generate allarmi sui riavvii di
namede sulle anomalie nelle risposte, non solo sui tempi di inattività. - Integrate la ridondanza e testatela. Fate girare più di un resolver, valutate un DNS gestito o secondario per le zone critiche e aggiungete i server DNS e i loro protocolli esposti al perimetro del vostro prossimo penetration test, così questo livello smette di essere un punto cieco.
Domande frequenti
Cosa è stato corretto in BIND 9.20.29 e 9.21.26?
ISC ha corretto 14 vulnerabilità in BIND 9, divulgate il 16 settembre 2026 — sette ad alta gravità (CVSS 7.5) e sette medie. BIND 9.20.29 corregge tutte e 14; BIND 9.21.26 ne corregge 13, perché una falla non riguarda il ramo 9.21. ISC raccomanda di aggiornare immediatamente alle versioni corrette.
Cos'è la CVE-2026-77692?
È un crash remoto non autenticato del processo named di BIND, valutato CVSS 7.5. Un attaccante termina il server inviando una singola richiesta DNS-over-HTTPS malformata che trasporta un record di firma SIG(0) crittograficamente non valido, poi chiudendo prematuramente la connessione. Una richiesta basta e non serve autenticazione — un vettore di denial-of-service economico e ripetibile contro qualsiasi resolver BIND che espone un endpoint DoH.
Queste falle vengono sfruttate in the wild?
Al momento della divulgazione, il 16 settembre 2026, ISC ha dichiarato di non essere a conoscenza di alcuno sfruttamento dei bug risolti. Non è un motivo per attendere: il crash DoH richiede una richiesta non autenticata, diverse altre falle ad alta gravità sono denial-of-service attivabili da remoto e un'interruzione DNS si ripercuote su ogni servizio che dipende dalla risoluzione dei nomi.
Cosa consentono le altre vulnerabilità di BIND?
I restanti problemi ad alta gravità consentono ad attaccanti remoti di provocare crash, esaurimento della memoria o saturazione delle risorse, tutti con esito di denial-of-service. I problemi a gravità media possono causare cache poisoning, uso eccessivo di memoria o CPU, o iniezione di dati arbitrari nelle zone DNS, con tecniche come query QTYPE TKEY contraffatte, risposte negative sovradimensionate e record SVCB/HTTPS in AliasMode. Il cache poisoning è il più pericoloso perché può reindirizzare silenziosamente il traffico.
Cosa dovrebbero fare ora i team che usano BIND?
Inventariate ogni resolver e server autoritativo BIND, inclusi container e appliance che integrano BIND, e aggiornate a 9.20.29, 9.21.26 o alla build Supported Preview Edition corrispondente. Date priorità ai resolver esposti su Internet e agli endpoint DoH, limitate l'accesso DoH dove non potete applicare subito la patch, fate girare un DNS ridondante o gestito perché un resolver in crash non faccia cadere la risoluzione, e aggiungete il DNS al perimetro del vostro prossimo penetration test.
Fonti
ISC Knowledge Base — 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