El caso expone un problema que va mucho más allá de una aplicación: estamos entregando algunas de las conversaciones más sensibles de empresas y gobiernos a una nueva capa de intermediarios tecnológicos.
Los asistentes de reuniones basados en inteligencia artificial se están convirtiendo rápidamente en un participante habitual de las videollamadas.
Entran a una reunión de Google Meet, Zoom o Microsoft Teams, graban la conversación, generan una transcripción y luego utilizan inteligencia artificial para resumirla, identificar tareas o recuperar información.
La comodidad es evidente. El riesgo también debería empezar a serlo.
El investigador de seguridad conocido como BobDaHacker publicó el 4 de agosto una investigación sobre tl;dv, uno de estos asistentes, en la que asegura haber encontrado una falla que permitía consultar información correspondiente a 181.874 reuniones de 84.312 usuarios pertenecientes a más de 35.000 dominios de correo electrónico.
Entre ellos había empresas, universidades y organismos gubernamentales de 23 países.
Pero el problema más grave no era simplemente saber que esas reuniones existían.
En determinadas circunstancias, la información expuesta permitía obtener el identificador de una videollamada que estaba ocurriendo en ese preciso momento. Y ese identificador podía convertirse en la puerta de entrada a la reunión.
Una falla simple con consecuencias enormes
El problema técnico resulta especialmente interesante porque no requería romper cifrado, comprometer contraseñas ni explotar una sofisticada vulnerabilidad de ejecución remota.
Según la investigación, tl;dv utilizaba Firebase y su base de datos Firestore para almacenar información relacionada con las reuniones.
Cuando un usuario se autenticaba normalmente en la plataforma obtenía un token que le permitía interactuar con esa infraestructura.
El problema estaba en algo mucho más básico: la colección de reuniones no aislaba correctamente los datos de cada cliente.
En una aplicación SaaS multiusuario, un usuario de la empresa A debería poder consultar únicamente los objetos que le pertenecen a A. Es lo que habitualmente se conoce como tenant isolation.
En este caso, según el investigador, un usuario autenticado podía consultar registros correspondientes a reuniones de otros clientes.
No hacía falta ser administrador. Ni comprometer una cuenta privilegiada.
Alcanzaba con tener una cuenta normal en el servicio.
Los registros accesibles incluían información como el correo electrónico del creador, proveedor utilizado para la videollamada, identificador de conferencia, timestamps y estado de la reunión.
Ese último dato era particularmente problemático.
Si el estado indicaba que la reunión estaba siendo grabada, significaba que la llamada estaba ocurriendo en ese momento. El investigador asegura que podía observar alrededor de 1.000 reuniones activas simultáneamente y obtener sus identificadores.
Para demostrar el impacto, utilizó uno de ellos para ingresar a una reunión del Ministerio de Educación de Malasia en la que participaban más de 150 personas. También accedió a una llamada de estudiantes de una universidad estadounidense que estaban desarrollando una aplicación y compartiendo información sobre el proyecto.
No había recibido ninguna invitación.
La información necesaria para encontrar las reuniones provenía de la propia infraestructura del asistente que estaba allí para grabarlas.
181.874 reuniones no significan 181.874 grabaciones públicas
Hay una distinción importante para dimensionar correctamente el incidente.
La vulnerabilidad no significaba que cualquier usuario pudiera descargar automáticamente las grabaciones, transcripciones y resúmenes privados de las 181.874 reuniones.
El investigador encontró que otras colecciones relacionadas con usuarios, transcripciones, grabaciones, videos, notas y organizaciones sí aplicaban controles que rechazaban esos accesos.
Lo que estaba masivamente expuesto era la información asociada a las reuniones.
A partir de allí apareció un segundo problema.
El investigador tomó una muestra de 27.334 identificadores de reuniones y comprobó cuáles tenían contenido configurado como públicamente accesible. Encontró más de 1.000.
En esos casos podían aparecer transcripciones, notas u otro contenido porque los propietarios habían habilitado una modalidad de compartir mediante enlace.
Esto introduce otra discusión de seguridad: un recurso configurado como “cualquiera con el enlace” no es realmente privado. El enlace funciona, en la práctica, como una credencial.
El problema se vuelve considerablemente mayor cuando otra vulnerabilidad permite enumerar esos identificadores.
Qué podía hacer un atacante
El impacto potencial no se limita a una filtración tradicional de datos.
Conocer qué organizaciones mantienen reuniones, quién las crea, cuándo ocurren y qué plataforma utilizan ya constituye información útil para inteligencia y reconocimiento.
Si además pueden identificarse llamadas activas, aparece la posibilidad de intentar ingresar en ellas.
En organizaciones empresariales podría significar acceso a negociaciones comerciales, discusiones sobre productos todavía no publicados, incidentes de seguridad, resultados financieros, entrevistas laborales, problemas internos o información de clientes.
En organismos públicos, las consecuencias pueden ser todavía más delicadas.
Una reunión gubernamental puede revelar procesos administrativos, proyectos de infraestructura, decisiones políticas, relaciones internacionales o discusiones vinculadas con seguridad.
Incluso cuando un atacante no logra ingresar, los metadatos pueden servir para construir perfiles de organizaciones y personas, identificar relaciones entre ellas o preparar campañas de ingeniería social mucho más convincentes.
Una aparentemente pequeña falla de autorización termina convirtiéndose así en una herramienta potencial de inteligencia.
El problema no es solamente tl;dv
Sería sencillo interpretar este episodio como una vulnerabilidad puntual de una empresa y pasar a la siguiente noticia.
Pero hacerlo perdería probablemente la parte más importante del caso.
tl;dv pertenece a una categoría cada vez más grande de asistentes de reuniones basados en inteligencia artificial. Existen numerosas plataformas que ofrecen funciones similares y utilizan diferentes arquitecturas, integraciones y mecanismos de almacenamiento.
Que esta vulnerabilidad haya sido encontrada en tl;dv no significa que las demás aplicaciones tengan el mismo problema.
Pero tampoco existe ninguna razón técnica para asumir automáticamente que no puedan existir vulnerabilidades equivalentes.
Un asistente de reuniones ocupa una posición especialmente sensible dentro de una organización: participa de conversaciones, procesa audio, genera transcripciones, almacena información y, en muchos casos, se integra con calendarios, plataformas de videoconferencia, CRM y otras herramientas corporativas.
Es decir, centraliza exactamente la clase de información que un atacante, un competidor o un servicio de inteligencia querría obtener.
Y cuanto más útiles se vuelven estas herramientas, mayor es la cantidad de información que concentramos en ellas.
Cumplimiento no significa ausencia de vulnerabilidades
El caso también deja otra lección incómoda.
tl;dv presenta públicamente diferentes controles y certificaciones de seguridad, incluyendo SOC 2 Type II, cumplimiento con GDPR, cifrado y prácticas de desarrollo seguro.
Nada de eso impidió que apareciera una vulnerabilidad conceptualmente sencilla de autorización.
No existe necesariamente una contradicción.
Una certificación evalúa determinados controles y procesos dentro de un alcance concreto. No garantiza que una aplicación esté libre de vulnerabilidades.
Pero desde el punto de vista de quien contrata tecnología, la diferencia es fundamental.
Ver una colección de certificaciones en la página de seguridad de un proveedor puede generar una falsa sensación de tranquilidad si se reemplaza el análisis técnico por una lista de sellos.
Una organización puede estar certificada y seguir teniendo errores de autorización.
Puede utilizar cifrado AES-256 y exponer datos porque una regla de acceso está mal configurada.
Puede cumplir formalmente un estándar y aun así cometer un error básico de desarrollo seguro.
La seguridad real aparece en los detalles.
Cuando la IA entra a la reunión, también entra otro proveedor
La expansión de estos asistentes plantea además una pregunta que muchas organizaciones todavía no parecen haberse hecho: ¿quién está autorizado a escuchar nuestras reuniones?
Durante años, una videollamada empresarial podía depender principalmente de Microsoft, Google o Zoom.
Ahora puede existir otra empresa conectada a esa conversación, almacenando una copia, generando una transcripción y procesándola mediante diferentes servicios de inteligencia artificial.
Cada nueva integración amplía la cadena de confianza.
Y cada eslabón adicional incorpora infraestructura, empleados, configuraciones, APIs, bases de datos y potenciales vulnerabilidades.
La discusión sobre soberanía digital suele concentrarse en dónde se almacenan los datos o qué país controla determinado proveedor. Pero existe una dimensión más cotidiana: decidir cuántos intermediarios tecnológicos necesitamos para mantener una conversación.
Una reunión interna puede contener más inteligencia sobre una organización que cientos de documentos públicos.
Por eso los asistentes de IA no deberían tratarse simplemente como una herramienta de productividad que cada empleado instala porque ahorra unos minutos escribiendo notas.
Son sistemas que procesan información corporativa sensible y deberían evaluarse como tales.
El incidente de tl;dv es un caso concreto.
La pregunta relevante para empresas, universidades y gobiernos es bastante más amplia: ¿sabemos realmente cuántas aplicaciones están escuchando nuestras reuniones, qué información conservan y qué ocurriría si una sola de ellas deja una puerta abierta?