CVE-2026-10702: a page visit enabled Firefox RCE

Detailed reporting published on 29 July 2026 explains the impact of CVE-2026-10702 on Firefox and Tor Browser. The vulnerability is a JIT miscompilation in Firefox’s SpiderMonkey JavaScript engine. Mozilla had already fixed it on 2 June in Firefox 151.0.3 and rated the impact high. The new analysis shows why visiting a malicious page can be enough to gain code execution in the browser’s content process and how researchers used the flaw as the first stage of a larger Android 17 chain.

The most important caveat is that public sources do not establish exploitation against users in the wild. The released end-to-end chain targets one supported ARM64 device build running Android 17. It does not prove that every Firefox, Tor or Android installation can be compromised automatically with identical code.

What the sources establish

Mozilla Foundation Security Advisory 2026-54 confirms that CVE-2026-10702 is a JIT miscompilation in the JavaScript Engine: JIT component, reported by Nebula Security and fixed in Firefox 151.0.3. Mozilla rates the impact high.

The Hacker News’ 29 July report, drawing on Nebula Security’s technical research, adds:

• opening a page with crafted JavaScript can trigger the flaw without another click;
• the first stage provides code execution inside the browser content process, still within its sandbox;
• public material uses CVE-2026-10702 as IonStack’s browser entry;
• a separate Linux-kernel flaw, CVE-2026-43499 or GhostLock, is the second stage;
• the demonstrated chain reaches root on one supported ARM64 Android 17 build;
• exploit material is public, reducing the time others need to understand the defect.

Reporting traces the faulty code through stable Firefox releases 147 to 151.0.2. Mozilla’s official advisory expresses remediation through the fixed version, so policy should require 151.0.3 or later rather than making unsupported assumptions about older branches.

How a JIT mistake becomes stale-pointer use

A JavaScript engine can interpret instructions one by one, but it compiles frequently executed functions into native code for speed. The JIT removes repeated loads, simplifies objects and relies on declarations about which operations can change memory.

The issue involved MObjectToIterator when skipRegistration was set. The compiler classified the operation like a read of object fields. In reality, resolving a lazy property could allocate a replacement dynamic-slots buffer and free the previous one. Global value numbering then considered a later buffer load redundant and reused the stale pointer.

In simplified terms:

1. the JIT remembers a pointer to an object’s property buffer;
2. an operation classified as “read only” can mutate the object and free that buffer;
3. the optimizer does not see the mutation and keeps the pointer;
4. an attacker fills the released allocation with controlled data;
5. later code uses a pointer that now refers to attacker-influenced content.

This is not a JavaScript syntax bug. The compiler’s model of side effects was unsound. An optimization that would have been valid under the declared alias contract became dangerous because the contract was wrong.

What the first stage provides—and what it does not

The proof of concept leaks a shape pointer, constructs a fake object and obtains arbitrary memory read and write by corrupting a Uint8Array. It can then change memory protection and redirect a WebAssembly function entry point to native code.

That sounds like a complete compromise, but the renderer remains separated by the browser sandbox. Modern browsers assume that parsers and JS engines will have bugs and restrict what a content process can do. An attacker therefore needs another vulnerability or configuration weakness to escape the process and obtain system privilege.

The operational distinction is:

• CVE-2026-10702 supplies the web-content entry point;
• the sandbox constrains the first-stage impact;
• CVE-2026-43499 is the separate kernel escalation in the demonstrated chain;
• patching Firefox closes the documented entry but does not patch the kernel flaw.

Why Tor Browser appears in the story

Tor Browser is based on Firefox ESR and inherits much of its engine. Researchers said the vulnerable code also affected Tor releases that incorporated it, but public sources do not provide a complete list of Tor Browser version numbers. Teams should not manufacture one by mapping ordinary Firefox numbers.

Tor users should install the latest release distributed by the Tor Project and confirm that its updater completed. An organization distributing Tor for research or journalism should manage it as a distinct product, not as an alias for “Firefox ESR.”

The risk has a special dimension for Tor users. Even content-process execution can threaten session data and anonymity, while a successful system chain can identify a device. That does not mean the Tor network was broken. The flaw is in the endpoint application and device operating system.

Versions, updates and inventory questions

The minimum ordinary Firefox state is 151.0.3 or later. Enterprise policy cannot stop at “automatic updates are enabled.” Read the effective version on:

• office and remote laptops;
• VDI and golden images;
• privileged administrator workstations;
• test environments with pinned updates;
• portable browsers and containers;
• systems returning after an extended offline period.

If the organization uses Firefox ESR, read the advisory for that branch. MFSA2026-54 does not list ESR as an affected product. Do not assume every ESR is vulnerable or safe without a primary source.

Public exploit material changes urgency, not history

A demonstration lets independent researchers reproduce the mechanism in the described environment. It makes offensive knowledge more accessible, but does not prove an active campaign. For defenders it means:

1. remediation deadlines should be measured in hours or days, not quarters;
2. version inventory must be joined with kernel and mobile patch status;
3. SOC teams should retain browser and host telemetry from the exposure period.

Do not run a public exploit against production workstations. Version evidence, package integrity and a safe policy test are sufficient proof of remediation. Full reproduction belongs in an isolated lab and an explicitly authorized scope.

Detection hypotheses

JIT exploitation is difficult to find in an HTTP log alone. Combine layers:

• Firefox or content-process crashes after visiting a new domain;
• unusual WebAssembly activity or memory-protection changes visible to EDR;
• child processes, device access or kernel calls unexpected from a renderer;
• second-stage downloads or outbound connections from the browser process;
• disabled updating or the return of version 151.0.2 through VDI;
• a sequence of page visit, memory/crash alert, escalation and a new root process.

These are not vendor signatures. No alert does not rule out exploitation, especially on an unmanaged device. If a high-risk user ran a vulnerable build and visited unknown pages, analysis may need to go beyond installing the update.

What to do today

Administrators should enforce Firefox 151.0.3 or later, restart the browser after updating and remove vulnerable images from VDI catalogs. Tor Browser users should update through the Tor Project and verify the current build. Managed Android devices require a separate kernel patch-level check because a browser update does not remediate CVE-2026-43499.

Next, verify whether an ordinary user can disable the policy, whether telemetry covers off-network devices and how quickly the organization can force a restart. This is useful material for IT and employee cybersecurity training: “update your browser” communications must explain the restart and must not drive users toward fake installers.

Connect browser inventory to a vulnerability-management process and an IT security audit that validates policy enforcement, device coverage and public-PoC response.

Sources and boundaries

The vendor-confirmed fact is a high-impact JIT flaw fixed in Firefox 151.0.3, documented in MFSA2026-54. Root-cause and chain details come from Nebula Security and were collected in The Hacker News’ 29 July report.

There is no confirmed exploitation against users. The affected Tor Browser release set has not been precisely enumerated publicly, and the complete system PoC targets a specific Android 17 build. Detection and rollout guidance are BreachRoad conclusions. The core fact is simple: the browser entry point is patched only where the update actually reached the device.

A public PoC raises urgency but does not prove a campaign

A public demonstration reduces analysis cost for other researchers and possible attackers. It is not campaign telemetry. Organisations should increase patch urgency while retaining accurate language: “public PoC with no confirmed exploitation,” not “an attack is underway.”

The SOC should not look only for one demonstration page. Exploitation of a JIT flaw may lead to a content-process crash, an unusual memory sequence or a follow-on stage, but normal browsers generate substantial noise. The stronger correlation combines an affected version, a rare destination, a process crash and subsequent endpoint behaviour. Where telemetry is limited, removing the affected build remains more reliable than detection. The advisory is also a useful case for improving Sigma and SIEM detection engineering.

Three inventories: Firefox, Tor Browser and Android

Many organisations report one “Firefox” asset despite having desktop releases, ESR, portable installations, VDI images and Tor Browser. Each channel has its own release mechanism and must be checked separately. For Tor Browser, use the Tor Project as the authoritative version source instead of mechanically mapping Firefox numbers.

Android creates another responsibility boundary. The browser update removes the engine stage, while the researcher-described kernel stage depends on an appropriate operating-system build. Inventory device model, OS version, security patch level, distribution channel and vendor support. A device that cannot receive updates may need restricted access to sensitive services.

Closure evidence should state how many devices are fixed, awaiting restart, unmanaged or silent. Assign every exception an owner and deadline. Cyber Threat Intelligence helps distinguish PoC availability from campaign evidence, while the Breachroad Academy provides employees with safe update-hygiene foundations.

Do not close the issue on package installation alone. Require process restart and removal of old VDI or recovery images, or the vulnerable build can return at the next login or restore.