Un site web pouvait créer plusieurs bases IndexedDB, observer l’ordre dans lequel elles étaient retournées par indexedDB.databases(), et extraire de cet ordre un identifiant unique, stable et déterministe lié au processus du navigateur plutôt qu’à une origine. Résultat : deux sites sans rapport pouvaient vérifier de façon indépendante s’ils avaient affaire au même utilisateur, contournant totalement les protections de cloisonnement de Tor Browser.
La faille a été corrigée dans Firefox 150 et ESR 140.10.0. Elle est référencée sous CVE-2026-6770 / Mozilla Bug 2024220.
La promesse fondamentale de Tor Browser repose sur deux garanties : que des sites non liés ne peuvent pas déduire qu’ils interagissent avec le même navigateur, et que la fin d’une session efface vraiment l’état associé. Cette faille cassait les deux.
Ce n’est pas anodin. Les journalistes, activistes, avocats et toute personne qui compte sur Tor pour compartimenter des identités numériques distinctes ont été exposés à une désanonymisation silencieuse, sans cookies, sans localStorage, sans aucun mécanisme de tracking explicite. Juste l’ordre interne de retour d’une API censée être anodine. En mode Navigation Privée Firefox, l’identifiant persistait même après fermeture de toutes les fenêtres privées, tant que le processus Firefox restait actif. Dans Tor Browser, il survivait à la fonctionnalité « New Identity », celle qui est censée réinitialiser complètement les circuits Tor, les cookies et l’historique. En pratique, le reset ne servait à rien pour cet identifiant-là.
Qu’est-ce qu’IndexedDB, et pourquoi son API de listing est-elle problématique ?
IndexedDB est l’API navigateur standard pour stocker des données structurées côté client. Les applications web s’en servent pour le support hors-ligne, la mise en cache de session, ou la gestion d’état local. Chaque origine peut y créer plusieurs bases nommées.
L’appel indexedDB.databases() renvoie la liste des bases visibles pour l’origine courante. Fonctionnellement, c’est utile pour déboguer l’état du stockage ou vérifier quelles bases existent déjà. Rien d’alarmant en surface.
Le problème, c’est l’ordre de retour. Dans une implémentation normale, cet ordre devrait être canonique ou sans signification identifiante. Dans Firefox, il reflétait l’état interne des structures de stockage du processus ce qui le rendait unique, stable et observable depuis n’importe quelle origine pendant toute la durée de vie du processus.
L’origine du problème se trouve dans dom/indexedDB/ActorsParent.cpp.
En mode Navigation Privée, Firefox ne stocke pas les bases IndexedDB sous leur nom réel. À la place, il fait correspondre chaque nom à un identifiant UUID via une table de hachage globale :
using StorageDatabaseNameHashtable = nsTHashMap<nsString, nsString>;
StaticAutoPtr<StorageDatabaseNameHashtable> gStorageDatabaseNameHashtable;Ce mapping est effectué dans GetDatabaseFilenameBase() lors de OpenDatabaseOp::DoDatabaseWork(). Quand aIsPrivate est vrai, le nom fourni par le site est remplacé par un UUID généré et stocké dans cette table globale.
Or cette table est partagée entre toutes les origines pour toute la durée de vie du processus. Les UUIDs ne sont pas aléatoires à chaque requête, ils sont déterministes pour une instance de processus donnée. Résultat : l’ordre dans lequel indexedDB.databases() retourne les résultats encode l’état interne du processus, et cet état est identique quel que soit le site qui le consulte.
Si un site contrôle N noms de bases, le nombre de permutations observables est N!, soit une entropie théorique de log₂(N!). Avec un nombre modeste de bases, la valeur identifiante est suffisamment élevée pour être unique par instance de navigateur.
Un site malveillant peut donc :
- Créer plusieurs bases IndexedDB avec des noms distincts
- Appeler
indexedDB.databases()et noter l’ordre de retour - Comparer cet ordre avec celui observé depuis un autre domaine
- Conclure avec certitude que les deux sessions appartiennent au même processus navigateur
C’est incroyable quand on y pense, non ? J’ai essayé de simplifier au maximum, j’espère que c’est assez clair, sinon je vous montre juste en dessous un exemple.
Exemple concret : ce que ça permettait en pratique
Imaginons un utilisateur de Tor Browser qui compartimente deux identités : une pour consulter un forum politique sensible, une autre pour accéder à sa messagerie professionnelle. Il clique sur « New Identity » entre les deux sessions, pensant réinitialiser complètement son profil.
Un site contrôlant les deux points d’entrée ou une ressource tierce avec les deux, aurait pu extraire l’identifiant IndexedDB sur les deux sessions et constater qu’elles provenaient du même processus. Aucun cookie partagé. Aucune IP commune. Juste l’ordre de retour d’une API de stockage.
En pratique, l’exploitation nécessite un adversaire capable d’injecter du JavaScript sur plusieurs origines visitées dans la même session ou de contrôler une ressource tierce présente sur des pages non liées. Bon qu’on soit bien d’accord, ce n’est pas une attaque à monter à grande échelle (trop complexe), mais pour un adversaire ciblé (services étatiques, opérateurs de sites .onion malveillants), c’est plutôt une solution optimisé sans trop de contrainte. Donc vous n’avez probablement aucun soucis à vous faire sauf si vous êtes recherché 🤣.
Il faut donc éviter l’exagération. Cette vulnérabilité n’exposait pas l’adresse IP réelle de l’utilisateur, ne compromettait pas les circuits Tor eux-mêmes, et ne permettait pas de corréler des sessions entre deux redémarrages distincts du navigateur. L’identifiant était lié au processus en cours pas à une installation permanente. Elle ne permettait pas non plus de récupérer le contenu des bases IndexedDB d’autres origines : la Same-Origin Policy reste en place. Ce qui était exposé, c’est uniquement l’ordre de retour de la liste des noms de bases, pas les données elles-mêmes.
La portée réelle : désanonymisation intra-session, entre sites distincts, pour un adversaire actif disposant d’une présence JavaScript sur plusieurs des sites visités.
Le correctif : simple, efficace, aurait dû être là dès le début
La solution est directe. indexedDB.databases() ne doit pas exposer un ordre qui reflète l’état interne du processus. En canonicalisant ou en triant les résultats avant de les retourner, on supprime l’entropie identifiante sans changer le comportement fonctionnel de l’API.
Firefox 150 et ESR 140.10.0 intègrent ce correctif. La cause racine étant dans l’implémentation Gecko d’IndexedDB, tous les navigateurs basés sur Gecko sont concernés y compris Tor Browser, qui hérite du moteur. La divulgation a été gérée de manière responsable par l’équipe Fingerprint.com vers Mozilla et le Tor Project avant publication.
Bon et gardons en tête quelques idées simples :
- Tor Browser rend l’anonymat absolu : Non. Tor protège contre la surveillance réseau et masque l’adresse IP. Il ne protège pas contre les vulnérabilités dans le code du navigateur lui-même. Cette faille en est une illustration directe.
- New Identity réinitialise tout : New Identity réinitialise les circuits Tor, les cookies et l’historique de navigation. Il ne redémarre pas le processus du navigateur et c’est précisément là que vivait cet identifiant.
- Seuls les API évidents comme les cookies ou localStorage sont à risque : Cette faille montre le contraire. L’identifiant était extrait de l’ordre de retour d’une API de listing, pas d’une donnée stockée explicitement. Ce type de canal indirect (side-channel via implémentation) est systématiquement sous-estimé.
Si ce n’est pas déjà fait, mettez à jour Firefox au minimum vers la version 150. Pour les utilisateurs de Tor Browser, attendre la mise à jour intégrant le correctif Gecko est indispensable. Au-delà du patch, quelques principes de base :
- Redémarrer complètement Tor Browser entre des sessions d’identités sensibles, pas seulement cliquer « New Identity »
- Éviter les ressources tierces sur les pages visitées via Tor chaque script tiers est un point d’observation potentiel
- Considérer les VMs ou profils OS séparés pour des identités qui ne doivent jamais se croiser
Cette faille est un exemple propre de ce que les chercheurs en sécurité appellent un side-channel d’implémentation : pas de données sensibles exposées directement, mais un détail d’implémentation bas niveau qui encode un état interne stable et unique. Le correctif est disponible. La question reste ouverte : combien d’autres API navigateurs exposent des ordres ou des timings qui reflètent un état interne processus plutôt qu’une réponse canonique ?
Questions fréquentes sur la faille IndexedDB & Tor Browser
Tout ce qu’il faut savoir sur CVE-2026-6770, son impact réel sur l’anonymat Tor, et les mesures à appliquer.
Aucune preuve d’exploitation active n’a été publiée. La découverte de CVE-2026-6770 provient de recherches de l’équipe Fingerprint.com, qui a pratiqué une divulgation responsable vers Mozilla et le Tor Project avant toute publication.
Ce n’était pas une vulnérabilité exploitée dans la nature, mais un canal de fingerprinting passif — subtil, stable, et fonctionnel depuis potentiellement très longtemps sans que personne ne s’en aperçoive.
Mozilla a intégré le correctif dans Firefox 150 et ESR 140.10.0. Le patch est tracké sous Mozilla Bug 2024220.
Pour Tor Browser, la faille provient de l’implémentation Gecko héritée d’IndexedDB. Le Tor Project a été notifié simultanément par Fingerprint.com — une mise à jour intégrant le correctif Gecko est donc nécessaire. Vérifiez que votre version de Tor Browser est à jour via le menu À propos de Tor Browser.
Contre cette faille spécifique, non. « New Identity » réinitialise les circuits Tor, les cookies et l’historique de navigation — mais il ne redémarre pas le processus du navigateur. Or l’identifiant IndexedDB était lié au processus, pas à une session.
Tant que le processus Firefox/Gecko restait actif, l’identifiant était stable et observable par n’importe quel site. La seule vraie réinitialisation était un redémarrage complet du navigateur.
Oui. En mode Navigation Privée Firefox, l’identifiant de processus IndexedDB persistait même après fermeture de toutes les fenêtres privées — tant que le processus Firefox restait actif. Une nouvelle fenêtre privée ouverte dans la même session de Firefox exposait le même identifiant.
Deux sites distincts ouverts en navigation privée dans la même session Firefox pouvaient donc dériver indépendamment le même identifiant et conclure qu’ils avaient affaire au même utilisateur, sans aucun cookie partagé ni mécanisme de tracking explicite.
Si l’article vous a plu et si vous aimez mon travail, vous pouvez faire un don en suivant ce lien :
