Au début de cette année, un test d'intrusion de routine mené par un prestataire indépendant a mis en évidence une vulnérabilité affectant l'accès à certaines métadonnées de réunions. Au cours de cette même période, un chercheur en sécurité indépendant nous a également contactés pour nous faire part de ses conclusions concernant ce même vecteur d'attaque. Sur la base de ces rapports, nous avons mis en place une mesure corrective, qui a ensuite été officiellement validée par notre cabinet externe spécialisé dans les tests d'intrusion, confirmant ainsi que la vulnérabilité avait été corrigée avec succès.

Récemment, cependant, nous avons pris connaissance d’une nouvelle voie d’exploitation, récemment découverte, liée à la même partie de notre pile technologique. Contrairement aux allégations selon lesquelles une seule vulnérabilité serait restée non corrigée pendant six mois, notre prestataire indépendant chargé des tests d’intrusion a officiellement attesté qu’il s’agissait de deux vecteurs distincts. La vulnérabilité initiale avait été entièrement corrigée et validée il y a plusieurs mois. Cet incident récent concernait une méthode d’attaque secondaire jusqu’alors inconnue.

Conformément à notre politique de sécurité habituelle, qui consiste à agir immédiatement dès qu'un problème est identifié, nous avons déployé un deuxième correctif et complètement colmaté cette nouvelle faille dans les 24 heures suivant sa découverte.

Étant donné que le dénominateur commun entre ces deux incidents distincts était Firebase, nous prenons la décision supplémentaire de le supprimer immédiatement et définitivement de notre pile technologique afin d'éliminer définitivement le risque de vulnérabilités similaires à l'avenir.

Par souci de transparence totale, une attestation signée par notre prestataire chargé des tests d'intrusion, confirmant le respect de nos procédures et la mise en œuvre immédiate de mesures correctives lors de ces deux incidents, est disponible sur simple demande pour nos clients et prospects à l'adresse [email protected].


Ce qui était accessible et ce qui ne l'était pas

Les données sensibles se limitaient strictement aux métadonnées : identifiants de réunion, identifiants de conférence (les liens utilisés pour rejoindre les appels sur Google Meet ou Microsoft Teams ) ainsi que les adresses e-mail et les domaines des participants.

Il est essentiel de souligner qu’aucun mot de passe, enregistrement, transcription, note générée par l’IA ni donnée relative aux comptes et à la facturation n’était accessible. Aucune de ces informations n’était accessible via cette vulnérabilité, et elles ne sont d’ailleurs pas stockées dans cette partie de notre infrastructure. Bien que nous traitions toutes les informations personnelles avec le plus grand sérieux, les données exposées ne comprenaient pas de données personnelles hautement sensibles ni le contenu réel d’aucune conversation.

En termes d'impact concret, on distingue deux axes distincts, dont la gravité varie :

Tout d'abord, en utilisant les identifiants de réunion rendus publics, une personne pourrait consulter la transcription ou les notes générées par l'IA uniquement pour les réunions que les utilisateurs ont explicitement choisi de rendre publiques. Le partage public sur tl;dv est un paramètre optionnel, désactivé par défaut, qui doit être activé délibérément par un client souhaitant qu'une réunion soit visible en dehors de son équipe.

Ces utilisateurs ayant délibérément activé le partage public des liens, ce contenu était, de par sa conception même, déjà accessible à toute personne disposant du lien. Même pour ces réunions publiques, le contenu n’apparaissait pas dans les résultats de navigation ou de recherche habituels de tl;dv: pour y accéder, il fallait qu’un pirate informatique expérimenté effectue des manipulations spécifiques.

Deuxièmement, dans quelques cas isolés, une personne a pu obtenir les URL des réunions et accéder aux salles en direct en utilisant un pseudonyme inconnu et en étant admise manuellement par l'organisateur. Dans le cadre de notre correction immédiate, nous avons entièrement sécurisé ce point d'accès afin de garantir que les URL des réunions ne puissent plus être obtenues de cette manière.


Le contexte général

Les paramètres de partage public des produits d'IA et SaaS ont mis en évidence des conclusions similaires ces derniers mois. Anthropic Nous avons identifié des artefacts publics exposés sur Claude et son écosystème MCP via la recherche Google. Lovable et Zoom ont tous deux traité des cas où les paramètres publics configurés par les utilisateurs ont entraîné une visibilité plus large que ce que ces derniers avaient prévu. Il s’agit d’une catégorie de problèmes d’expérience utilisateur (UX) à laquelle le secteur accorde de plus en plus d’attention.

Le point commun : le terme « public » peut revêtir différentes significations selon les utilisateurs, et l'expérience utilisateur liée au choix de la visibilité publique doit présenter clairement les conséquences de ce choix. Nous réexaminons actuellement comment mieux mettre en avant ces choix dans notre propre produit, et nous prévoyons de déployer ces modifications prochainement.


Nos projets pour l'avenir

La sécurité n'est pas un objectif figé pour aucune plateforme. Nous continuons à investir dans des tests indépendants, dans la correction rapide de tout problème détecté et dans l'amélioration constante de nos méthodes de protection des données de nos clients.

Nous reconnaissons également le rôle que joue l’ensemble de la communauté de la cybersécurité dans cette démarche. Le chercheur qui a identifié ce vecteur alternatif est un expert hautement qualifié, qui a déjà fait ses preuves en matière de détection de vulnérabilités au sein de grandes organisations. L’examen minutieux mené par des talents de premier plan n’est pas seulement une étape inévitable du développement d’une plateforme logicielle ; c’est une force nécessaire qui pousse nos défenses à devenir plus solides et plus résilientes.

Sur le plan personnel, je reconnais que j’aurais dû tenir le chercheur informé après sa première prise de contact en début d’année, et j’assume l’entière responsabilité de ce manque de communication. À l’avenir, nous allons affiner nos processus de signalement et de traitement des vulnérabilités afin de garantir que tous les rapports de sécurité externes bénéficient de l’attention immédiate, du respect et d’un suivi clair qu’ils méritent.


Nous contacter

Pour toute question relative à votre compte, veuillez envoyer un e-mail à [email protected].


Allan Bettarel, directeur technique d'
, tl;dv

P.S. Oui, notre équipe a également développé une petite application interne de pronostics pour la Coupe du monde au début de l'année, programmée à la va-vite par des collègues non-ingénieurs pour le plaisir et hébergée sur un sous-domaine. Elle n'était reliée à aucune donnée client ni à aucun système de production, et nous en avons depuis renforcé les mesures d'accès.