CVE-2026-85046 · V8 Type Confusion in Inline Array.prototype.sort (Maglev JIT) in…

01 · The Real Story

Someone left the sorting hat on backwards and now it thinks pointers are just numbers

CVE-2026-85046 is a type confusion flaw in V8's inline Array.prototype.sort optimization path, specifically in the Maglev JIT compiler's TryReduceArrayPrototypeSort function. When the JIT accepts polymorphic element-kind feedback (PACKED_SMI_ELEMENTS + PACKED_ELEMENTS), a crafted comparator callback can call arr.fill(0), migrating the receiver's map backward from PACKED_ELEMENTS to PACKED_SMI_ELEMENTS. V8 then treats object pointers as small integers, yielding addrof and fakeobj primitives and ultimately arbitrary read/write across the V8 heap. All Chromium-based browsers — Chrome, Edge, Brave, Opera, Vivaldi — and all Electron applications prior to the upstream fix at Chrome 152.0.7977.82 are affected. The flaw was reported by Salvatore Gulizia (Serotav) on August 4, 2026, and publicly patched September 3, 2026 — Google's sixth actively exploited Chrome zero-day of the year.

Google's vendor severity of HIGH (8.8) is honest and accurate. The CVSS vector correctly encodes unauthenticated remote access with required user interaction and a scope boundary (the sandbox) that is *not* crossed by this bug alone. Execution is confined to Chrome's renderer sandbox: the attacker gets cookies, DOM, session tokens, and form data from the compromised tab, but does not get direct file-system access, OS-level persistence, or lateral movement without chaining a separate sandbox-escape flaw. A companion fix in the same release for CVE-2026-85050 (OOB write in WebGL on Android) hints at a potential chain, but Google has not confirmed the two were paired in the wild. The practical impact is significant — session hijacking from an admin's browser is enough to pivot into cloud consoles, identity providers, or CI dashboards — but the sandbox cap means 8.8 HIGH is the right grade, not CRITICAL.

"Actively exploited V8 type confusion gives sandbox RCE in every Chromium browser. Patch now."

02 · The Attack Path

6 steps from start to impact.

STEP 01

Deliver crafted page to victim

The attacker hosts or injects JavaScript exploit code into a web page. Delivery can be phishing email, malvertising through ad networks, watering-hole compromise, or SEO poisoning. No authentication or special network position is needed — the attacker just needs the victim's browser to fetch the page.

Conditions required:

Victim running any Chromium-based browser < 152.0.7977.82
Victim navigates to or is redirected to attacker-controlled content

Where this breaks in practice:

Requires user interaction (click, navigation) — but phishing and malvertising are industrialized
Content-Security-Policy and site-isolation reduce but do not prevent delivery via ad iframes

Detection/coverage: Email gateway and web proxy URL reputation may block known malicious domains; browser-level Safe Browsing provides secondary coverage but zero-day payloads bypass signature detection.

STEP 02

JIT training loop triggers Maglev inline sort

The exploit JavaScript creates a small array (≤16 elements) and calls Array.prototype.sort approximately 1,000–2,000 times, feeding the Maglev compiler polymorphic element-kind feedback that mixes PACKED_SMI_ELEMENTS and PACKED_ELEMENTS. This is standard-looking JavaScript; no unusual APIs are invoked during training. Tools: raw JavaScript, no external libraries.

Conditions required:

JIT compilation is enabled (default in all Chromium builds)
Array length ≤ 16 to hit the inline insertion-sort fast path

Where this breaks in practice:

None — this is normal-looking JS that blends into any minified bundle

Detection/coverage: No current EDR or browser telemetry specifically flags JIT training loops. V8's TurboFan tracing (--trace-turbo) would show the optimization but is never enabled in production.

STEP 03

Comparator callback triggers map migration

During a final sort() call, the attacker-supplied comparator invokes arr.fill(0), which causes V8 to migrate the array's hidden class (map) backward from PACKED_ELEMENTS to PACKED_SMI_ELEMENTS. The JIT-compiled sort code continues using the stale map, reading object pointers as SMIs and vice versa. This is the type-confusion trigger.

Conditions required:

V8 has not yet applied the patch that prevents map migration during an active sort comparator

Where this breaks in practice:

Timing is deterministic — no ASLR defeat or heap spray required, making the exploit highly reliable

STEP 04

Build addrof/fakeobj primitives

With the type confusion established, the attacker constructs standard V8 exploitation primitives: addrof (leak a pointer value as a number) and fakeobj (create a pointer from a controlled number). These are chained to build an arbitrary read/write primitive within the V8 heap cage. PoC repos (e.g., atiilla/CVE-2026-85046, SneakyNachos/CVE-2026-85046) demonstrate this step.

Conditions required:

Type confusion from step 3 succeeded

Where this breaks in practice:

V8 heap cage (pointer compression, sandboxed pointers) limits read/write to the V8 address space, not the full process

Detection/coverage: Chrome's MiraclePtr / BackupRefPtr may detect some OOB accesses in crash telemetry, but this does not block exploitation in real time.

STEP 05

Achieve renderer-process code execution (sandbox-contained)

The attacker uses the arbitrary read/write to corrupt V8 internals — for example, overwriting a WebAssembly module's code pointer with attacker-controlled shellcode as demonstrated in the SneakyNachos PoC. Execution now runs inside the Chrome renderer sandbox. The attacker can read cookies, session tokens, manipulate the DOM, exfiltrate form data, and interact with any origin the tab has access to.

Conditions required:

Arbitrary read/write from step 4

Where this breaks in practice:

Sandbox boundary — the attacker cannot touch the filesystem, spawn processes, or access other tabs/profiles without a separate sandbox-escape vulnerability
Site isolation limits cross-origin access to same-process origins

Detection/coverage: Renderer crash reports and anomalous chrome.runtime API calls may appear in browser telemetry. EDR process-behavior monitoring on the chrome.exe renderer child process may flag unusual syscall patterns, but sandbox-confined activity generates minimal signal.

STEP 06

(Optional) Chain sandbox escape for full RCE

To break out of the sandbox, the attacker must chain a second vulnerability — such as CVE-2026-85050 (OOB write in WebGL, Android) or an IPC bug in the Mojo broker. Without this chain, the attacker is limited to renderer-scope impact. Google has not confirmed whether the in-the-wild exploitation paired a sandbox escape.

Conditions required:

A separate sandbox-escape vulnerability exists and is unpatched
Target platform matches the escape (e.g., Android for CVE-2026-85050)

Where this breaks in practice:

Sandbox escapes are rare, high-value, and independently patched
Multi-bug chains are fragile and version-sensitive
Chrome's multi-process architecture means the broker has a much smaller attack surface

Detection/coverage: Sandbox-escape attempts typically trigger Windows exploit-guard or macOS seatbelt violation logs. EDR should detect anomalous child-process creation from renderer processes.

03 · Compensating Control

HIGH 8.8→IGNORE 0.0

SEVERITY REDUCED

Force Chrome auto-update and verify fleet-wide deployment of 152.0.7977.82+ — Chrome's built-in updater handles this silently for most endpoints, but enterprise-managed browsers may lag behind if GPO/Intune policies pin versions or defer updates. Verify via your endpoint management platform (SCCM, Intune, Jamf, KACE) that every Chromium-based browser on every endpoint reports ≥ 152.0.7977.82. Because this is KEV-listed with confirmed exploitation, deploy within hours — do not wait for the standard noisgate HIGH mitigation SLA of 30 days.

HIGH 8.8→HIGH 7.5

Block known malicious PoC domains and URLs at the web proxy / DNS layer — Add threat intel feeds covering CVE-2026-85046 exploitation infrastructure to your web proxy (Zscaler, Netskope, Palo Prisma) and DNS resolver (Umbrella, Infoblox). This reduces exposure from commodity exploitation but does not protect against novel delivery infrastructure or zero-day watering holes. Apply immediately alongside patching.

HIGH 8.8→HIGH 8.0

Audit and update Electron applications embedding Chromium — Electron apps (Slack, VS Code, Teams, 1Password, etc.) embed their own Chromium and do not update via Chrome's auto-updater. Inventory all Electron apps, check their bundled Chromium version, and push updates from each vendor. Prioritize apps that process untrusted content (VS Code extensions, Slack link previews). Apply within the noisgate HIGH mitigation SLA of 30 days, or sooner for apps in CI/CD pipelines.

HIGH 8.8→LOW 2.5

SEVERITY REDUCED

Enable V8 JIT-less mode on high-risk headless Chrome instances — For CI/CD pipelines and server-side rendering that use headless Chrome (Puppeteer, Playwright), launch with --jitless flag to disable TurboFan/Maglev JIT compilation entirely. This eliminates the JIT-based type confusion attack surface at the cost of ~5-10x JavaScript performance degradation. Acceptable for testing and rendering workloads; not viable for interactive browsing. Apply immediately on CI/CD runners.

HIGH 8.8→HIGH 7.0

Enforce site isolation and strict Content-Security-Policy headers — Ensure --site-isolation-trials is active (default since Chrome 67) and enforce strict CSP on internal web applications to prevent malicious script injection via XSS or ad iframes. This limits the attacker's ability to target specific origins but does not prevent exploitation from a directly navigated malicious page. Deploy as a defense-in-depth measure within 30 days.

What doesn't work

Network-level IDS/IPS signatures — the exploit payload is standard-looking minified JavaScript delivered over HTTPS. No network signature can distinguish the ~2,000-iteration JIT training loop from legitimate application code without TLS interception and deep JS analysis.
EDR behavioral detection on the renderer process — sandbox-contained exploitation generates minimal OS-level telemetry. The renderer process does not make unusual syscalls; it simply manipulates V8 heap memory. EDR will not alert on this unless a sandbox escape follows.
Disabling JavaScript entirely — while technically effective, this breaks virtually all web applications and is not a viable compensating control for enterprise browser fleets.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	Confirmed. Google stated "an exploit for CVE-2026-85046 exists in the wild." This is Chrome's 6th actively exploited zero-day of 2026. No specific threat actor, campaign, or target vertical has been publicly attributed.
CISA KEV Status	Listed September 4, 2026, one day after patch release. Federal agencies subject to BOD 22-01 must remediate per the KEV-mandated deadline.
EPSS	0.48881 — approximately the 97th percentile. This places CVE-2026-85046 among the top 3% of all CVEs by predicted exploitation probability, consistent with confirmed in-the-wild activity.
PoC Availability	7 public repositories on GitHub; 1 flagged as weaponized. Notable repos: atiilla/CVE-2026-85046 (JS PoC with `addrof`/`fakeobj` primitives, browser HTML harness), SneakyNachos/CVE-2026-85046 (Wasm code-pointer hijack, runs in Chrome 152.0.7977.75 with `--expose-gc`), ubitquity/CVE-2026-85046 (conceptual C++ patch analysis). Exercise extreme caution: some CVE-named repos carry malware.
CVSS Vector	`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` → 8.8 HIGH. Key: S:U (Scope Unchanged) correctly reflects sandbox containment — impact is limited to the vulnerable renderer component, not the host OS.
Affected Versions	All Chromium-based browsers shipping V8 prior to the fix commit: Google Chrome < 152.0.7977.82, Microsoft Edge (Chromium), Brave, Opera, Vivaldi, and Electron applications embedding older Chromium. Electron apps pinning Chromium versions are independently vulnerable until their maintainers rebase.
Fixed Versions	Chrome 152.0.7977.82 (Linux), 152.0.7977.82/.83 (Windows/macOS). Edge, Brave, Opera, and Vivaldi must ship their own downstream updates pulling in the V8 fix. Electron framework requires Electron ≥ the release rebased onto Chromium 152.0.7977.82+.
Researcher	Salvatore Gulizia (handle: Serotav). Reported August 4, 2026. Google paid a $1,000 bounty — widely criticized as low for a confirmed zero-day under active exploitation.
Scanning/Exposure	GreyNoise and Shodan are not directly applicable — this is a client-side browser vulnerability, not a server-side service. Exposure is measured by browser version inventory across managed endpoints. Enterprises without browser version enforcement via GPO, Intune, or Jamf should assume full fleet exposure.
Disclosure Timeline	Reported 2026-08-04 → Patch released 2026-09-03 (30-day fix window) → KEV listed 2026-09-04 → Public PoCs appeared within days.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (8.8/10)

Why this verdict

Active exploitation confirmed, KEV-listed: Google explicitly states an exploit exists in the wild, and CISA added it to KEV within 24 hours of the patch. This eliminates any doubt about real-world weaponization and overrides any theoretical friction discount.
Weaponized PoC is public and reliable: Multiple GitHub repos demonstrate the full addrof/fakeobj chain. The exploit is deterministic — no heap spray, no ASLR bypass needed — making it accessible to mid-tier attackers, not just APTs.
User interaction is the only prerequisite, and it's industrialized: The CVSS vector correctly requires UI:R (user must visit a page), but phishing, malvertising, and watering-hole delivery are commodity capabilities. This friction point is real but provides less than 1 CVSS point of practical protection in enterprises.
Sandbox containment is the decisive cap at HIGH: The exploit achieves code execution *inside* Chrome's renderer sandbox. Without a chained sandbox escape, the attacker cannot access the host filesystem, spawn processes, or move laterally at the OS level. Session tokens, cookies, and DOM data are exposed, but the scope boundary (S:U) is architecturally enforced. This is why 8.8 HIGH, not 9.x CRITICAL, is correct.
Role multiplier: Chrome/Chromium is deployed on essentially 100% of enterprise workstations but is a *client application*, not a canonically high-value infrastructure component (it is not a hypervisor, domain controller, IdP, PAM, CA, or network edge appliance). The blast radius of a single renderer compromise is host-level (session theft from that user's browser). On an admin workstation with active sessions to Azure AD, AWS Console, or a CI/CD dashboard, session hijacking could escalate to identity-scale or supply-chain-scale impact — but this requires a second pivot, not the vulnerability itself. Electron apps in CI/CD pipelines processing untrusted content represent a supply-chain-adjacent scenario, but Electron's sandboxing posture varies widely and this is a minority deployment pattern. The floor is HIGH based on universal deployment + confirmed exploitation + session-theft capability, but does not reach the CRITICAL floor because Chrome is not a canonically high-value-role component and the sandbox prevents direct fleet/domain/supply-chain compromise.

Why not higher?

CRITICAL would require either (a) a confirmed sandbox escape chain, giving full OS-level RCE with no additional prerequisites, or (b) the affected component being a canonically high-value infrastructure service (hypervisor, DC, IdP, network edge). CVE-2026-85046 achieves sandbox-contained execution only — the attacker gets cookies and DOM but not the host. The CVSS Scope is correctly Unchanged. The companion CVE-2026-85050 is Android-only and unconfirmed as a paired chain. Without evidence of a cross-platform sandbox escape, the blast radius is capped at session-level, not OS-level.

Why not lower?

Downgrading below HIGH would ignore three hard signals: (1) confirmed in-the-wild exploitation by Google, (2) CISA KEV listing within 24 hours, and (3) an EPSS of 0.489 placing it in the 97th percentile. The exploit is deterministic, public, and weaponized. Session-level compromise from a browser is not trivial — it enables credential theft, OAuth token replay, and SaaS account takeover. Reducing to MEDIUM would misrepresent the operational urgency for any fleet running unpatched Chromium.

06 · Verification

Crowdsourced verification payload.

Run this script on any Windows endpoint with administrator or standard-user privileges. It checks all installed Chromium-based browsers (Chrome, Edge, Brave, Opera, Vivaldi) against the patched version threshold. Invoke from an elevated PowerShell prompt or via your RMM/endpoint management tool: powershell -ExecutionPolicy Bypass -File .\Check-CVE-2026-85046.ps1

noisgate-verify.ps1

POWERSHELLREAD-ONLYSAFE

<# Check-CVE-2026-85046.ps1
   Checks installed Chromium-based browsers for CVE-2026-85046 vulnerability.
   Output: VULNERABLE / PATCHED / UNKNOWN per browser.
   Exit codes: 0 = all patched, 1 = at least one vulnerable, 2 = no browsers found.
#>

$ErrorActionPreference = 'SilentlyContinue'
$patchedVersion = [version]'152.0.7977.82'
$foundAny = $false
$vulnerable = $false

$browsers = @(
    @{ Name = 'Google Chrome';    Paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
    )},
    @{ Name = 'Microsoft Edge';   Paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\msedge.exe',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\msedge.exe'
    )},
    @{ Name = 'Brave';            Paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\brave.exe'
    )},
    @{ Name = 'Vivaldi';          Paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\vivaldi.exe'
    )}
)

foreach ($browser in $browsers) {
    $exePath = $null
    foreach ($regPath in $browser.Paths) {
        $reg = Get-ItemProperty -Path $regPath -ErrorAction SilentlyContinue
        if ($reg.'(default)') {
            $exePath = $reg.'(default)'
            break
        }
    }
    if (-not $exePath -or -not (Test-Path $exePath)) { continue }
    $foundAny = $true
    $fileVersion = (Get-Item $exePath).VersionInfo.ProductVersion
    try {
        $ver = [version]$fileVersion
    } catch {
        Write-Host "[$($browser.Name)] Version parse error: $fileVersion — UNKNOWN"
        continue
    }
    if ($ver -ge $patchedVersion) {
        Write-Host "[$($browser.Name)] $fileVersion >= $patchedVersion — PATCHED"
    } else {
        Write-Host "[$($browser.Name)] $fileVersion < $patchedVersion — VULNERABLE"
        $vulnerable = $true
    }
}

if (-not $foundAny) {
    Write-Host 'No Chromium-based browsers found in registry — UNKNOWN'
    exit 2
}
if ($vulnerable) {
    Write-Host "`nRESULT: VULNERABLE — at least one browser requires update for CVE-2026-85046"
    exit 1
} else {
    Write-Host "`nRESULT: PATCHED — all detected browsers meet minimum version"
    exit 0
}