Gyazo espone 23,6 milioni di account mentre BIND e Unbound aprono il fronte DNS

🛡️ Executive Summary

• Gyazo conferma l’esposizione di 23,62 milioni di record utente e circa 490 milioni di record di metadata associati alle immagini.
• BIND 9.20.29 corregge 14 vulnerabilità, compresi crash remoti, problemi DNSSEC e una falla DoH sfruttabile senza autenticazione.
• Unbound fino alla versione 1.26.0 contiene CVE-2026-81642, buffer overflow nel validatore DNSSEC con denial of service e possibile esecuzione remota di codice.

Tre disclosure pubblicate a poche ore di distanza mostrano quanto l’infrastruttura Internet continui a dipendere da componenti che raramente attirano l’attenzione finché qualcosa non si rompe. Gyazo ha confermato un’intrusione partita dal proprio server di upload e culminata nell’accesso al database, con milioni di account e centinaia di milioni di metadata esposti. Nello stesso momento ISC ha corretto 14 vulnerabilità in BIND 9, mentre NLnet Labs ha chiuso una falla critica nel validatore DNSSEC di Unbound che può causare denial of service e, secondo il vendor, anche esecuzione remota di codice. L’asse comune non è il singolo exploit, ma la quantità di fiducia concentrata in servizi apparentemente invisibili: upload server, resolver DNS e validazione delle risposte.

Gyazo: da una falla nell’upload server al database con 23,62 milioni di record

Helpfeel ha confermato ufficialmente la violazione di Gyazo dopo che l’11 settembre un attore non autorizzato ha sfruttato una vulnerabilità nel server utilizzato per l’upload delle immagini, ottenendo la possibilità di eseguire comandi arbitrari. L’azienda ha rilevato attività sospette la stessa sera e dichiara di avere bloccato i percorsi di accesso e corretto la vulnerabilità entro le prime ore del 12 settembre. L’indagine ha però stabilito che l’attaccante aveva già raggiunto il database. Sono stati esposti circa 23,62 milioni di record relativi agli utenti, contenenti in misura variabile nomi, email, password hash, user ID, device ID, login session ID, token di integrazione X, informazioni Google SSO, profili, date di registrazione e ultimo accesso, piano e stato di fatturazione. Helpfeel esclude l’esposizione di numeri di carta o altri dati di pagamento.

La parte più delicata riguarda però le immagini. L’azienda ha identificato circa 490 milioni di record di metadata, prevalentemente collegati a contenuti registrati entro gennaio 2019, oltre ai metadata di altri 2,4 milioni di immagini recuperati attraverso filtri specifici. Tra i campi figurano image ID utilizzabili per costruire gli URL Gyazo, IP sorgente, User-Agent, eventuali dati EXIF di localizzazione, testo OCR, titolo e URL originale. L’azienda ammette inoltre che l’aggressore ha ottenuto una lista delle immagini private e non esclude che alcune siano state visualizzate. Il rischio supera quindi il semplice furto delle credenziali: screenshot apparentemente innocui possono contenere token, email, console amministrative, dati personali e informazioni aziendali visibili direttamente nell’immagine.

Leggi anche: Ransom Busters, Sakura e CareCloud mostrano perché password hashate e assenza di carte non chiudono il rischio

BIND 9 corregge 14 falle e il DNSSEC diventa ancora una superficie DoS

Sul livello infrastrutturale, le release note ufficiali di BIND 9.20.29 descrivono un aggiornamento eccezionalmente ampio. ISC ha corretto 14 vulnerabilità, diverse delle quali interessano direttamente resolver ricorsivi, DNSSEC, DoH e gestione della cache. Tra le più immediate compare CVE-2026-77692, che permette a un client non autenticato di far terminare named attraverso una richiesta DNS-over-HTTPS contenente una firma SIG(0) non valida, chiudendo la connessione prima del completamento della verifica. CVE-2026-80274 consente invece a un server autorevole controllato dall’attaccante di provocare l’uscita inattesa di un resolver che valida DNSSEC attraverso una sequenza costruita di record wildcard, NSEC3 e NSEC. ISC non segnala exploit attivi conosciuti.

Altre falle colpiscono disponibilità e correttezza della validazione. CVE-2026-19668 permette di forzare un resolver a consumare CPU attraverso grandi quantità di materiale crittografico DNSSEC senza corrispondenze valide; CVE-2026-19662 è un use-after-free nella gestione delle prove NOQNAME memorizzate nella cache e può portare al crash del processo. La concentrazione di problemi nello stesso sottosistema conta più del numero assoluto delle CVE: il resolver DNS è un servizio che deve rimanere disponibile continuamente e processa dati provenienti da domini e server autorevoli esterni. Un errore di memoria, un’asserzione raggiungibile da remoto o un consumo di CPU controllabile dall’attaccante possono quindi degradare un’infrastruttura dalla quale dipendono contemporaneamente migliaia di applicazioni.

ISC indica BIND 9.20.29 come release stabile corretta e 9.21.26 per il ramo development, con alcune differenze nell’impatto delle singole CVE. L’aggiornamento arriva inoltre in un anno anomalo per il progetto: ISC aveva già avvertito a maggio che l’uso crescente degli LLM nella ricerca di vulnerabilità stava aumentando di oltre dieci volte il volume storico delle segnalazioni ricevute, inducendo il progetto a prepararsi a security release più frequenti.

Unbound trasforma una DNSKEY malformata in possibile esecuzione di codice

Il problema più grave per severità arriva però da Unbound. L’advisory di NLnet Labs per CVE-2026-81642 descrive un heap buffer overflow nel validatore DNSSEC durante l’elaborazione di una DNSKEY. Una chiave costruita con un compression pointer del nome proprietario diretto verso il proprio RDATA può provocare l’overflow del buffer utilizzato durante il calcolo del digest. Il vendor assegna severità Critical e indica come conseguenze sia denial of service sia possibile Remote Code Execution attraverso dati controllati dall’attaccante. Sono interessate tutte le versioni di Unbound fino alla 1.26.0 compresa.

L’attaccante deve controllare una zona malevola e indurre il resolver vulnerabile a interrogarla, requisito molto meno restrittivo di un accesso amministrativo o locale. Non risultano al momento campagne di sfruttamento citate dall’advisory, ma l’assenza di exploit osservati non riduce la priorità della patch quando il componente è un resolver ricorsivo esposto alle risposte provenienti da Internet. Gli amministratori devono aggiornare alla versione corretta indicata da NLnet Labs oppure applicare manualmente la patch fornita dal progetto. La dinamica richiama altri incidenti nei quali la compromissione del DNS ha trasformato un nodo apparentemente periferico in un punto di controllo sul traffico.

Continua con:

• CISA, cPanel, Fortinet e SimpleHelp: gli attacchi attivi contro le infrastrutture Internet-facing
• Sanità sotto attacco: Aesto espone 9,5 milioni di pazienti

La superficie critica è quella che gli utenti non vedono

Gyazo, BIND e Unbound non condividono la stessa vulnerabilità né lo stesso impatto, ma mostrano la stessa asimmetria. Nel primo caso un server di upload apparentemente periferico ha permesso di raggiungere un database con milioni di identità e metadata capaci di ricostruire contenuti privati. Negli altri due, componenti DNS che normalmente funzionano senza essere percepiti dagli utenti possono diventare punti di denial of service, manipolazione della validazione o potenziale esecuzione di codice.

Per i team di sicurezza la priorità è quindi diversa nei tre casi ma immediata: Gyazo richiede rotazione delle password, attenzione al phishing e valutazione dei dati eventualmente contenuti negli screenshot; BIND e Unbound richiedono inventario dei resolver e aggiornamento rapido delle release vulnerabili. La lezione infrastrutturale è più ampia: i servizi meno visibili sono spesso quelli ai quali viene delegata la maggiore quantità di fiducia. Quando upload, DNS o validazione crittografica falliscono, l’impatto non rimane confinato al singolo componente che ha generato il bug.