← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-10910 · CWE-843 · Disclosed 2026-06-04

Type Confusion in V8 in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a burglar getting through the lobby turnstile but not the vault door

CVE-2026-10910 is a V8 type confusion bug in Google Chrome that can let a remote attacker run arbitrary code inside Chrome's sandboxed renderer by getting a user to load crafted web content. The affected range is Chrome before 149.0.7827.53; Google's June 2, 2026 stable rollout shipped 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS, with Android inheriting the same desktop security fixes in 149.0.7827.59.

paragraph 2: Google's HIGH 8.8 label is technically fair if you score it as browser RCE from the internet, but it overstates the enterprise patching urgency a bit because the code runs inside the sandbox, there is no KEV listing, the prompt's EPSS is only 0.00081, and I found no public PoC or active exploitation evidence. That said, browsers are one of the few apps every user runs against hostile content all day, so this still lands in defender-priority HIGH, just not at the top of the queue.

"Internet-reachable and easy to deliver, but the Chrome sandbox keeps this below panic level absent exploit evidence."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver malicious web content

The attacker needs the victim to render attacker-controlled HTML/JavaScript in Chrome. In practice that means phishing, malvertising, a compromised site, or an ad network redirect; there is no authentication requirement, but there *is* a hard dependency on user interaction or browser-driven page load.
Conditions required:
  • Target uses vulnerable Chrome version
  • Victim browses to attacker-controlled or attacker-influenced content
  • JavaScript execution is allowed
Where this breaks in practice:
  • Requires user interaction (UI:R) rather than silent drive-by infrastructure scanning
  • Email security, web filtering, Safe Browsing, and ad/tracker controls prune a lot of delivery attempts
  • Enterprise auto-update sharply reduces the stale-host population
Detection/coverage: Network scanners will not see this. Coverage comes from proxy logs, DNS logs, Safe Browsing telemetry, browser crash spikes, and EDR process ancestry around chrome/msedgewebview2 child activity.
STEP 02

Trigger the V8 type confusion

The payload abuses V8 object typing to confuse the engine into operating on incompatible structures, creating a path to controlled memory corruption. No public weaponized exploit or GitHub PoC was found; the Chromium issue is still restricted, which raises reverse-engineering cost for opportunistic actors.
Conditions required:
  • Attacker has a browser-specific exploit for this bug
  • Target browser build and platform line up with exploit assumptions
  • Mitigations such as exploit hardening do not break reliability
Where this breaks in practice:
  • Browser memory corruption exploits are brittle across versions and architectures
  • Chrome's renderer hardening and allocator defenses reduce exploit reliability
  • Restricted bug details slow copycat exploitation
Detection/coverage: Exploit kits and commodity scanners do not have reliable signature-level coverage here. Practical detection is indirect: browser crashes, abnormal renderer restarts, and EDR memory-corruption telemetry if enabled.
STEP 03

Execute inside the renderer sandbox

If exploitation succeeds, the attacker gets arbitrary code execution inside Chrome's sandbox, not on the full host. That is real compromise, but it is deliberately fenced: filesystem, sensitive IPC, and OS interactions are constrained compared with native user-mode execution.
Conditions required:
  • Exploit achieves controlled execution
  • Renderer sandbox is functioning normally
  • Attacker can operate within sandbox restrictions
Where this breaks in practice:
  • Sandboxed execution sharply limits blast radius
  • Many post-exploitation actions require a second bug, privileged browser IPC abuse, or social engineering
  • EDR still sees browser child-process abuse and LOLBin pivots if a breakout is attempted
Detection/coverage: Behavioral EDR can catch suspicious child processes, script interpreters, token access, or browser spawning patterns. Version-based vulnerability scanners can identify exposure, but they do not validate exploitability.
STEP 04

Chain to meaningful host impact

To turn renderer code execution into credential theft, lateral movement, or host takeover, the attacker usually needs a sandbox escape, local privilege escalation, or abuse of browser-trusted workflows. This is the decisive downward pressure on severity: the CVE is dangerous, but the headline impact assumes an additional compromise stage.
Conditions required:
  • Attacker has a viable post-sandbox chain or can achieve objectives from in-browser context alone
  • Target protections do not block follow-on activity
  • User/session contains data worth stealing through browser context
Where this breaks in practice:
  • A second exploit or privileged pivot is often required for full endpoint compromise
  • MFA, EDR, application control, and browser isolation can stop or contain follow-on steps
  • Many enterprises can tolerate a sandboxed renderer compromise better than a native host RCE
Detection/coverage: This is where detections get better: EDR, sandboxing, child-process blocking, kernel telemetry, and identity monitoring all operate on the follow-on chain.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the consulted source set; not in CISA KEV as of the catalog pages reviewed.
Public PoC availabilityNo public PoC located. The Chromium issue for this bug is present but access-restricted, which is normal during patch rollout and raises copycat friction.
EPSS0.00081 from the prompt, which is roughly 0.081% modeled 30-day exploit probability; no authoritative percentile was available in the retrieved sources.
KEV statusNot KEV-listed; no CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — internet-deliverable with no auth, but user interaction is required and the stated impact is still inside a sandbox.
Affected versionsChrome prior to 149.0.7827.53; Google's desktop stable rollout on 2026-06-02 shipped 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac).
Fixed versions149.0.7827.53+ is the safe floor for this CVE; for fleet policy use 149.0.7827.54+ on Windows/macOS if you want the exact desktop stable pair Google rolled out.
Disclosure and creditPublished 2026-06-04; Chrome's stable notes credit Mufeed VH from Winfunc Research and show the Chromium bug ID 508811477.
Exposure populationThis is a browser-client bug, not an internet service. Shodan/Censys/FOFA are basically useless for enumerating exposure; your real inventory source is endpoint software/version telemetry.
Detection realityBest coverage is version inventory + EDR + browser telemetry. Traditional external vuln scanning and perimeter signatures will miss most of the risk.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.4/10)

The single biggest severity brake is that successful exploitation yields code execution inside Chrome's sandbox, not immediate host-level execution. I kept it in HIGH because attacker position is still just malicious web content to a widely deployed browser, which is a very reachable delivery model across a 10,000-host enterprise.

HIGH Affected version floor and fixed release mapping
HIGH Need for user interaction and sandboxed impact
MEDIUM No-public-PoC / no-active-exploitation assessment

Why this verdict

  • Downgrade from 8.8 because the RCE lands in a sandbox — that is a real containment boundary and it removes the automatic assumption of full host compromise.
  • Still HIGH because attacker position is easy — unauthenticated remote delivery through ordinary web content is a reachable path in nearly every enterprise.
  • Downward pressure from threat intel — prompt EPSS is 0.00081, KEV is No, and I found no public PoC or public exploitation evidence.
  • Upward pressure from exposure — Chrome is ubiquitous, high-frequency, and continuously exposed to untrusted content, so even sandboxed memory corruption deserves fast patching.
  • More downward pressure from fleet reality — modern enterprises usually have auto-update, browser isolation, EDR, Safe Browsing, and web filtering that cut exploit reach and post-exploitation payoff.

Why not higher?

There is no evidence here of active exploitation, KEV inclusion, or an available exploit chain that reliably turns renderer execution into host compromise. The need for user interaction plus the sandbox boundary makes this materially less urgent than a browser bug with a published sandbox escape or an already-abused zero-day.

Why not lower?

This is still internet-deliverable memory corruption in the browser engine used by nearly every employee. Even without host escape, a working exploit gives an attacker a foothold in one of the most exposed applications in the fleet, which is too reachable and too common to treat as routine backlog.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Use GPO/MDM/package management to force stable-channel updates and block version pinning. For a HIGH verdict, get this mitigation in place within 30 days if you do not already have it, because stale browsers are the real exposure multiplier.
  2. Block outdated browser versions — Use EDR, MDM compliance, or NAC to flag and quarantine endpoints running Chrome below 149.0.7827.53. This is the cleanest temporary control for a client-side browser bug and should be deployed within 30 days where feasible.
  3. Route risky users through browser isolation — Put high-click populations such as finance, exec admins, and helpdesk behind remote/browser isolation for unknown sites. If you cannot patch part of the fleet quickly, apply this compensating control within 30 days to reduce exploit reliability and post-exploitation value.
  4. Tighten browser child-process policy — Use EDR or application control to block abnormal child processes from Chrome and alert on script interpreters, LOLBins, and credential access spawned by browser processes. This does not stop the renderer bug itself, but it does raise the cost of turning sandboxed execution into real endpoint impact within 30 days.
  5. Prioritize browser-version inventory — Pull a version census from endpoint management, not from network scanners. For this class of bug, good inventory is the compensating control that tells you whether you actually have a Monday problem or just a patch already rolling.
What doesn't work
  • A WAF does not help; this is client-side browser exploitation, not a server-side HTTP parsing issue on your edge.
  • External vulnerability scanners do not meaningfully enumerate vulnerable Chrome clients, so they will underreport your exposure.
  • MFA does not prevent exploitation of the browser engine; it only helps with some follow-on account abuse.
  • Generic IDS signatures are weak here because exploit traffic is usually just crafted web content over normal browsing channels.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your RMM/EDR script runner. Invoke it with python3 check_chrome_cve_2026_10910.py on macOS/Linux or py check_chrome_cve_2026_10910.py on Windows; no admin rights are usually needed, but elevated rights may improve registry and filesystem visibility on locked-down Windows hosts.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10910.py
# Detects whether locally installed Google Chrome/Chromium builds are below the fix floor for CVE-2026-10910.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from typing import List, Optional, Tuple

FIXED = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
    if not text:
        return None
    m = VERSION_RE.search(text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_version(a: Tuple[int, int, int, int], b: Tuple[int, int, int, int]) -> int:
    return (a > b) - (a < b)


def run_cmd(cmd: List[str]) -> Optional[str]:
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or "") + "\n" + (p.stderr or "")
        return out.strip()
    except Exception:
        return None


def windows_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
    found = []
    # Registry query via reg.exe to avoid winreg edge cases in restricted contexts
    reg_paths = [
        r'HKLM\SOFTWARE\Google\Chrome\BLBeacon',
        r'HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\SOFTWARE\Google\Chrome\BLBeacon',
        r'HKLM\SOFTWARE\Chromium\BLBeacon',
        r'HKCU\SOFTWARE\Chromium\BLBeacon',
    ]
    for path in reg_paths:
        out = run_cmd(['reg', 'query', path, '/v', 'version'])
        if out:
            v = parse_version(out)
            if v:
                found.append((path, v))

    exe_paths = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Chromium', 'Application', 'chrome.exe'),
    ]
    for exe in exe_paths:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out or '')
            if v:
                found.append((exe, v))
    return dedupe(found)


def mac_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
    found = []
    paths = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
        os.path.expanduser('~/Applications/Chromium.app/Contents/MacOS/Chromium'),
    ]
    for p in paths:
        if os.path.exists(p):
            out = run_cmd([p, '--version'])
            v = parse_version(out or '')
            if v:
                found.append((p, v))
    return dedupe(found)


def linux_versions() -> List[Tuple[str, Tuple[int, int, int, int]]]:
    found = []
    cmds = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
    ]
    for cmd in cmds:
        out = run_cmd(cmd)
        v = parse_version(out or '')
        if v:
            found.append((' '.join(cmd), v))
    return dedupe(found)


def dedupe(items: List[Tuple[str, Tuple[int, int, int, int]]]) -> List[Tuple[str, Tuple[int, int, int, int]]]:
    seen = set()
    result = []
    for src, ver in items:
        key = (src, ver)
        if key not in seen:
            seen.add(key)
            result.append((src, ver))
    return result


def main() -> int:
    system = platform.system().lower()
    versions: List[Tuple[str, Tuple[int, int, int, int]]] = []

    if 'windows' in system:
        versions = windows_versions()
    elif 'darwin' in system:
        versions = mac_versions()
    elif 'linux' in system:
        versions = linux_versions()
    else:
        print('UNKNOWN')
        return 2

    if not versions:
        print('UNKNOWN')
        return 2

    vulnerable = []
    patched = []
    for src, ver in versions:
        if cmp_version(ver, FIXED) < 0:
            vulnerable.append((src, ver))
        else:
            patched.append((src, ver))

    if vulnerable:
        print('VULNERABLE')
        return 1

    if patched:
        print('PATCHED')
        return 0

    print('UNKNOWN')
    return 2


if __name__ == '__main__':
    sys.exit(main())
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: treat this as a HIGH browser-engine issue, but not a fire drill. Use your endpoint inventory to identify Chrome versions below 149.0.7827.53, enforce or repair auto-update, and put any lagging high-risk user groups behind browser isolation or stricter browser child-process controls within 30 days per the noisgate mitigation SLA; then complete the actual browser upgrade across the fleet within 180 days per the noisgate remediation SLA. There is no mitigation SLA — go straight to the 180-day remediation window would be wrong here because HIGH does have one, but this is also not an immediate-hours event since it is not KEV-listed and no active exploitation was found.

Sources

  1. Google Chrome Stable Channel Update for Desktop (June 2, 2026)
  2. Chrome Releases June 2026 archive
  3. Chromium issue 508811477 for CVE-2026-10910
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS data and stats
  7. FIRST EPSS API documentation
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.