Uma falha de configuração no serviço de assistente de reuniões com inteligência artificial tl;dv terá permitido que qualquer utilizador autenticado consultasse informação sobre reuniões de outros clientes — incluindo chamadas ao vivo de organismos governamentais, universidades e grandes empresas. Segundo a investigação divulgada pelo investigador conhecido por BobDaHacker e o relato da Dark Reading, o problema residia numa base de dados Cloud Firestore do Google Firebase sem o isolamento correto entre clientes, expondo metadados de reuniões e, em alguns casos, transcrições e endereços de email. O investigador afirma ainda ter conseguido entrar em muitas dessas chamadas fazendo-se passar por um bot de transcrição.
Resposta rápida: Uma configuração deficiente do Firestore no serviço tl;dv terá permitido a qualquer utilizador autenticado enumerar reuniões de outros clientes e, em muitos casos, entrar em chamadas ao vivo. Se a sua organização usa “AI notetakers”, exija aprovação manual de bots, ative salas de espera e defina as reuniões como privadas por predefinição. Reveja também a exposição de transcrições com partilha pública ativa.
O que é o tl;dv e o que terá corrido mal
O tl;dv (de “Too Long; Didn’t View”) é um assistente de reuniões que se junta automaticamente a chamadas em Zoom, Google Meet e Microsoft Teams para gravar, transcrever e resumir o conteúdo. O seu site afirma ser usado por mais de dois milhões de utilizadores em todo o mundo, incluindo em empresas de marca como Salesforce, Forbes e Cloudflare. Segundo a Dark Reading, o tl;dv é usado em dezenas de agências governamentais, além de grandes universidades e organizações, um pouco por todo o mundo.
O cerne do problema é uma questão clássica de isolamento entre clientes (“tenant isolation”). Quando um utilizador se autenticava no tl;dv, a plataforma emitia uma credencial de sessão própria e trocava-a por um token do Firebase, e esse token dava ao cliente acesso ao back end Firestore do tl;dv. De acordo com a investigação, a maioria das coleções aplicava corretamente as fronteiras de conta ou organização, bloqueando o acesso a utilizadores, transcrições, chats, gravações, notas e dados de equipa de outros clientes — mas a coleção de reuniões era a exceção, permitindo que qualquer utilizador autenticado listasse documentos dessa coleção em todos os clientes.
Esses documentos revelavam metadados operacionais sensíveis. Um documento de reunião expunha informação suficiente para identificar quem criou a chamada, que serviço de conferência a alojava, se a gravação estava ativa e qual a sala de conferência envolvida, e o investigador indicou que cerca de 1.000 registos podiam estar marcados como a gravar num dado momento, transformando a coleção numa espécie de diretório quase em tempo real das chamadas em curso. Entre os dados figuravam o email do criador da reunião, o fornecedor de conferência, marcas temporais, o estado de gravação e um identificador de conferência utilizável para chegar à sala subjacente de Google Meet ou Microsoft Teams.
Importa sublinhar um ponto relevante: o problema não exigia uma conta de administrador roubada, malware, nem uma falha no próprio Google Cloud. Tratava-se de uma regra de segurança em falta na configuração do serviço. Como resume o investigador, quando se constroem aplicações com Firebase, “as regras de segurança do Firestore são a primeira coisa que a Google diz para configurar”.
Da consulta de metadados à entrada em chamadas ao vivo
Conhecer os metadados de uma reunião não dá, por si só, acesso à sala. Mas o investigador terá encontrado formas de contornar essa barreira. Obter a informação da reunião não concede acesso à reunião, mas nos testes BobDaHacker encontrou uma forma de entrar na maioria das reuniões dos utilizadores do tl;dv, na maioria das vezes; algumas, como uma grande chamada de Google Meet alojada pelo instituto de formação de gestão do Ministério da Educação da Malásia, estavam abertas ao público. Para as chamadas privadas, o investigador diz que fazer-se passar por um assistente de IA como o tl;dv e depois pedir para entrar na reunião costumava resultar, tendo sido admitido em reuniões cerca de 80% das vezes.
A escala dos dados no back end era considerável. Quando não estava a entrar ativamente em chamadas ao vivo, BobDaHacker aprofundou o back end da aplicação, onde encontrou mais de 180.000 registos de chamadas concluídas pertencentes a mais de 80.000 utilizadores. Quanto às transcrições realmente expostas na Internet, o volume foi mais contido e ligado às definições de privacidade dos utilizadores. Segundo o investigador, de cerca de 70.000 reuniões verificadas através da REST API, só cerca de 1.000 tinham partilha pública ativa — esses utilizadores tiveram as transcrições e os emails dos convidados expostos, enquanto as restantes 69.000 ficaram protegidas apenas pelas suas definições de privacidade.
Entre as reuniões afetadas, a Dark Reading refere casos sensíveis. Numa amostra de mais de 27.000 identificadores de reunião analisados em busca de dados expostos publicamente, mais de 1.000 deixavam à vista emails de convidados e transcrições, incluindo uma reunião no Ministério da Transformação Digital da Ucrânia e uma reunião entre o governo estadual de São Paulo, no Brasil, e vários grupos de conservação.
Uma segunda exposição: dados de funcionários
Além da falha na coleção de reuniões, a investigação identificou um segundo problema, de natureza semelhante mas separado. Durante a pesquisa de subdomínios, BobDaHacker encontrou também uma aplicação interna de previsões do Campeonato do Mundo usada por funcionários do tl;dv, e reportou que uma API de dados de jogadores sem autenticação devolvia 43 registos, incluindo nomes, emails corporativos e alguns emails pessoais. Há uma pequena divergência entre fontes quanto ao número exato: a Dark Reading indicou 42 funcionários ou jogadores expostos, criando uma pequena discrepância numérica entre os dois relatos, mas ambas as fontes concordam que o endpoint não tinha autenticação e divulgava informação de funcionários.
Divulgação sem resposta e estado da falha
O processo de divulgação responsável parece ter falhado. Embora o tl;dv prometa publicamente uma resposta em 24 horas da sua equipa de segurança, o investigador publicou uma cronologia com mensagens a começar a 28 de janeiro e a prolongar-se por julho, sem resposta do responsável tecnológico e sem correção confirmada; a Dark Reading relatou igualmente não ter obtido resposta antes da publicação. A falha continuava ativa à data de publicação do artigo.
| Data / momento | Evento |
|---|---|
| Finais de janeiro de 2026 | O investigador descobre que qualquer utilizador do tl;dv pode aceder ao back end Firebase e consultar informação de reuniões de outros clientes. |
| 28 de janeiro em diante | Início das tentativas de contacto com o tl;dv, prolongadas por vários meses sem resposta confirmada. |
| Agosto de 2026 | Publicação da investigação e do artigo da Dark Reading; a falha permanecia ativa à data. |
Como reduzir o risco de “AI notetakers”
Este caso ilustra um problema mais vasto: os assistentes de IA proliferam nas reuniões com permissões elevadas e pouca supervisão. O primeiro conselho prático é tratar o bot como aquilo que é — um participante. O investigador recomenda ter consciência de que o bot é um participante e que ver um “AI notetaker” numa chamada para a qual não foi convidado é um sinal de alerta; num caso citado, numa reunião governamental da Malásia, o bot do tl;dv estava na lista de participantes e 157 pessoas viram-no sem que ninguém o questionasse.
Do lado das organizações, várias medidas ajudam a fechar esta janela de risco:
- Desativar entradas automáticas de bots e exigir aprovação manual e explícita do anfitrião para qualquer assistente de gravação ou de notas que tente entrar numa sessão.
- Aplicar definições de privacidade estritas, tornando privadas por predefinição as videoconferências internas e externas, com códigos de acesso ou salas de espera, e desativando a partilha pública de transcrições.
- Realizar avaliações de risco de fornecedores, verificando se as ferramentas de IA de produtividade garantem isolamento de dados robusto e cifragem adequada.
- Configurar sempre as definições de privacidade de forma proporcional à sensibilidade da reunião. Como resume o investigador: “predefinir para privado”.
Porque é que isto importa em Portugal
Para organizações em Portugal, o incidente toca em vários planos regulatórios. Como o tl;dv processa transcrições e emails de participantes, qualquer exposição indevida de dados pessoais cai no âmbito do RGPD, que impõe deveres de segurança do tratamento e, em caso de violação de dados suscetível de risco, obrigações de notificação à CNPD. Convém recordar que a responsabilidade pelo consentimento e pela conformidade recai frequentemente sobre a organização que adota a ferramenta, e não apenas sobre o fornecedor.
No plano da cibersegurança, entidades abrangidas pelo novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a NIS2) devem gerir os riscos da cadeia de fornecimento e das ferramentas de terceiros, incluindo assistentes de IA com acesso a comunicações internas. O CNCS e o CERT.PT recomendam, de forma consistente, princípios de “privacidade por predefinição”, controlo de acessos e avaliação de fornecedores — exatamente o tipo de práticas cuja ausência esteve na origem deste caso. Para cidadãos e PME, a lição é simples: um assistente de IA que “só” tira notas pode, na prática, deter acesso privilegiado a conversas confidenciais, e merece o mesmo escrutínio de segurança que qualquer outra aplicação com permissões elevadas.
Perguntas frequentes
A falha do tl;dv já foi corrigida?
À data de publicação da investigação e do artigo da Dark Reading, em agosto de 2026, não havia correção confirmada e a exposição permanecia ativa. O investigador afirma ter tentado reportar o problema desde janeiro sem obter resposta. Recomenda-se seguir os avisos oficiais e reforçar entretanto as definições de privacidade das reuniões.
Que dados terão ficado expostos?
Segundo a investigação, qualquer utilizador autenticado podia consultar metadados de reuniões de outros clientes — email do criador, fornecedor de conferência, marcas temporais, estado de gravação e um identificador da sala. Numa fração das reuniões, com partilha pública ativa, ficaram também expostas transcrições e emails de convidados. Um segundo problema expôs dados de funcionários numa aplicação interna sem autenticação.
Como posso proteger as reuniões da minha organização?
Desative a entrada automática de bots de transcrição, exija aprovação manual do anfitrião, use salas de espera e códigos de acesso, e defina as reuniões como privadas por predefinição. Trate qualquer “AI notetaker” não convidado como um sinal de alerta e faça avaliações de risco aos fornecedores de ferramentas de IA antes de os integrar.
Este incidente tem implicações no RGPD?
Sim. Ao processar transcrições e emails, a ferramenta trata dados pessoais, pelo que exposições indevidas podem configurar violações de dados sujeitas às obrigações do RGPD, incluindo notificação à CNPD quando aplicável. A responsabilidade de garantir conformidade recai também sobre a organização que adota a ferramenta, e não só sobre o fornecedor.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela investigação de BobDaHacker e pelo relato da Dark Reading, bem como em análises técnicas de terceiros.