tl;dv, la falla che ha lasciato aperte 181.874 riunioni registrate con l’AI
Una regola di sicurezza mancante su tl;dv ha esposto 181.874 riunioni e circa mille chiamate dal vivo. Cosa insegna a chi usa un notetaker AI.
Se usi un assistente AI che entra nelle tue videochiamate, registra tutto e ti restituisce trascrizione e riassunto, questa storia ti riguarda da vicino. Il ricercatore indipendente noto come BobDaHacker ha pubblicato il 4 agosto 2026 un’analisi dettagliata in cui documenta come tl;dv, una delle piattaforme di note automatiche per riunioni più diffuse, abbia lasciato per mesi il proprio database interrogabile da qualsiasi utente registrato. Il risultato è un archivio di 181.874 riunioni consultabile da chiunque avesse un account gratuito, comprese circa mille chiamate ancora in corso in un dato momento.
Non si tratta di un attacco sofisticato. Si tratta di una regola di configurazione dimenticata.
Che cosa è successo davvero dentro il database di tl;dv
tl;dv, acronimo di “Too Long; Didn’t View”, funziona come molti strumenti simili: fai entrare un bot nella tua riunione su Google Meet, Zoom o Microsoft Teams, il bot registra l’audio e il video, un modello linguistico produce trascrizione, riassunto e punti d’azione. La piattaforma dichiara oltre due milioni di utenti e viene usata per colloqui di lavoro, chiamate commerciali, revisioni delle performance e riunioni di strategia interna. Esattamente il tipo di conversazione in cui qualcuno dice “questa chiamata viene registrata” e poi si parla comunque di numeri, clienti e piani riservati.
Il problema riguarda l’architettura di autenticazione e autorizzazione. Quando ti registri, la piattaforma ti autentica e scambia il tuo token per una credenziale Firebase, che ti permette di interrogare il database Firestore su cui poggia il servizio. Fin qui è tutto normale: è così che funzionano moltissime applicazioni moderne, che espongono il database direttamente al client e affidano la separazione tra clienti alle regole di sicurezza lato server.
Una sola regola mancante
Le regole di sicurezza di Firestore sono la lista che stabilisce chi può leggere che cosa. Se sono scritte bene su una collezione di dati, ogni cliente vede solo i propri record. Se mancano su una collezione, qualsiasi utente autenticato può leggere i dati di tutti gli altri.
Secondo la ricostruzione del ricercatore, tl;dv aveva impostato correttamente queste regole quasi ovunque: utenti, chat, trascrizioni, clip, registrazioni, video, note, team e organizzazioni rispondevano tutti con un errore di accesso negato. Su una sola collezione, quella chiamata meetings, la regola non c’era. E quella collezione conteneva, per ogni riunione, l’indirizzo email di chi l’aveva creata, il provider usato, gli orari e soprattutto l’identificativo della stanza virtuale.
Una svista in un punto solo, moltiplicata per l’intera base clienti.
Dalle registrazioni alle chiamate dal vivo
La parte più delicata non è l’archivio storico, ma il presente. Ogni record contiene anche lo stato della riunione, e quando lo stato è “in registrazione” significa che quella conferenza è attiva in quel momento. L’identificativo della stanza è un link su cui si può entrare.
Il ricercatore descrive di aver osservato la collezione in tempo reale, di aver visto comparire nuove riunioni mano a mano che iniziavano e di essersi collegato a due chiamate dal vivo come prova di concetto: una riunione del Ministero dell’Istruzione della Malesia con oltre 157 partecipanti collegati, e una sessione di lavoro di un gruppo di studenti universitari statunitensi che condividevano lo schermo mentre costruivano la loro applicazione. In entrambi i casi il bot di tl;dv era già nella lista dei partecipanti, e nessuno si è accorto dell’ospite in più.
A qualsiasi ora, secondo l’analisi, nella collezione ci sono circa mille riunioni con lo stato “in registrazione”. Un aggressore con un bot automatizzato avrebbe potuto entrare in tutte contemporaneamente.
La scala del problema: governi, università e aziende
I numeri raccontano quanto in profondità arrivi questo genere di strumenti nel lavoro quotidiano. La collezione conteneva 181.874 record di riunioni, riconducibili a 84.312 utenti distinti distribuiti su 35.003 domini email diversi.
Tra questi comparivano domini governativi di 23 paesi, dal Brasile all’Ucraina, dal Messico al Giappone, passando per Stati Uniti, Filippine, Indonesia, Israele e Malesia. C’erano atenei come Berkeley e l’Università di Tokyo, e aziende private di ogni dimensione. Il ricercatore riferisce inoltre di aver verificato quanti contenuti fossero effettivamente accessibili e non solo elencati: su oltre 27.000 identificativi controllati, più di mille riunioni risultavano pubbliche, con 715 indirizzi email di invitati esposti su 228 domini.
Vale la pena distinguere due livelli di gravità. I metadati, cioè chi ha creato la riunione e quando, sono già di per sé informazioni sensibili: dicono con quale frequenza un’azienda incontra un certo interlocutore e quando un dipendente ha fissato colloqui. Il contenuto vero e proprio, video e trascrizione, era protetto per impostazione predefinita, ma la possibilità di entrare in una chiamata in corso rende la distinzione quasi accademica.
Chi entra dal vivo sente tutto, e non lascia traccia in nessun registro di accessi.
Sei mesi di segnalazioni senza risposta
La cronologia della divulgazione responsabile è forse la parte più istruttiva della vicenda. Secondo il resoconto pubblicato, la falla è stata scoperta a fine gennaio 2026 e segnalata il 28 gennaio, prima via LinkedIn a uno dei fondatori e poi via email al responsabile tecnico. La risposta iniziale è arrivata in pochi minuti ed è stata cordiale, ma alle rassicurazioni non sono seguiti né una correzione né un contatto tecnico.
Il ricercatore documenta solleciti a fine gennaio, a metà febbraio, il 6 marzo e ancora il 22 luglio, tutti con lo stesso esito: messaggi letti e nessuna risposta operativa, con la vulnerabilità ancora sfruttabile. La correzione sembra essere arrivata solo nei giorni a ridosso della pubblicazione dell’articolo, quindi circa sei mesi dopo la prima segnalazione.
L’azienda ha poi risposto pubblicamente con una nota sul proprio blog in cui sostiene che la falla era stata individuata sia da un fornitore esterno di penetration test sia dalla segnalazione indipendente, e che la correzione era stata distribuita e successivamente validata dallo stesso fornitore. Restano però evidenti le distanze tra le due ricostruzioni sulle date, perché la testimonianza del ricercatore indica accessi ancora possibili a fine luglio.
C’è un contrasto che merita di essere notato: la pagina dedicata alla sicurezza della piattaforma esibisce una fila di certificazioni, dalla conformità SOC 2 al GDPR fino all’AI Act europeo, insieme alla promessa di rispondere alle segnalazioni entro 24 ore. Le certificazioni misurano i processi, non l’assenza di errori, e questa storia lo dimostra con una chiarezza brutale.
Perche’ questa storia riguarda ogni assistente AI per riunioni
Il caso tl;dv non è interessante perché quella specifica azienda abbia sbagliato, ma perché la categoria di prodotto a cui appartiene concentra rischi enormi in un punto solo. Un notetaker AI è, per definizione, un servizio a cui deleghi la parte più riservata della tua giornata lavorativa: la conversazione. Il valore che ti offre, cioè trasformare il parlato in testo strutturato e cercabile grazie ai sistemi di riconoscimento vocale e ai modelli linguistici, è lo stesso che rende quel deposito attraente per chi vuole spiare.
C’è poi una questione di consenso. Quando accetti che una riunione venga registrata, stai autorizzando quella registrazione a esistere presso quel fornitore, non a essere elencata in un indice consultabile da estranei. Se sei un’azienda europea e usi uno di questi strumenti, sei tu il titolare del trattamento e il fornitore è il responsabile: la responsabilità verso i tuoi clienti e i tuoi dipendenti non si trasferisce con l’abbonamento.
Il tema si intreccia con la corsa in atto sulla sicurezza applicata all’AI. Da un lato ci sono modelli sempre più capaci di trovare vulnerabilità nel codice, come mostra il lavoro di OpenAI su GPT-5.6-Cyber e il programma Daybreak, e c’è un mercato che sta consolidando gli strumenti per gestire le identità delle applicazioni, come dimostra l’acquisizione di Oasis Security da parte di Cyera. Dall’altro lato ci sono ancora errori elementari di configurazione che vanificano l’intera catena.
La tecnologia difensiva corre. Le pratiche di base, spesso, no.
Cosa puoi fare se usi un notetaker AI
La reazione istintiva sarebbe smettere di usare questi strumenti, ma è una risposta poco realistica e neanche particolarmente utile. Ha più senso ridurre la superficie di rischio con qualche scelta pratica.
- Registra solo quello che serve davvero, e disattiva il bot nelle riunioni che toccano dati personali, questioni legali o trattative delicate.
- Controlla nelle impostazioni del tuo spazio di lavoro chi può accedere agli archivi e per quanto tempo le registrazioni restano conservate, impostando una cancellazione automatica.
- Verifica se il fornitore ha una pagina pubblica per le segnalazioni di sicurezza e se pubblica i tempi effettivi di correzione, non solo i loghi delle certificazioni.
- Chiedi dove sono ospitati i dati e se esiste la possibilità di conservare le trascrizioni in un ambiente sotto il tuo controllo.
Sul fronte tecnologico esistono anche approcci che spostano il problema a monte, riducendo la quantità di dati leggibili in chiaro dal fornitore. La ricerca sulla crittografia applicata all’inferenza, di cui è un esempio il compilatore open source HEIR annunciato da Google, punta esattamente in quella direzione, anche se i tempi di adozione su larga scala non saranno brevi.
Nel frattempo, la difesa più efficace resta la più noiosa: sapere che cosa stai registrando e chi lo custodisce.
Conclusioni
Questa vicenda non racconta un fallimento dell’intelligenza artificiale, perché il modello che trascrive le riunioni ha fatto esattamente il suo lavoro. Racconta un fallimento del contesto attorno al modello, cioè della piattaforma che quei dati li raccoglie, li conserva e dovrebbe proteggerli. È una distinzione importante da tenere a mente ogni volta che valuti uno strumento AI: la qualità del modello ti dice quanto è utile il prodotto, non quanto è sicuro.
La lezione operativa è duplice. Per chi costruisce prodotti AI, le regole di isolamento tra clienti vanno verificate collezione per collezione e testate in modo automatico, perché una singola dimenticanza annulla tutto il resto. Per chi li usa, la domanda giusta da fare a un fornitore non è quante certificazioni possiede, ma quanto tempo impiega a chiudere una segnalazione e come lo dimostra.
Se nella tua azienda usi un assistente AI per le riunioni, prenditi dieci minuti oggi stesso per rivedere impostazioni di conservazione, permessi di accesso e riunioni davvero necessarie da registrare. Continua a seguirci per restare aggiornato su sicurezza, privacy e nuovi strumenti di intelligenza artificiale.