Vue lecture

Une faille IndexedDB permettait de relier toutes vos identités Tor

Bon, les amis, si vous utilisez Tor Browser pour faire du sérieux, faut que vous sachiez un truc. Le bouton "New Identity", censé vous donner une nouvelle identité vierge à chaque clic... bah il laissait filer, jusqu'à il y a peu de temps, un identifiant stable tant que Firefox tournait.

Deux chercheurs de Fingerprint ont en effet trouvé comment une fonction toute bête du navigateur se transformait en empreinte unique de votre browser, partagée entre tous les sites que vous visitiez.

Il faut donc dès à présent faire la mise à jour vers Firefox 150 ou l'ESR 140.10.0 (la version long-terme utilisée par Tor Browser), ainsi que la dernière version de Tor Browser qui récupère le patch. Si vous voulez en savoir plus, la CVE c'est CVE-2026-6770 , classé comme sévérité modérée par Mozilla.

Le truc marche en vase clos mais traverse les murs.

Mais avant, IndexedDB c'est quoi ?

En gros c'est une mini-base de données que les sites web peuvent créer dans votre navigateur, pour stocker des trucs en local (du cache, des données offline, l'état d'une app web). Chaque site peut y ranger plusieurs bases nommées, et une petite fonction JavaScript indexedDB.databases() permet au site de demander la liste de ses bases.

Rien de foufou sur le papier. Sauf que dans Firefox en navigation privée, le navigateur renomme en coulisse chaque base avec un identifiant aléatoire (UUID), et range tout ça dans une seule grosse table interne. Et le gros problème, c'est que cette table est partagée entre tous les sites ouverts, et pas cloisonnée site par site.

Et là, ça devient croustillant puisque quand un site redemande la liste de ses bases, Firefox la renvoie sans la trier, dans un ordre qui dépend de la structure interne de cette table partagée. Du coup, deux sites totalement différents qui créent chacun seize bases dans le même ordre récupèrent exactement la même suite en retour. Pas l'ordre de création donc mais une permutation bizarre, genre g,c,p,a,l,f,n,d,j,b,o,h,e,m,i,k.

Je vous passe les détails mais ça fait dans les 17 000 milliards de combinaisons possibles. Donc largement de quoi distinguer votre navigateur parmi des millions, comme une empreinte digitale qui colle au doigt !

Et ce qui pique vraiment c'est que cet identifiant survit à la fermeture de toutes vos fenêtres privées. Tant que le process Firefox tourne en arrière-plan, l'ID reste. Un site peut donc vous reconnaître après que vous ayez fermé vos onglets privés, rouvert une session pensée comme neuve, et revisité le site. Pour le user, c'est une session fraîche alors que pour le serveur c'est clairement le même navigateur qu'il y a dix minutes.

Côté Tor Browser c'est pire puisque le bouton "New Identity" a pour mission explicite de couper tout lien avec ce que vous faisiez avant. Il ferme les onglets, efface l'historique, vide les cookies, tire de nouveaux circuits Tor. La promesse officielle, c'est "empêcher votre activité future d'être liée à ce qui précède".

Sauf que cette fameuse table interne, elle, ne bouge pas. Le New Identity reset donc tout sauf ce qu'il ignore. C'est comme changer de fringues dans le même ascenseur... en gardant le même parfum. Techniquement vous êtes différent, mais reconnaissable en deux secondes. Bref, c'est assez grave car un site capable d'exploiter la faille peut lier votre session avant-New-Identity à votre session après-New-Identity.

Tant qu'on n'a pas redémarré Firefox complètement, l'ID persiste.

Les chercheurs disent avoir fait une divulgation responsable, directement à Mozilla et au Tor Project avant publication donc c'est nickel, et les deux équipes ont poussé les patches avant de communiquer sur quoi que ce soit. Donc les utilisateurs à jour sont tout simplement protégés contre cette faille précise.

Après si vous êtes du genre parano, pensez à redémarrer complètement votre Tor Browser entre deux sessions vraiment sensibles. Ça coupe le process Firefox, ça vide cette fameuse table, et ça évite ce genre de surprise pour d'autres leaks similaires qu'on n'aurait pas encore trouvés.

A bon entendeur, salut !!

Source

  •  

Docker : la faille CVE-2026-34040 permet d’obtenir un accès root sur l’hôte !

CVE-2026-34040 : une nouvelle faille de sécurité importante a été découverte dans Docker Engine. Elle permet de contourner le plugin Authz via une requête HTTP.

Le post Docker : la faille CVE-2026-34040 permet d’obtenir un accès root sur l’hôte ! a été publié sur IT-Connect.

  •  

CVE-2026-35616 : déjà exploitée, cette faille Fortinet a été patchée en urgence !

La solution Fortinet FortiClient EMS est concernée par la CVE-2026-35616, une faille de sécurité déjà exploitée en tant que zero-day. Un patch est disponible.

Le post CVE-2026-35616 : déjà exploitée, cette faille Fortinet a été patchée en urgence ! a été publié sur IT-Connect.

  •  

Apple a corrigé une faille sur iOS et macOS, et c’est invisible grâce à cette nouveauté

Apple a déployé son premier correctif via la fonctionnalité "Background Security Improvements" pour la CVE-2026-20643. C'est transparent pour les utilisateurs.

Le post Apple a corrigé une faille sur iOS et macOS, et c’est invisible grâce à cette nouveauté a été publié sur IT-Connect.

  •  

WordPress – CVE-2026-1492 : une faille dans un plugin permet de devenir admin très facilement

Une faille de sécurité critique affecte l'extension User Registration & Membership. Elle permet à un attaquant de pirater complètement le site WordPress.

Le post WordPress – CVE-2026-1492 : une faille dans un plugin permet de devenir admin très facilement a été publié sur IT-Connect.

  •