By ByteBot
Security researchers at Fingerprint.com discovered a critical privacy vulnerability (CVE-2026-6770) in Firefox’s IndexedDB implementation on April 21, 2026 that breaks Tor Browser’s anonymity guarantees. The flaw allows websites to generate a unique tracking identifier by inspecting the order IndexedDB returns database entries—even across supposedly isolated “New Identity” sessions. Mozilla released emergency patches (Firefox 150, ESR 140.10.0) the same day, but the discovery raises fundamental questions about browser-based privacy.
Tor Browser users specifically chose the tool for unlinkability between sessions. Journalists protecting sources, whistleblowers, and activists in authoritarian regimes relied on the “New Identity” button as a complete reset. Turns out it wasn’t resetting everything.
IndexedDB Ordering Creates Unique Fingerprint
IndexedDB returns database names in an order that reflects internal process-level state, not alphabetical or deterministic sorting. Websites can create databases, read the order, and derive a unique “fingerprint” for the browser process. That ordering acts as a stable tracking identifier—and here’s the problem: unrelated websites visiting the same browser process see the same ordering.
According to Fingerprint.com’s disclosure, “Websites can derive a unique, deterministic, and stable process-lifetime identifier from the order of entries returned by IndexedDB, even in contexts where users expect stronger isolation.” The identifier is process-scoped, not origin-scoped. This defeats Firefox’s privacy isolation model entirely. Cross-origin tracking works even when cookies are blocked.
The vulnerability exploits a fundamental design flaw: the browser exposed internal storage ordering that varies by process state rather than providing consistent, sorted results. Two completely unrelated domains can independently observe the same database ordering and link activity to the same user.
Tor’s “New Identity” Button Failed Its Core Promise
Tor Browser’s “New Identity” button promises a complete reset: clear cookies, clear history, establish new Tor circuits. Users click it expecting total unlinkability from their previous session. But the button doesn’t restart the browser process—and process-level state survives the reset.
The Fingerprint.com researchers confirmed: “In Tor Browser, the stable identifier persists even through the ‘New Identity’ feature, which is designed to be a full reset that clears cookies and browser history and uses new Tor circuits.” For users who rely on Tor for safety, this is a fundamental breach of trust. The tool they chose specifically for anonymity was betraying its core promise.
Related: GitHub CLI Silently Enables Telemetry: Opt-Out Is Wrong
Privacy features only work if they reset what users expect them to reset. Tor’s “New Identity” cleared network-level state (Tor circuits) and browser-level cookies, but left process-level state intact. That gap created a tracking vector that persisted across supposedly isolated sessions.
Mozilla Patched Within Hours
Mozilla’s response was impressive: patches released the same day as disclosure (April 21, 2026). Firefox 150 and ESR 140.10.0 canonicalize IndexedDB results before returning them, removing the entropy that enabled tracking. The fix is straightforward—sort database names alphabetically so the order is deterministic regardless of internal state.
CVE-2026-6770 was assigned, and Tor Browser inherits the fix through the Gecko engine. Thunderbird (Mozilla’s email client) also got patched versions (150 and 140.10). The Mozilla Security Advisory confirms the fix was deployed within hours of responsible disclosure.
But questions remain: How long has this flaw existed? IndexedDB has been in Firefox for years. Were users actually tracked using this method before it was discovered in security research? Why didn’t Mozilla’s security audits catch a flaw that breaks Tor’s entire anonymity model?
All Firefox-Based Browsers Hit
This isn’t just a Tor Browser issue. The vulnerability exists in Firefox’s Gecko engine, meaning all Firefox-based browsers inherited the flaw: LibreWolf (privacy-hardened Firefox fork), Mullvad Browser (Tor without the network), standard Firefox, and even Thunderbird.
Privacy-focused users who chose LibreWolf or Mullvad thinking they’re more secure than standard Firefox face the same vulnerability. The entire Firefox-based privacy browser ecosystem needs immediate updates. Only browsers using different engines (Chromium-based like Brave, or WebKit-based like Safari) are unaffected—they have different IndexedDB implementations.
What This Means
If you use Firefox, Tor Browser, or any Firefox-based privacy browser: update immediately. Check your version: Firefox must be 150 or higher, ESR must be 140.10.0 or higher. Restart your browser completely (full process restart, not just “New Identity”).
The broader question: Can we trust privacy tools to deliver on their promises? Mozilla responded fast, but this vulnerability exposed a fundamental gap between what Tor’s “New Identity” button claimed to do and what it actually did. Privacy features must be transparent about their limitations.
Browser-based privacy is hard. Process-scoped state leaks like this one are subtle—IndexedDB’s ordering behavior probably seemed like an implementation detail, not a privacy violation. But for users whose safety depends on anonymity, implementation details matter. Every API that exposes internal state is a potential fingerprinting vector.
The good news: responsible disclosure worked. Fingerprint.com reported it privately, Mozilla patched same-day, and users can now update. The bad news: how many other privacy browsers have similar flaws we haven’t discovered yet? The Hacker News discussion (768 points, 228 comments) reflects this concern across the developer community.
Update now. Restart fully. And maybe reconsider which privacy promises you trust.
