Het artikel beschrijft een kritiek datalek bij het AI-platform tl;dv, waarbij de auteur ontdekte dat de Firestore-collectie 'meetings' geen tenant isolation had. Hierdoor kon elke geauthenticeerde gebruiker metadata van circa 182.000 vergaderingen inzien, waaronder die van overheden uit 23 landen en diverse universiteiten.
De auteur bewijst de kwetsbaarheid door live Google Meet-gesprekken binnen te stappen via blootgestelde conferentie-ID's. Daarnaast werd een interne app ('World Cup Pick'em') ontdekt die persoonlijke gegevens van medewerkers lekte vanwege het ontbreken van authenticatie.
Ondanks herhaalde meldingen sinds januari 2026 aan de CTO en andere contactpersonen, bleef een effectieve oplossing of reactie uit, terwijl het bedrijf op haar website claimt SOC2- en GDPR-compliant te zijn.
tl;dv (Too Lazy; Didn't Validate): 181.874 vergaderingen wagenwijd opengeteld
Ik heb dit gemeld op 28 januari 2026. Het is nu juli 2026. Zes maanden later is de Firestore-database nog steeds wagenwijd open. De CTO heeft nooit gereageerd. Ik vermoed dat mijn e-mails te lang waren en ze niet zijn gelezen.
Wat is tl;dv?
tl;dv (Too Long; Didn't View) is een AI-platform voor het opnemen van vergaderingen. Het platform plaatst een bot in je Google Meet-, Zoom- of Teams-gesprek, neemt alles op, transcribeert de audio en genereert met behulp van AI samenvattingen. Het heeft meer dan 2 miljoen gebruikers, is gesteund door investeerders en wordt aanbevolen door een groot deel van de sales-influencers op LinkedIn.
Ze slaan verkoopgesprekken, sollicitatiegesprekken, functioneringsgesprekken en interne strategiesessies op. Het soort inhoud waarbij iemand zegt: "dit gesprek wordt opgenomen", waarna iedereen zenuwachtig lacht en vervolgens 45 minuten lang bedrijfsgeheimen deelt.
De kwetsbaarheid
Wanneer je je aanmeldt voor tl;dv, authenticeert het platform je met een JWT en ruilt deze in voor een Firebase-token via gw.tldv.io/v1/users/firebase/token. Dat token stelt je in staat om hun Firestore-database op te vragen bij projects/lmi-store/databases/(default).
De collectie 'meetings' heeft geen tenant isolation. Elke geauthenticeerde tl;dv-gebruiker kan elke vergadering van elk account op het platform opvragen. Elk vergaderingsrecord geeft je het e-mailadres van de maker, het conferentie-ID (wat een joinbare Google Meet- of Teams-kamer is), de provider, de opnamestatus en tijdstempels.
Voor vergaderingen met de status 'recording' is dat conferentie-ID een actieve, live call. Je kunt de collectie in realtime volgen, zien wanneer een vergadering start met opnemen, het ID grijpen en onuitgenodigd iemands gesprek binnenwandelen. Op elk gegeven moment staan er ongeveer 1.000 vergaderingen met de status recording in de collectie. Duizend live calls met blootgestelde conferentie-ID's. Een aanvaller met een bot zou ze allemaal gelijktijdig kunnen joinen.
Ik ben twee vergaderingen binnengestapt
Ik heb het gedaan.
Ik haalde een conferentie-ID uit Firestore en trad toe tot een live Google Meet van het Maleisische Ministerie van Onderwijs. Een dame presenteerde aan meer dan 157 deelnemers. De tl;dv-bot stond al in de deelnemerslijst. Ik zat nu in hetzelfde gesprek. Niemand had mij uitgenodigd; de Firestore-database deed dat.
Daarnaast trad ik toe tot een call waar studenten van een grote Amerikaanse universiteit een startup-app aan het bouwen waren. Er waren 21 mensen in het gesprek. Ze deelden hun scherm en lieten hun volledige project zien, discussieerden over prototypes en — ik maak een grapje niet — praatten erover dat ze client-side validatie voor .edu-e-mailadressen moesten toevoegen. Ze waren ook live op het scherm Supabase aan het instellen, waarbij ik alleen maar kon denken: "alsjeblieft, stel RLS-policies in", want de meeste mensen doen dat niet, en dan eindig je zoals tl;dv.
Ik wilde zo graag iets zeggen: "Hé, misschien willen jullie ook server-side validatie." Maar dit was een proof of concept, geen consultancy.
De schaal van het probleem
Ik heb de Firestore 'meetings'-collectie opgevraagd en zag dat er 181.874 vergaderingsrecords waren, behorend tot 84.312 unieke gebruikers over 35.003 e-maildomeinen.
- Overheidsvergaderingen uit 23 landen: waaronder Brazilië, Colombia, Peru, Oekraïne, El Salvador, de Filipijnen, Chili, Indonesië, Mexico, de Verenigde Staten, Qatar, Maleisië, Oezbekistan, Sri Lanka, Haïti, Zuid-Afrika, Jamaica, Honduras, Argentinië, Thailand, Japan, Israël en Belize. Allemaal
.gov-domeinen. Overheidsmedewerkers die gesprekken opnemen op een platform dat elke gebruiker met een gratis account in staat stelt om alles op te sommeren.
- Universiteitsvergaderingen: van Berkeley, de Universiteit van Tokio, De La Salle en Universidad Nacional de Colombia. Tientallen
.edu- en .ac-domeinen.
- Zakelijke vergaderingen: van alle overige 35.000 domeinen. Mitsui-Soko (484 vergaderingen verspreid over vier regionale kantoren), Mitsui Fudosan, HubSpot, Confluent, Mekari, AnyMind Group. Elk bedrijf dat ooit tl;dv heeft gebruikt, had hun vergaderingsmetadata in dezelfde onbeveiligde collectie staan.
De piekmaand was juli 2025 met 43.209 vergaderingen. Het drukste tijdslot: woensdag om 14:00 UTC, met 7.804 vergaderingen. Het uur van de 'hump-day standup'.
Maar wacht, er is meer
Ik wilde weten hoeveel daadwerkelijke inhoud toegankelijk was. Standaard zijn vergaderingen privé (wat betekent dat je de video niet kunt bekijken of het transcript niet kunt zien), dus ik heb 27.334 meeting-ID's gescraped en gecontroleerd welke openbaar waren. Meer dan 1.000 daarvan waren dat. Hierdoor werden 715 e-mailadressen van genodigden blootgesteld over 228 domeinen.
Enkele hoogtepunten: een Braziliaanse overheidsvergadering over natuurbehoud (PACTO Mata Atlântica) met deelnemers van WWF, The Nature Conservancy, Conservation International, WRI en de regering van de staat São Paulo. Vergaderingen van het Oekraïense Ministerie van Digitale Transformatie. Een verkoopgesprek van HubSpot. Sessies waarbij Universidad Nacional de Colombia en Chili's Cámara Verde betrokken waren.
De "Pasta Infrastructuur"
tl;dv noemt hun microservices naar pasta. Een scan van subdomeinen onthult cappellini, carbonara, fusilli, pasta, penne, puttanesca-v0 en ravioli, allemaal onder tldv.io. Een heel Italiaans restaurant aan Express-servers.
Too Long; Didn't Score
Tijdens het verkennen van hun subdomeinen vond ik https://worldcup.tldv.io. Een "vibecoded" voorspellingsspel voor het WK 2026, gebouwd op Base44 voor medewerkers van tl;dv. Het heet "World Cup Pick'em" en hun interne team is genaamd "Too Long; Didn't Score". Schattig.
De API-entity Player heeft nul authenticatie. Een GET /api/entities/Player request retourneert elk spelersrecord zonder dat er een sessiecookie nodig is. 43 spelers, waaronder 19 medewerkers met @tldv.io-adressen, inclusief volledige namen en zakelijke e-mails.
Raphael Allstadt, mijn contactpersoon voor de melding die vage geruststellingen gaf en vervolgens stilviel, kwam op de tweede plaats met 298 punten. Zijn persoonlijke Gmail-adres stond ook in de API-respons. Speler #5 op het wereldwijde klassement is "Super Duper CEO". Ik laat jullie raden wie dat is.
Ook de entities Prediction en Fixture staan wagenwijd open. Een bedrijf dat vergaderingen van miljoenen mensen opneemt, heeft een intern leuk appje gebouwd dat hun eigen personeelsgids lekt. De ironie is al dente.
De melding (Disclosure)
Op 28 januari stuurde ik Raphael Allstadt een bericht via LinkedIn en vertelde hem dat ik een enorme kwetsbaarheid had gevonden die gebruikersgegevens lekt. Hij reageerde binnen enkele minuten: "bedankt! kun je dit rapporteren aan onze CTO? dan kijken we er direct naar." Ik stuurde de e-mail. Hij zei: "bedankt!". Ik vroeg naar een beloning. "Mijn CTO komt bij je terug," zei hij.
De CTO is nooit teruggekomen.
- 29 januari: "Je CTO heeft trouwens nog niet contact opgenomen en het is niet opgelost."
- 30 januari, Raphael: "Ik ben er zeker van dat het team het zeer snel bekijkt ❤️"
- 14 februari: "Nog geen e-mail gehad en de kwetsbaarheid werkt nog steeds." Raphael: "Hij komt terug ☺️" Ik zei dat ze misschien de kwetsbaarheid gewoon moesten oplossen in plaats van klanten bloot te stellen.
- 19 februari: "We zijn ermee bezig. Het kost wat tijd, maar wees gerust dat we het afhandelen. Voor verdere communicatie raad ik aan direct contact op te nemen met onze CTO."
De CTO die nooit reageerde. Diezelfde CTO.
- 6 maart: "Nog steeds niet opgelost." Gezien door Raphael om 17:42 uur. Geen antwoord.
- 22 juli: "Nog steeds niet opgelost..." Geen antwoord.
Hun beveiligingspagina is een trofeeënkast. SOC2-compliant. GDPR-compliant. EU AI Act-compliant. Gehost in de EU. AES-256 encryptie. Een video waarin de oprichter zich committeert aan veiligheid. Zes compliance-badges op een rij. Onderaan staat één regel: "Als u een privacy- of beveiligingsprobleem heeft ontdekt dat we moeten aanpakken, laat het ons dan altijd weten via [email protected]. Ons securityteam reageert binnen 24 uur." Ik mailde de CTO rechtstreeks. Zes maanden later: geen reactie. Hun Firestore-database heeft een betere uptime dan hun inbox.
Tijdlijn van gebeurtenissen
| Datum | Gebeurtenis |
|---|
| Laat januari 2026 | Ontdekking van de Firestore tenant isolation bypass |
| 28 januari 2026 | Contact gezocht met Raphael Allstadt (LinkedIn) en e-mail gestuurd naar CTO + Raphael |
| 29 januari 2026 | Raphael geeft vage geruststelling |
| Februari - Maart 2026 | Meerdere follow-ups. CTO reageert nooit. |
| Juli 2026 | Nog steeds niet opgelost. Nog steeds geen reactie. Buon appetito. |
Tot tl;dv
Jullie platform neemt de meest gevoelige gesprekken van mensen op. Sollicitatiegesprekken. Verkooponderhandelingen. Overheidsbriefings. Jullie gebruikers vertrouwden jullie met inhoud waarvoor zij expliciet toestemming gaven voor opname.
- Los de Firestore tenant isolation op. Er bestaan security rules in Firestore voor precies dit doel. Voor elke andere collectie (
users, chats, transcripts, clips, recordings, videos, notes, teams, organizations) doen jullie het al correct (deze geven een 403 terug). Jullie zijn alleen de meetings vergeten.
- Zet authenticatie op de World Cup-app of haal hem offline. Jullie personeelsgids is één GET-request verwijderd.
- Reageer op security-researchers. Zeker wanneer ze jullie vertellen dat elke vergadering op jullie platform opvraagbaar is door iedereen met een gratis account.
So long and thanks for all the pasta :3
tl;dv (Too Lazy; Didn't Validate): 181.874 vergaderingen wagenwijd opengeteld
Ik heb dit gemeld op 28 januari 2026. Het is nu juli 2026. Zes maanden later is de Firestore-database nog steeds wagenwijd open. De CTO heeft nooit gereageerd. Ik vermoed dat mijn e-mails te lang waren en ze niet zijn gelezen.
Wat is tl;dv?
tl;dv (Too Long; Didn't View) is een AI-platform voor het opnemen van vergaderingen. Het platform plaatst een bot in je Google Meet-, Zoom- of Teams-gesprek, neemt alles op, transcribeert de audio en genereert met behulp van AI samenvattingen. Het heeft meer dan 2 miljoen gebruikers, is gesteund door investeerders en wordt aanbevolen door een groot deel van de sales-influencers op LinkedIn.
Ze slaan verkoopgesprekken, sollicitatiegesprekken, functioneringsgesprekken en interne strategiesessies op. Het soort inhoud waarbij iemand zegt: "dit gesprek wordt opgenomen", waarna iedereen zenuwachtig lacht en vervolgens 45 minuten lang bedrijfsgeheimen deelt.
De kwetsbaarheid
Wanneer je je aanmeldt voor tl;dv, authenticeert het platform je met een JWT en ruilt deze in voor een Firebase-token via gw.tldv.io/v1/users/firebase/token. Dat token stelt je in staat om hun Firestore-database op te vragen bij projects/lmi-store/databases/(default).
De collectie 'meetings' heeft geen tenant isolation. Elke geauthenticeerde tl;dv-gebruiker kan elke vergadering van elk account op het platform opvragen. Elk vergaderingsrecord geeft je het e-mailadres van de maker, het conferentie-ID (wat een joinbare Google Meet- of Teams-kamer is), de provider, de opnamestatus en tijdstempels.
Voor vergaderingen met de status 'recording' is dat conferentie-ID een actieve, live call. Je kunt de collectie in realtime volgen, zien wanneer een vergadering start met opnemen, het ID grijpen en onuitgenodigd iemands gesprek binnenwandelen. Op elk gegeven moment staan er ongeveer 1.000 vergaderingen met de status recording in de collectie. Duizend live calls met blootgestelde conferentie-ID's. Een aanvaller met een bot zou ze allemaal gelijktijdig kunnen joinen.
Ik ben twee vergaderingen binnengestapt
Ik heb het gedaan.
Ik haalde een conferentie-ID uit Firestore en trad toe tot een live Google Meet van het Maleisische Ministerie van Onderwijs. Een dame presenteerde aan meer dan 157 deelnemers. De tl;dv-bot stond al in de deelnemerslijst. Ik zat nu in hetzelfde gesprek. Niemand had mij uitgenodigd; de Firestore-database deed dat.
Daarnaast trad ik toe tot een call waar studenten van een grote Amerikaanse universiteit een startup-app aan het bouwen waren. Er waren 21 mensen in het gesprek. Ze deelden hun scherm en lieten hun volledige project zien, discussieerden over prototypes en — ik maak een grapje niet — praatten erover dat ze client-side validatie voor .edu-e-mailadressen moesten toevoegen. Ze waren ook live op het scherm Supabase aan het instellen, waarbij ik alleen maar kon denken: "alsjeblieft, stel RLS-policies in", want de meeste mensen doen dat niet, en dan eindig je zoals tl;dv.
Ik wilde zo graag iets zeggen: "Hé, misschien willen jullie ook server-side validatie." Maar dit was een proof of concept, geen consultancy.
De schaal van het probleem
Ik heb de Firestore 'meetings'-collectie opgevraagd en zag dat er 181.874 vergaderingsrecords waren, behorend tot 84.312 unieke gebruikers over 35.003 e-maildomeinen.
- Overheidsvergaderingen uit 23 landen: waaronder Brazilië, Colombia, Peru, Oekraïne, El Salvador, de Filipijnen, Chili, Indonesië, Mexico, de Verenigde Staten, Qatar, Maleisië, Oezbekistan, Sri Lanka, Haïti, Zuid-Afrika, Jamaica, Honduras, Argentinië, Thailand, Japan, Israël en Belize. Allemaal
.gov-domeinen. Overheidsmedewerkers die gesprekken opnemen op een platform dat elke gebruiker met een gratis account in staat stelt om alles op te sommeren.
- Universiteitsvergaderingen: van Berkeley, de Universiteit van Tokio, De La Salle en Universidad Nacional de Colombia. Tientallen
.edu- en .ac-domeinen.
- Zakelijke vergaderingen: van alle overige 35.000 domeinen. Mitsui-Soko (484 vergaderingen verspreid over vier regionale kantoren), Mitsui Fudosan, HubSpot, Confluent, Mekari, AnyMind Group. Elk bedrijf dat ooit tl;dv heeft gebruikt, had hun vergaderingsmetadata in dezelfde onbeveiligde collectie staan.
De piekmaand was juli 2025 met 43.209 vergaderingen. Het drukste tijdslot: woensdag om 14:00 UTC, met 7.804 vergaderingen. Het uur van de 'hump-day standup'.
Maar wacht, er is meer
Ik wilde weten hoeveel daadwerkelijke inhoud toegankelijk was. Standaard zijn vergaderingen privé (wat betekent dat je de video niet kunt bekijken of het transcript niet kunt zien), dus ik heb 27.334 meeting-ID's gescraped en gecontroleerd welke openbaar waren. Meer dan 1.000 daarvan waren dat. Hierdoor werden 715 e-mailadressen van genodigden blootgesteld over 228 domeinen.
Enkele hoogtepunten: een Braziliaanse overheidsvergadering over natuurbehoud (PACTO Mata Atlântica) met deelnemers van WWF, The Nature Conservancy, Conservation International, WRI en de regering van de staat São Paulo. Vergaderingen van het Oekraïense Ministerie van Digitale Transformatie. Een verkoopgesprek van HubSpot. Sessies waarbij Universidad Nacional de Colombia en Chili's Cámara Verde betrokken waren.
De "Pasta Infrastructuur"
tl;dv noemt hun microservices naar pasta. Een scan van subdomeinen onthult cappellini, carbonara, fusilli, pasta, penne, puttanesca-v0 en ravioli, allemaal onder tldv.io. Een heel Italiaans restaurant aan Express-servers.
Too Long; Didn't Score
Tijdens het verkennen van hun subdomeinen vond ik https://worldcup.tldv.io. Een "vibecoded" voorspellingsspel voor het WK 2026, gebouwd op Base44 voor medewerkers van tl;dv. Het heet "World Cup Pick'em" en hun interne team is genaamd "Too Long; Didn't Score". Schattig.
De API-entity Player heeft nul authenticatie. Een GET /api/entities/Player request retourneert elk spelersrecord zonder dat er een sessiecookie nodig is. 43 spelers, waaronder 19 medewerkers met @tldv.io-adressen, inclusief volledige namen en zakelijke e-mails.
Raphael Allstadt, mijn contactpersoon voor de melding die vage geruststellingen gaf en vervolgens stilviel, kwam op de tweede plaats met 298 punten. Zijn persoonlijke Gmail-adres stond ook in de API-respons. Speler #5 op het wereldwijde klassement is "Super Duper CEO". Ik laat jullie raden wie dat is.
Ook de entities Prediction en Fixture staan wagenwijd open. Een bedrijf dat vergaderingen van miljoenen mensen opneemt, heeft een intern leuk appje gebouwd dat hun eigen personeelsgids lekt. De ironie is al dente.
De melding (Disclosure)
Op 28 januari stuurde ik Raphael Allstadt een bericht via LinkedIn en vertelde hem dat ik een enorme kwetsbaarheid had gevonden die gebruikersgegevens lekt. Hij reageerde binnen enkele minuten: "bedankt! kun je dit rapporteren aan onze CTO? dan kijken we er direct naar." Ik stuurde de e-mail. Hij zei: "bedankt!". Ik vroeg naar een beloning. "Mijn CTO komt bij je terug," zei hij.
De CTO is nooit teruggekomen.
- 29 januari: "Je CTO heeft trouwens nog niet contact opgenomen en het is niet opgelost."
- 30 januari, Raphael: "Ik ben er zeker van dat het team het zeer snel bekijkt ❤️"
- 14 februari: "Nog geen e-mail gehad en de kwetsbaarheid werkt nog steeds." Raphael: "Hij komt terug ☺️" Ik zei dat ze misschien de kwetsbaarheid gewoon moesten oplossen in plaats van klanten bloot te stellen.
- 19 februari: "We zijn ermee bezig. Het kost wat tijd, maar wees gerust dat we het afhandelen. Voor verdere communicatie raad ik aan direct contact op te nemen met onze CTO."
De CTO die nooit reageerde. Diezelfde CTO.
- 6 maart: "Nog steeds niet opgelost." Gezien door Raphael om 17:42 uur. Geen antwoord.
- 22 juli: "Nog steeds niet opgelost..." Geen antwoord.
Hun beveiligingspagina is een trofeeënkast. SOC2-compliant. GDPR-compliant. EU AI Act-compliant. Gehost in de EU. AES-256 encryptie. Een video waarin de oprichter zich committeert aan veiligheid. Zes compliance-badges op een rij. Onderaan staat één regel: "Als u een privacy- of beveiligingsprobleem heeft ontdekt dat we moeten aanpakken, laat het ons dan altijd weten via [email protected]. Ons securityteam reageert binnen 24 uur." Ik mailde de CTO rechtstreeks. Zes maanden later: geen reactie. Hun Firestore-database heeft een betere uptime dan hun inbox.
Tijdlijn van gebeurtenissen
| Datum | Gebeurtenis |
|---|
| Laat januari 2026 | Ontdekking van de Firestore tenant isolation bypass |
| 28 januari 2026 | Contact gezocht met Raphael Allstadt (LinkedIn) en e-mail gestuurd naar CTO + Raphael |
| 29 januari 2026 | Raphael geeft vage geruststelling |
| Februari - Maart 2026 | Meerdere follow-ups. CTO reageert nooit. |
| Juli 2026 | Nog steeds niet opgelost. Nog steeds geen reactie. Buon appetito. |
Tot tl;dv
Jullie platform neemt de meest gevoelige gesprekken van mensen op. Sollicitatiegesprekken. Verkooponderhandelingen. Overheidsbriefings. Jullie gebruikers vertrouwden jullie met inhoud waarvoor zij expliciet toestemming gaven voor opname.
- Los de Firestore tenant isolation op. Er bestaan security rules in Firestore voor precies dit doel. Voor elke andere collectie (
users, chats, transcripts, clips, recordings, videos, notes, teams, organizations) doen jullie het al correct (deze geven een 403 terug). Jullie zijn alleen de meetings vergeten.
- Zet authenticatie op de World Cup-app of haal hem offline. Jullie personeelsgids is één GET-request verwijderd.
- Reageer op security-researchers. Zeker wanneer ze jullie vertellen dat elke vergadering op jullie platform opvraagbaar is door iedereen met een gratis account.
So long and thanks for all the pasta :3
Groetjes,