Cualquier usuario de tl;dv podía ver las reuniones de los demás: 181.874 registros y mil llamadas en directo

Si en tu empresa alguien instaló un transcriptor de IA para que tome notas en las reuniones, hay una probabilidad razonable de que sea tl;dv: es uno de los más usados, se cuela como un invitado más en tus Google Meet y tus Teams, graba, transcribe y te manda el resumen. Durante meses, su base de datos no separaba a un cliente de otro. Cualquier persona con una cuenta gratuita podía consultar los registros de reuniones de todos los demás.

Las cifras las publicó el 4 de agosto la investigadora de seguridad conocida como bobdahacker en su propio blog: 181.874 registros de reuniones pertenecientes a 84.312 usuarios de 35.003 dominios de correo distintos. Entre ellos, reuniones de administraciones públicas de 23 países, universidades y miles de empresas. Ese mismo día, Dark Reading publicó su cobertura y aseguró que el agujero seguía abierto en el momento de publicar, seis meses después de que se avisara a la empresa.

Lo más grave no son los registros históricos, sino un detalle de diseño: cada registro incluía el identificador de la videollamada y su estado de grabación. En cualquier momento había alrededor de mil reuniones marcadas como recording. Es decir, llamadas que estaban ocurriendo en ese instante, con el código para entrar en ellas a la vista.

Qué contenía exactamente cada registro

El fallo no era exótico. tl;dv guardaba las reuniones en Firestore, la base de datos de Google, y la colección de reuniones no comprobaba a qué cliente pertenecía cada documento. Cualquier usuario autenticado —basta registrarse— podía listar la colección entera. En seguridad esto se llama broken object level authorization: el servidor no verifica que quien pide un recurso tenga derecho sobre él. Es el primer riesgo del top 10 de APIs de OWASP y el error que se supone que no debes cometer montando un servicio multicliente.

Cada documento traía el correo del creador de la reunión, el proveedor de videoconferencia, marcas de tiempo, el estado de la grabación y el identificador de la sala. Con ese identificador se llega a la sala real de Google Meet o de Teams. La investigadora lo demostró entrando en dos llamadas ajenas: una presentación del Ministerio de Educación de Malasia con más de 157 asistentes y una reunión de veintiún estudiantes de una universidad estadounidense enseñando el prototipo de su aplicación. En una videollamada con decenas de participantes nadie mira quién acaba de entrar; y si parece el bot de notas de siempre, menos todavía.

Hay un segundo hallazgo que conviene separar bien, porque es donde después vino la discusión. Tras extraer 27.334 identificadores, la investigadora comprobó que más de mil reuniones estaban marcadas como públicas por sus propios dueños, con transcripción accesible y 715 correos de invitados en 228 dominios. Esas transcripciones no salían del fallo de la base de datos, sino de enlaces que alguien había hecho públicos sin entender qué significaba "público"; el fallo solo servía para encontrarlas todas de golpe. Y de propina, un juego de predicciones del Mundial alojado en un subdominio de la empresa devolvía sin autenticación una lista de 43 jugadores, 19 de ellos empleados con nombre y correo corporativo.

Seis meses de avisos sin respuesta

La cronología es la parte que peor sienta. El 28 de enero de 2026 la investigadora contactó por LinkedIn con Raphael Allstadt, cofundador y consejero delegado, y escribió al director técnico. Hubo seguimientos en febrero, marzo, junio y julio. El último apunte es del 22 de julio: "sigue sin arreglar", sin respuesta. Cuando Dark Reading pidió comentarios antes de publicar, tampoco obtuvo contestación.

Es el patrón clásico del que se quejan los investigadores de seguridad: mientras nadie publica, no pasa nada; en cuanto sale en prensa, se arregla en horas. Aquí ocurrió literalmente eso.

Qué dice tl;dv y en qué estado está el fallo hoy

Esta es la parte que el resto de coberturas todavía no recoge, así que la detallo. El 5 de agosto, un día después de la publicación, tl;dv publicó una respuesta oficial firmada por su director técnico, Allan Bettarel. El texto se actualizó de nuevo el 7 de agosto. Sus afirmaciones, resumidas:

• Sostiene que hubo dos vectores distintos sobre el mismo componente. El primero se detectó a principios de año, entre una auditoría de su proveedor de pruebas de intrusión (Abicom) y el aviso de la investigadora, y se corrigió con validación de esa misma auditora.
• El segundo, una "vía de explotación alternativa recién descubierta", lo cerró "en menos de 24 horas desde su descubrimiento".
• Como el denominador común de ambos incidentes era Firebase, dice que va a retirar Firebase de su arquitectura por completo.
• Acota los datos afectados a metadatos: identificadores de reunión, identificadores de sala y correos y dominios de los participantes. Afirma que no fueron accesibles "contraseñas, grabaciones, transcripciones, notas generadas por IA ni datos de cuenta o facturación".
• Y admite el fallo de comunicación: reconoce que debería haber mantenido informada a la investigadora tras su primer aviso de principios de año y asume "toda la responsabilidad por esa laguna de comunicación".

El estado a 11 de agosto de 2026, dicho con precisión: la empresa afirma que el fallo está cerrado; no hay verificación independiente publicada. La investigadora no ha actualizado su artículo original, que sigue fechado el 4 de agosto con el problema abierto. Y en el hilo de Lobsters sobre el caso varios lectores documentaron que la respuesta de la empresa se reescribió varias veces: pasó de decir que el problema "se resolvió poco después" a que "resurgió brevemente" y de ahí a "una vía de explotación alternativa recién descubierta". Cuando una nota oficial cambia tres veces de versión en dos días, lo prudente es tomarla por lo que es: la palabra de la empresa, no un hecho comprobado.

Hay además una discrepancia que no conviene tapar. La empresa dice que las transcripciones nunca fueron accesibles; la investigadora publicó más de mil con transcripción visible. Ambas cosas encajan si venían de enlaces públicos creados por los propios usuarios, que es la lectura más razonable. Pero para quien tuviera una de esas reuniones, el resultado es el mismo.

Qué mirar antes de meter un notetaker de IA en tus reuniones

Los transcriptores de IA son de las herramientas que más rápido se han colado en las empresas, casi siempre sin pasar por nadie: alguien los instala, autoriza el acceso al calendario y a partir de ahí el bot entra solo. Cinco cosas que sí merece la pena comprobar antes.

Qué permisos pide, y cuáles puedes quitarle. La mayoría piden acceso al calendario para entrar solos en todo: también en la reunión con tu abogado, en la de despidos y en la de la due diligence. Si permite lista blanca —que solo grabe cuando se lo pides—, actívala. Un notetaker con permiso general es un micrófono abierto en toda la empresa.

Dónde se guardan las transcripciones y cuánto tiempo. Pregunta por región de almacenamiento, plazo de conservación y, sobre todo, si tus grabaciones se usan para entrenar modelos. Y qué pasa cuando te das de baja: sin borrado verificable, tus reuniones se quedan ahí.

Cómo separan a un cliente de otro, y quién lo ha comprobado. Es la pregunta exacta de esta noticia. No sirve el "ciframos los datos": aquí no falló el cifrado, falló que la base de datos no comprobaba de quién era cada fila. Pide el informe de la última prueba de intrusión y pregunta si cubre el aislamiento entre clientes. Un sello en la web no lo garantiza: aquí había auditora contratada y el agujero estuvo abierto meses.

Qué obliga el RGPD cuando grabas a otros. No prohíbe grabar, pero exige base jurídica e información previa: hay que avisar antes de empezar, no dar por hecho el consentimiento porque nadie proteste. Si en la llamada hay clientes, candidatos o proveedores, estás tratando datos de terceros que no han elegido tu herramienta. Y el proveedor es un encargado del tratamiento: necesitas contrato del artículo 28 y saber a qué subencargados manda el audio. Lo he desarrollado en la guía sobre RGPD e inteligencia artificial en la empresa.

Qué significa "compartir" en esa herramienta. El caso de las mil reuniones públicas no fue un fallo técnico: fue gente pulsando "compartir" sin saber que el enlace era accesible para cualquiera con la URL. Antes de desplegar nada, mira qué genera exactamente el botón de compartir y explícalo a quien vaya a usarlo.

Y una alternativa que en muchos equipos resuelve el problema entero: no meter un bot en la llamada. Grabar en local y transcribir después, o generar el acta de la reunión con IA a partir de un audio que no sale de tu equipo, elimina de golpe el proveedor intermedio, el identificador de sala expuesto y el invitado que nadie invitó.

Mi lectura

Lo que más me inquieta no es el fallo: unas reglas de Firestore mal puestas las ha tenido medio sector. Es el eslabón que se saltó todo el mundo. Una herramienta con acceso a las conversaciones internas de 84.312 personas se instala sin revisión, en muchos casos sin contrato de encargado, y sin que nadie pregunte cómo separa a un cliente de otro. Cuando eso falla no se filtra una contraseña que puedes cambiar: se filtra quién habló con quién, cuándo y por dónde entrar a escucharlo.

Cada bot que metes en una llamada es un sitio más donde tu conversación puede acabar en manos ajenas. Merece la pena que alguien en tu empresa se haga esa pregunta antes de la próxima instalación, y no seis meses después de que la haga un investigador por ti.