Zoomsday: bucare Zoom bastavano 20 prompt AI
Un partecipante malevolo a una riunione Zoom poteva tentare di eseguire codice sul dispositivo di un altro partecipante, senza bisogno di un clic o di un download legati al contenuto malevolo. Zoom ha già distribuito le correzioni per le tre vulnerabilità coinvolte, prima che la ricerca venisse resa pubblica. Il dettaglio che ha reso il caso virale è un altro: i ricercatori sostengono di essere arrivati da zero a un exploit funzionante in meno di 24 ore, con meno di 20 prompt a modelli AI pubblicamente disponibili.
La società di ricerca offensiva A Security ha individuato la catena di vulnerabilità l'8 giugno 2026 e l'ha comunicata a Zoom il 10 giugno. Zoom ha pubblicato i tre bollettini ufficiali (ZSB-26015, ZSB-26016, ZSB-26017) l'11 agosto 2026, in coincidenza con la divulgazione pubblica della ricerca da parte di A Security, curata dal ricercatore Idan Levcovich con Iliya Fayans e Lidor Elias.
Questo articolo è informativo ed è stato verificato incrociando i bollettini ufficiali di Zoom con il report tecnico originale di A Security. Eventuali consigli o link commerciali saranno sempre indicati in modo trasparente.
In breve
"Zoomsday" è il nome dato a una catena di tre vulnerabilità nella funzione di annotazione di Zoom (CVE-2026-53413, CVE-2026-53414, CVE-2026-53415), corrette da Zoom tra giugno e luglio 2026 e divulgate pubblicamente l'11 agosto. Due erano classificate High con CVSS 8,3: secondo A Security, lo sfruttamento non richiedeva alla vittima di cliccare link, aprire file o interagire direttamente con il contenuto malevolo. La parte che ha superato l'ambito tecnico è che A Security dichiara di aver costruito l'intero exploit in meno di un giorno, con meno di 20 prompt a modelli AI pubblici.
Sei in una riunione di lavoro su Zoom. Tra i partecipanti c'è un attaccante. Non clicchi link, non apri file e non scarichi nulla: il partecipante malevolo sfrutta il canale che Zoom usa per le annotazioni, con dati costruiti appositamente, e può arrivare a eseguire codice sul tuo dispositivo. È ciò che A Security ha dimostrato, prima che Zoom distribuisse le correzioni.
Zoom ha già corretto le tre vulnerabilità: ecco le versioni sicure, cosa fare per proteggerti subito e perché il vero caso è la velocità con cui l'AI ha accelerato la ricerca.
Su ScelgoIo ho già raccontato più volte come le minacce digitali si stiano spostando da schemi grossolani a tecniche sempre più difficili da riconoscere, dai falsi client VPN scaricati da siti clonati al malware SparkCat travestito da software legittimo. Il caso "Zoomsday" è diverso da entrambi: qui non c'è nessun file da scaricare né nessun sito da imitare. La falla era dentro Zoom stesso, in una funzione che milioni di persone usano ogni giorno senza pensarci due volte. Ed è diverso anche per un altro motivo, che è il vero centro di questo articolo: il modo in cui è stata trasformata in un attacco funzionante.
Cos'è successo: la falla nell'annotazione di Zoom
Il punto di partenza è una funzione che quasi tutti quelli che usano Zoom per lavoro hanno toccato almeno una volta: l'annotazione, cioè la possibilità di disegnare, scrivere testo o aggiungere forme direttamente sopra lo schermo condiviso durante una riunione. È pensata per essere leggera e immediata, e proprio per questo gira in background su ogni chiamata, pronta a essere usata in qualunque momento anche se nessuno la sta guardando.
Secondo la ricostruzione di A Security, ogni volta che un partecipante disegna qualcosa, il client Zoom non invia un'immagine: costruisce un oggetto digitale che descrive quel disegno (un tratto, una forma, una casella di testo) e lo spedisce agli altri partecipanti attraverso un protocollo proprietario, senza documentazione pubblica. Il client di chi riceve quell'oggetto lo ricostruisce automaticamente, senza chiedere conferma a nessuno: è un processo interamente automatico, pensato per essere istantaneo. L'attaccante doveva comunque trovarsi nella stessa riunione della vittima: non si tratta di un attacco lanciabile verso un utente qualsiasi su Internet.
I ricercatori hanno scoperto che il sistema che riceve questi "disegni" non controlla bene chi li sta davvero inviando né quanto sono grandi i dati che dichiara di contenere. Costruendo un messaggio apposta, camuffato da normale conferma di ricezione, sono riusciti a far scrivere al client della vittima molti più dati di quelli previsti in un'area di memoria troppo piccola per contenerli — e a far sì che quella scrittura in eccesso finisse esattamente dove serviva per prendere il controllo del programma.
Questa parte è per chi vuole il dettaglio tecnico. Se ti interessa solo capire cosa rischiavi e cosa fare, puoi saltarla e andare alla sezione sulle versioni sicure.
Le tre vulnerabilità in dettaglio, con i dati ufficiali
Uno dei problemi che vedo spesso in questo tipo di notizie è che si parla di "una falla gravissima" senza mai indicare numeri verificabili. Qui i numeri ci sono, e vengono direttamente dai bollettini ufficiali pubblicati da Zoom l'11 agosto 2026, poi aggiornati il 14 agosto con una revisione che ha corretto la versione di Zoom Workplace indicata e aggiunto Zoom Video SDK tra i prodotti coinvolti.
Nota sulla colonna "Corretta in": le prime due CVE erano già risolte lato client dalla versione 7.1.0. La 7.1.5 diventa necessaria solo per chiudere anche la terza. In pratica, per essere al sicuro da tutte e tre contemporaneamente serve la versione più alta, 7.1.5 (o 7.0.6 sul ramo precedente) — è il numero che trovi nella checklist a fine articolo.
Un dettaglio che vale la pena chiarire, perché è facile fraintenderlo: la terza falla, CVE-2026-53415, non è stata trovata da A Security. Lo stesso report di A Security lo dice esplicitamente: quando hanno segnalato le prime due vulnerabilità, Zoom li ha informati che quella terza falla, nello stesso motore di annotazione, era già stata individuata e corretta internamente dal team Zoom Offensive Security, come conferma anche il bollettino ZSB-26017. È corretto dire che "Zoomsday" comprende tre CVE, ma solo due sono il risultato diretto della ricerca assistita da AI di cui si parla tanto in queste ore.
C'è anche un'incongruenza apparente che vale la pena segnalare invece di ignorare. Il vettore CVSS ufficiale di CVE-2026-53413 (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H) classifica l'interazione dell'utente come "richiesta" (UI:R), mentre A Security descrive l'attacco come "zero-click". Zoom non ha pubblicato una nota che spieghi la differenza, ed è una discrepanza che nessuna delle due fonti chiarisce direttamente. Una lettura possibile, ma resta un'interpretazione nostra e non una spiegazione ufficiale, è che nel punteggio CVSS il semplice fatto di partecipare alla riunione sia stato conteggiato come requisito minimo di interazione, mentre A Security si riferisce all'assenza di un'azione specifica sul messaggio malevolo, come un clic o un download. Va anche detto che quello 8,3 è il punteggio assegnato dal vendor: al momento in cui scriviamo, il National Vulnerability Database del NIST non ha ancora pubblicato una propria valutazione CVSS indipendente per questa CVE.
Il vero caso: da zero a exploit in 24 ore con meno di 20 prompt
Fin qui, la storia è quella di una falla software seria ma già chiusa, come ce ne sono diverse ogni mese nei bollettini di sicurezza di qualunque grande software. Il motivo per cui "Zoomsday" sta circolando molto più delle altre è un altro, e riguarda il modo in cui è stata trovata.
A Security racconta di aver iniziato dal client Android di Zoom nella versione 7.0.4, il cui pacchetto conta in tutto 121 librerie native. Il primo passo è stato un agente AI incaricato di classificare automaticamente il rischio delle funzioni raggiungibili da un punto di ingresso JNI (l'interfaccia tra il codice Java e quello nativo, l'unica porzione che i ricercatori potevano ispezionare in modo automatico su quella scala): su quel sottoinsieme più ristretto, pari a 70 librerie, l'agente ha prodotto una classifica di 3.762 funzioni in base al rischio, dando priorità a quelle che gestiscono dati non fidati con operazioni di copia in memoria potenzialmente pericolose. È un dettaglio che vale la pena riportare perché ridimensiona un po' la narrazione "l'AI ha trovato la falla in un colpo solo": secondo A Security, quella prima classificazione automatica aveva messo la libreria dell'annotazione, poi rivelatasi quella vulnerabile, al 45° posto in quella graduatoria su 70, non ai primi posti — ed è stata scartata inizialmente, per essere ripescata solo in un secondo momento con un metodo diverso. Il percorso che ha portato alla scoperta vera è stato più simile a un lavoro investigativo umano supportato dall'AI passo per passo — tracciare dinamicamente il client durante una riunione reale per vedere quali funzioni si attivano quando si disegna qualcosa sullo schermo — che a una singola richiesta magica.
Una volta individuata la libreria giusta (libannotate.so), il resto del lavoro — dalla ricostruzione del formato dei messaggi fino alla scrittura di un exploit funzionante contro dispositivi di test reali su macOS, capace di far aprire l'applicazione Safari come prova dell'esecuzione di codice — è stato condotto dai ricercatori con l'assistenza di modelli AI. Secondo quanto il ricercatore capo Idan Levcovich ha dichiarato alla testata specializzata SC Media, il team ha lavorato nello specifico con i modelli Claude Opus 4.7 e Opus 4.8 di Anthropic, insieme a strumenti come il plugin IDA Pro e Frida in modalità MCP per il reverse engineering e il tracciamento dinamico. In totale, tra individuazione della falla e costruzione dell'exploit, A Security dichiara di aver usato meno di 20 prompt e meno di 24 ore.
È un dato che va preso per quello che è: un'affermazione della società che ha condotto la ricerca, non una misurazione indipendente verificata da terzi. A Security stessa lo inquadra come un cambio di scala rispetto a un lavoro che, secondo la loro stessa valutazione, avrebbe richiesto in precedenza un piccolo team di specialisti per diversi mesi — una stima loro, utile per dare l'idea del salto più che come dato scientifico verificabile. Anche considerando che tempi e risorse sono stime fornite dalla stessa società, resta comunque significativa la dimostrazione tecnica pubblicata da A Security: l'exploit ha funzionato contro dispositivi di test reali su più sistemi operativi, ed è stato costruito da un singolo ricercatore in un giorno lavorativo. "La barriera per produrre questa classe di armi è crollata, e non tornerà indietro", scrivono i ricercatori nella loro disclosure. Non significa che chiunque, senza alcuna competenza, possa ripetere lo stesso risultato: servivano comunque strumenti di reverse engineering professionali, la capacità di leggere un binario ARM64 e di capire cosa suggeriva l'AI passo per passo. Significa che il tempo e le competenze specialistiche necessarie per arrivare a un exploit di questo livello si sono ridotti in modo molto netto, ed è questo — non "20 prompt per bucare Zoom" — il punto su cui vale la pena riflettere.
Cosa rischiava davvero chi usava Zoom
Vale la pena essere precisi su questo punto, perché è quello che interessa a chi legge non da addetto ai lavori. Se lo sfruttamento fosse riuscito prima della correzione, un partecipante malevolo a una riunione avrebbe potuto eseguire codice sul dispositivo di un altro partecipante senza alcun segnale visibile di compromissione. A Security elenca tra le conseguenze possibili la sottrazione silenziosa di dati, l'attivazione non autorizzata di microfono o videocamera e l'installazione di ulteriore software dannoso. Nella dimostrazione pratica condotta dai ricercatori su macOS, l'exploit è arrivato a far aprire l'applicazione Safari sul Mac della vittima: non è un danno in sé, ma è la prova che il codice arbitrario dell'attaccante stava effettivamente girando sul dispositivo altrui.
Quest'ultimo punto merita una spiegazione, perché va contro l'istinto comune secondo cui "più crittografia end-to-end uguale più sicurezza in ogni caso". Il 15 luglio 2026 Zoom ha attivato una mitigazione lato server che intercetta e blocca i messaggi di annotazione costruiti in modo anomalo prima che raggiungano i client non ancora aggiornati. Questo filtro, però, richiede che il server possa leggere il contenuto del messaggio — cosa che nelle riunioni con crittografia end-to-end attiva non è tecnicamente possibile, perché è proprio quello il punto della E2EE. Per chi usava riunioni E2EE con un client non aggiornato, quindi, la finestra di rischio è rimasta aperta più a lungo, fino alla correzione definitiva lato client del 20 luglio (per la terza falla) e fino all'aggiornamento effettivo del proprio dispositivo. Su questo punto va detto con precisione cosa consiglia la fonte: A Security raccomanda esplicitamente, nella propria guida alla mitigazione, di disattivare temporaneamente la crittografia end-to-end finché non tutti i client sono aggiornati, proprio per lasciare operativo il filtro lato server. La nostra posizione editoriale è più prudente, e la dichiariamo come tale: rinunciare alla E2EE ha un costo in termini di riservatezza della riunione, quindi la priorità che consigliamo resta aggiornare il client il prima possibile; disattivare la E2EE è nella lista delle opzioni indicate dai ricercatori, non un passaggio che raccomandiamo come prima scelta.
Una nota di realismo, prima della checklist: per quanto risulta dalle fonti pubbliche disponibili, non ci sono segnalazioni di sfruttamento reale della falla prima della pubblicazione della ricerca. È una distinzione importante, per non trasformare una storia di divulgazione responsabile, gestita correttamente da entrambe le parti, in un allarme mai confermato.
Cosa fare adesso: versioni sicure e checklist
Il messaggio pratico, a differenza del titolo, è tranquillizzante: le correzioni esistono già e sono distribuite da settimane. Il compito di chi legge è verificare di averle davvero installate, non smettere di usare Zoom.
| Prodotto | Versione minima corretta | Note |
|---|---|---|
| Zoom Workplace | 7.1.5 oppure 7.0.6 | Windows, macOS, Linux, iOS, Android — copre tutte e tre le CVE |
| Zoom Rooms | 7.1.5 | Tutte le piattaforme supportate |
| Zoom Meeting SDK | 7.1.5 | Tutte le piattaforme supportate |
| Zoom Workplace VDI Client (Windows) | 7.0.11 oppure 6.6.16 | Versione minima diversa a seconda del ramo installato |
| Zoom Video SDK | 2.6.5 | Rilevante soprattutto per chi integra Zoom in app di terze parti |
Dati tratti dai bollettini ufficiali Zoom ZSB-26015, ZSB-26016 e ZSB-26017 (revisione del 14/08/2026). Per Zoom Rooms e Meeting SDK, la soglia 7.1.0 basta a coprire le prime due CVE: la 7.1.5 riportata qui è il minimo per essere protetti anche dalla terza. Per Zoom Video SDK, ZSB-26015 e ZSB-26016 indicano come soglia la versione 2.6.0, mentre ZSB-26017 indica 2.6.5: riportiamo quest'ultima perché copre tutte e tre le vulnerabilità.
- A Security — "ZOOMSDAY" — il report tecnico originale dei ricercatori, con timeline della disclosure e dettagli di sfruttamento
- Zoom Security Bulletin ZSB-26015 (CVE-2026-53413) — bollettino ufficiale con versioni interessate e vettore CVSS
- Zoom Security Bulletin ZSB-26016 (CVE-2026-53414) — bollettino ufficiale sulla vulnerabilità di buffer over-read
- Zoom Security Bulletin ZSB-26017 (CVE-2026-53415) — bollettino ufficiale sulla terza vulnerabilità, di scoperta interna a Zoom
- TechRepublic — sintesi tecnica con indicazioni di mitigazione per i reparti IT
- SC Media — intervista al ricercatore capo Idan Levcovich, con i dettagli sui modelli AI usati
Domande frequenti
Autore: Rocco Caiazza – Fondatore di ScelgoIo
