A vulnerability in Mozilla Firefox allowed websites to generate a stable, hidden identifier from private browsing sessions without using cookies - a tracking signal that persisted through Tor Browser's identity reset feature and survived even after all private windows were closed. Mozilla fixed the flaw on April 21, 2026, in Firefox 150 and Firefox ESR 140.10. The Tor Project released Tor Browser 15.0.10 the same day.

The bug, assigned CVE-2026-6770 and categorized as "Other issue in the Storage: IndexedDB component" with moderate impact, was discovered by security researchers Dai Nguyen and Martin Bajanik of Fingerprint. Their public disclosure described how the IndexedDB API - a browser database built for storing structured web application data - inadvertently exposed a stable process-lifetime identifier through the ordering of results returned by the indexedDB.databases() method. That ordering, which the MDN Web Docs specification explicitly describes as undefined, reflected internal browser memory layout rather than any canonical, neutral presentation. The consequence was a tracking vector that operated entirely in metadata, never touching actual stored data across origins.

For the advertising and marketing technology industry, the case is a pointed reminder that browser privacy changes do not always arrive on a schedule announced at industry events. They arrive as patches, often quietly, and frequently carry implications for how user identity is resolved - and how it cannot be.

How the identifier formed

IndexedDB is a standard browser API used by web applications to store significant volumes of structured data on the client side. Applications use it for offline functionality, local caching, and complex client-side state management. The IDBFactory.databases() method returns a promise that resolves to an array describing the databases present in the current browsing context, including their names and version numbers. According to MDN's documentation, the sequence of those returned objects is explicitly undefined - meaning developers were never supposed to rely on a particular order.

In Firefox's private browsing implementation, according to the public technical analysis by Fingerprint, the browser mapped user-chosen database names to UUID-based internal filename identifiers using a global hash table. That mapping was keyed solely by the database name string, shared across origins, and persisted for the full lifetime of the IndexedDB quota client - which in practice meant the full lifetime of the Firefox process. When indexedDB.databases() was subsequently called, the browser collected those mapped names into an internal hash set and iterated over them without applying any canonical sort. The result was that the order of the returned list reflected internal hash table bucket layout, not a neutral presentation.

Because the UUID-based mappings were stable across the life of the running Firefox process, the returned ordering was also stable. Crucially, the ordering was process-scoped rather than origin-scoped. Two unrelated websites, running in the same Firefox private browsing process, could independently create a controlled set of database names and compare the ordering returned by indexedDB.databases(). If both sites observed the same non-canonical permutation, they could infer they were interacting with the same running browser process - without exchanging any data, without reading each other's storage, and without relying on cookies.

Fingerprint's write-up quantified the signal's strength. For sixteen controlled database names, the theoretical space of observable permutations is 16! - approximately 44 bits of entropy, according to the disclosure. The reachable permutation set may be smaller in practice due to hash table constraints, but the analysis argues the signal is robust enough for cross-origin correlation during active browsing sessions.

Why private mode and Tor New Identity did not protect users

Mozilla's own Firefox Help documentation describes Private Browsing as a mode that leaves no trace after the session ends. The browser's anti-fingerprinting work has been substantial. Firefox 145 completed a second phase of fingerprinting defenses in November 2025, cutting the percentage of users identifiable through fingerprinting by nearly half. Those protections target fingerprinting scripts that operate outside known tracker lists and restrict what browser APIs can reveal about device configuration. The CVE-2026-6770 flaw sat in a different layer entirely - not in graphic rendering, font enumeration, or device configuration APIs, but in the presentation order of storage metadata.

According to the Fingerprint disclosure, in affected Firefox Private Browsing builds the identifier could persist even after a user closed all private windows, as long as the Firefox process itself remained running. Closing a private window and restarting the browser were not equivalent actions for this bug. Only a full process restart cleared the signal.

The Tor Browser implications were more consequential for the users most at risk. Tor Browser explicitly documents its New Identity feature as a mechanism designed to make later browser activity unlinkable to prior activity. When triggered, New Identity closes open tabs and windows, clears cookies and browsing history, and switches to new Tor circuits. The Fingerprint disclosure states that in affected Tor Browser builds, the stable identifier survived a New Identity action within the same running browser process. A site could observe the same underlying ordering after the user had invoked what Tor documents as a full reset. Only a complete restart of the Tor Browser process cleared the identifier.

The Tor Project's release note for Tor Browser 15.0.10, published April 21, 2026, was unusually specific. It stated that the release included important Firefox security updates and, distinctly, "a fix to the cross-origin correlation issue explained here," linking directly to the Fingerprint research. That language confirms the Tor Project considered the issue operationally relevant to its privacy model - not merely a downstream package update.

Mozilla classified CVE-2026-6770 as moderate within the Firefox 150 advisory bundle. That advisory was rated high overall because it also included memory-safety fixes and other security patches. The moderate classification for this specific CVE reflects the fact that no direct cross-origin data exfiltration occurred. But a moderate vendor label in a general-purpose browser becomes a meaningfully different threat in a browser whose core design proposition is active resistance to linkability and fingerprinting. Both assessments can be accurate simultaneously.

What this is not

Precision matters in security reporting. The Fingerprint disclosure does not describe one origin reading another origin's IndexedDB contents. The attack is correlation, not exfiltration. A site can observe a structural property of the running browser process - the iteration order of a metadata collection - and infer that a separate site is running within the same process. No raw database content crosses an origin boundary.

The identifier also did not survive a full browser restart. In both Firefox Private Browsing and Tor Browser, restarting the process changed the ordering. This is not a device-level fingerprint tied to hardware or persistent profile state. It is a process-lifetime signal - strong enough to correlate activity within a session, but not a permanent mark on the device.

The bug also sits in a different class from the Total Cookie Protection and state partitioning work Mozilla has pursued over several years. Those mechanisms target explicit storage channels: cookies, localStorage, cache, and related APIs that can carry cross-site identifiers. Firefox 149, released March 24, 2026, added a built-in VPN to that layered privacy architecture. The IndexedDB ordering flaw bypassed all of those defenses by using a different class of signal entirely - the presentation of internal implementation state through an API surface that was never supposed to carry identity semantics.

The advertising and ad tech context

The connection between browser fingerprinting research and digital advertising is not abstract. Fingerprinting as a tracking technique has been a live policy and technical debate in the industry for several years. Google announced in December 2024 that it would permit advertisers to use device fingerprinting starting February 16, 2025, particularly for Connected TV advertising. The UK Information Commissioner's Office called that decision "irresponsible" when it responded on December 19, 2024, pointing to the fact that fingerprinting relies on signals users cannot easily eliminate - unlike cookies, which can be cleared.

The ICO's concern maps directly onto what CVE-2026-6770 illustrates technically. Privacy controls built around cookies give users a tangible control surface. Fingerprinting signals derived from metadata ordering, hash table behavior, or internal implementation state do not. A user who believes they have reset their identity - by switching to private mode, by closing private windows, by triggering New Identity in Tor - has no visible mechanism to verify that every possible signal has actually been cleared.

Mozilla faced a separate controversy in September 2024 when the privacy organization noyb filed a formal complaint with the Austrian Data Protection Authority over Firefox's Privacy Preserving Attribution feature, which was enabled by default without explicit user consent. That case illustrated the tension between browser-level ad measurement and user privacy expectations. CVE-2026-6770 illustrates a different but related tension: the gap between a browser's documented privacy promises and the implementation details that determine whether those promises hold under active use.

For ad tech infrastructure, the practical question is what this class of vulnerability implies for identity resolution in privacy-constrained environments. The industry has spent considerable resources on cookieless identity solutions, first-party data strategies, and privacy-enhancing technologies. Those investments assume that the privacy boundaries browsers describe are real. When a bug shows that a supposedly isolated private session can be correlated across origins through metadata ordering, it surfaces the broader challenge: the integrity of any user-facing privacy claim depends on whether every layer of the implementation actually enforces the boundary the product documentation promises.

The Fingerprint researchers' disclosure noted that the proposed mitigation direction was canonicalization - applying a stable sort, such as lexicographic ordering by name, before returning results from indexedDB.databases() in private browsing contexts. Because MDN's specification already states the ordering is undefined, developers were never promised a specific order. Returning a canonical, neutral presentation would therefore remove the leak without violating any developer-facing guarantee. Mozilla's advisory does not describe the precise patch mechanics, but the Tor Browser release note's explicit reference to "the cross-origin correlation issue" confirms the downstream fix aligned with that direction.

The enumeration surface problem

The broader engineering lesson from CVE-2026-6770 is not specific to IndexedDB. Any API that enumerates internal objects - returning counts, ordering, opaque handles, or timing information - can become an identity surface if the underlying implementation state persists longer or scopes wider than users expect. Security review is generally well-equipped to ask whether data crosses a forbidden boundary. Privacy review must also ask whether the presentation of internal state crosses a semantic boundary: does the order, count, or shape of an API's output encode information the caller was never supposed to receive?

Browser vendors have made significant progress on state partitioning and explicit storage channels. Safari's Private Browsing 2.0 extended partitioning to localStorage, IndexedDB, and the Cache API for third-party content. Mozilla's Total Cookie Protection confines cookies to originating websites. These are real protections against real tracking vectors. But CVE-2026-6770 shows that partitioning storage does not automatically neutralize metadata signals that emerge from how the browser's internal implementation chooses to present that storage to JavaScript. The attack did not require reading another origin's IndexedDB data. It required only observing the order in which the browser listed database metadata.

For red teams and security engineers, the case also offers a workflow insight. Reproducing this class of vulnerability requires a two-origin test setup, precise version accounting, and testing across specific state transitions: open private window, compare ordering across origins, close private windows without restarting the process, reopen and compare again, then trigger a full restart and compare once more. A single-origin test proves nothing. The meaningful signal is cross-origin ordering consistency within the same process lifetime. Patched builds - Firefox 150, Firefox ESR 140.10, and Tor Browser 15.0.10 - should not reproduce the behavior.

Patch boundaries

Mozilla's official fix covers Firefox 150 and Firefox ESR 140.10. These are the verified patch boundaries confirmed in Mozilla's advisory. Tor Browser 15.0.10 incorporates the same fix, as confirmed by the Tor Project's own release note. For organizations running older Firefox ESR branches or any Gecko-based browser that has not explicitly adopted the fix, the prudent action is to verify patch status. The Fingerprint disclosure notes that the underlying behavior was tied to Gecko's IndexedDB implementation, which means other Gecko-based products should verify whether they inherited the same behavior unless they already carried their own mitigation.

For Tor Browser users specifically, updating to 15.0.10 or later is the clear remediation. The fix restores the unlinkability guarantee that New Identity is documented to provide within the scope of what a browser can control at the process level.

Timeline

Summary

Who: Mozilla, the Tor Project, and security researchers Dai Nguyen and Martin Bajanik of Fingerprint. Mozilla assigned and fixed the CVE; the Tor Project shipped a downstream fix; Fingerprint provided the public technical disclosure.

What: CVE-2026-6770 - a vulnerability in Firefox's IndexedDB implementation that exposed a stable, process-lifetime identifier through the ordering returned by indexedDB.databases(). The identifier enabled cross-origin correlation within a single browser session without using cookies or accessing cross-origin storage contents. The signal survived private window closure and Tor's New Identity feature until a full process restart.

When: Mozilla patched the vulnerability on April 21, 2026, in Firefox 150 and Firefox ESR 140.10. Tor Browser 15.0.10 was released the same day. The Fingerprint disclosure was published around April 23, 2026.

Where: The vulnerability resided in Gecko's IndexedDB implementation, affecting Firefox Private Browsing mode and Tor Browser sessions. It was exploitable across any two origins running within the same Firefox or Tor Browser process.

Why: The bug emerged because Firefox's private-mode IndexedDB implementation mapped database names to internal UUID-based identifiers using a global, process-scoped hash table, then returned the resulting list to JavaScript without applying a canonical sort. The iteration order of the hash set reflected internal memory layout - a stable, non-canonical signal that persisted across origins within the same process. The flaw contradicted the unlinkability guarantees documented by both Mozilla and the Tor Project for their respective privacy features.

Share this article
The link has been copied!