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

Inappropriate implementation in V8 in Google Chrome prior to 149

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

This is a burglar locked in your lobby, not loose in the server room

Per the supplied intel, this is an *inappropriate implementation in V8* in Google Chrome that lets a remote attacker execute code inside Chrome's renderer sandbox after getting a user onto malicious content. The affected range is Chrome versions before 149.0.7827.53; public release coverage around the June 2026 Chrome 149 rollout shows fixes landing at 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.

Google's HIGH 8.8 baseline is too hot for enterprise patch triage if the practical outcome is only renderer compromise. The big downgrade factor is the sandbox: a renderer RCE is a foothold, not a workstation compromise, and the attacker still needs user interaction plus a second bug or design weakness to escape containment and get to meaningful host impact.

"Renderer-only code exec is serious, but without a sandbox escape this is not a host-takeover emergency."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land malicious web content

The attacker needs the user to render attacker-controlled JavaScript or web content in vulnerable Chrome. In practice that means phishing, malvertising, a compromised site, or a targeted link delivered through email or chat; the weaponized tool is simply a hostile webpage using a custom V8 trigger rather than a public exploit kit.
Conditions required:
  • Target is running Chrome below the fixed build
  • Victim browses to attacker-controlled or attacker-influenced content
  • JavaScript or the vulnerable V8 path is reachable
Where this breaks in practice:
  • Requires *user interaction* rather than blind exploitation
  • Many enterprise email/web gateways block obvious lure delivery
  • High-value targets often browse behind additional isolation or filtering controls
Detection/coverage: Little scanner value here; delivery may show up in email gateway logs, DNS/proxy telemetry, or secure web gateway alerts, but a Nessus-style network scan will not prove exploitability.
STEP 02

Trigger V8 bug for renderer code execution

Once the page is loaded, attacker code exercises the vulnerable V8 implementation path to corrupt execution and gain code execution in the renderer process. The weaponized tool at this step is a bespoke browser exploit; I did not locate a public PoC for this exact CVE as of 2026-06-05.
Conditions required:
  • Exact vulnerable Chrome build and code path are present
  • Exploit reliability matches the victim platform and mitigations
  • No crash-only behavior; attacker needs a stable primitive
Where this breaks in practice:
  • Modern Chrome exploit chains are hard to make reliable across Windows, macOS, and Linux
  • Browser hardening, compiler mitigations, and V8 exploit instability reduce success rate
  • No public exploit evidence lowers the odds of broad opportunistic abuse
Detection/coverage: EDR rarely gives clean attribution for browser memory-corruption exploits unless they crash or spawn anomalous children. Chrome crash telemetry and user-reported tab crashes are more realistic signals.
STEP 03

Operate inside the sandbox

A successful exploit at this stage buys execution inside the renderer sandbox, not arbitrary host execution. The attacker can target data available to that renderer context and may attempt same-site/session abuse, but Chrome's multi-process model and Site Isolation sharply limit cross-site reach; the weaponized tool becomes post-exploitation JavaScript and renderer-resident payload logic.
Conditions required:
  • Renderer compromise succeeds
  • Desired data is reachable from the compromised renderer context
  • Enterprise extensions or browser settings do not further constrain access
Where this breaks in practice:
  • Chrome's sandbox restricts filesystem, device, and privileged browser access
  • Site Isolation reduces cross-site data exposure and process sharing
  • Impact is often bounded to the active browsing context unless chained further
Detection/coverage: Traditional vuln scanners cannot see this step. Browser forensics, extension telemetry, suspicious cookie/session behavior, and unusual network beacons from the browser process are better indicators.
STEP 04

Chain to sandbox escape or accept limited impact

To convert this into workstation takeover, the attacker usually needs a second vulnerability outside the renderer sandbox or another trusted execution bridge. Without that chain, the exploit ends as a contained browser compromise; the weaponized tool is a full exploit chain, and there is no public evidence of one tied to this CVE.
Conditions required:
  • A second exploit or trust boundary bypass is available
  • OS/browser mitigations do not block the escape path
  • Attacker has a reason to spend a higher-end chain on this target
Where this breaks in practice:
  • This is the decisive choke point: sandbox escape is a separate and much rarer capability
  • EDR, Attack Surface Reduction, and OS hardening are more likely to catch post-sandbox behavior
  • Most real attackers save full browser chains for high-value targets, not broad spray-and-pray
Detection/coverage: If the chain escapes, EDR visibility improves substantially due to child process creation, persistence attempts, token theft, or filesystem/registry activity. Absent escape, visibility remains weak.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence located that this CVE is actively exploited as of 2026-06-05; it is not listed in CISA KEV.
Public record statusI could not independently locate a public NVD/MITRE/Chrome entry for this exact CVE ID on June 5, 2026, so this assessment leans on the user-supplied metadata plus Chrome 149 release/fix context.
PoC availabilityNo public PoC or exploit repo found in quick public web/GitHub search as of 2026-06-05.
EPSS0.00038 from the supplied intel, which is extremely low and consistent with *no observed broad exploitation pressure*.
KEV statusNot KEV-listed; no CISA catalog entry found for this CVE as of 2026-06-05.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H correctly captures *remote delivery with user interaction*, but the C:H/I:H/A:H impact looks overstated if execution is inside the sandbox rather than on the host.
Affected versionsPer supplied intel: Chrome prior to 149.0.7827.53. Public Chrome 149 rollout material indicates fixed desktop builds at 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS.
Fixed versionsUpgrade to 149.0.7827.53 or later; for macOS specifically, advisory rollup material references 149.0.7827.54.
Exposure footprintThis is not an internet-facing service, so Shodan/Censys/FOFA exposure counts are not useful. The real exposure is endpoint footprint, and Chrome remains the dominant browser, so affected population can still be very large.
Disclosure / reporterSupplied disclosure date is 2026-06-04. I did not find a public reporter attribution for this exact CVE; Chrome often restricts bug details until most users are patched.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

The single biggest reason this lands in MEDIUM is that the reported outcome is code execution inside Chrome's sandbox, which materially cuts blast radius compared with true workstation RCE. Chrome's massive footprint keeps this from falling lower, but without exploitation evidence or a demonstrated sandbox escape, this is not a drop-everything event.

HIGH Renderer sandbox meaningfully limits host impact
MEDIUM Version/fix boundaries for Chrome 149 desktop builds
LOW Exact public metadata for this CVE ID

Why this verdict

  • Start at vendor 8.8: fair baseline for a widely deployed browser bug with remote delivery and no auth requirement
  • Down for sandbox-only execution: the reported impact is renderer compromise, not direct host compromise; that is the biggest real-world severity reducer
  • Down for user interaction: attacker needs the victim to browse or open hostile content, which implies a delivery step that modern mail/web controls can disrupt
  • Down for no exploitation signal: no KEV entry, no public PoC found, and supplied EPSS is extremely low
  • Up slightly for exposure scale: Chrome's endpoint footprint is huge, so even a bounded bug can affect a very large population

Why not higher?

Because the chain as described stops inside the sandbox. A second exploit is typically required to turn renderer code execution into host takeover, and there is no evidence in the supplied intel of a paired escape, KEV listing, or active campaign pressure.

Why not lower?

Because Chrome is everywhere, remote delivery is straightforward, and browser compromises still matter even when contained. A renderer foothold can still enable session abuse, same-context data theft, or chaining in high-value targeting scenarios, so this is not backlog fluff.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update — Verify that enterprise Chrome update policy is functioning and that stragglers are not pinned below the fixed build. For a MEDIUM verdict there is no mitigation SLA, so use this immediately as operational hygiene while you work inside the 365-day remediation window.
  2. Hunt version drift — Query endpoint management, EDR, or software inventory for any host still below 149.0.7827.53/54 and for unmanaged portable/browser forks lagging behind upstream. This is the fastest way to reduce practical exposure on Monday morning when there is no formal mitigation deadline.
  3. Use browser isolation for high-risk users — Apply remote browser isolation or equivalent protected browsing for executives, administrators, researchers, and other high-click populations where a renderer exploit is more likely to be worth an attacker chain. Treat this as defense-in-depth rather than a substitute for patching.
  4. Block unmanaged Chromium variants — Enforce application control so users are not running stale Chromium-derived browsers outside your normal patch channel. This matters because attackers only need one lagging browser footprint, not your standard gold image.
What doesn't work
  • A WAF or perimeter IPS does not solve endpoint browser memory corruption; the exploit lands in the client, not your server edge.
  • Network vulnerability scanning will not meaningfully measure exploitability here because the vulnerable surface is local browser code on user endpoints.
  • Antivirus alone is weak coverage for an in-memory renderer exploit that never drops a conventional payload or child process.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint itself from your EDR live response shell, software distribution tool, or a local terminal. Invoke it with python3 chrome_cve_check.py or python chrome_cve_check.py --path "C:\Program Files\Google\Chrome\Application\chrome.exe"; no admin rights are required unless your environment blocks process execution from standard user context.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_cve_check.py
# Check whether the locally installed Google Chrome version is vulnerable to
# CVE-2026-10904 based on fixed versions discussed in Chrome 149 advisories.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import argparse
import os
import platform
import re
import shutil
import subprocess
import sys

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


def parse_version(text):
    m = VERSION_RE.search(text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_version(binary):
    try:
        cp = subprocess.run([binary, '--version'], capture_output=True, text=True, timeout=10)
        out = (cp.stdout or '') + ' ' + (cp.stderr or '')
        return parse_version(out.strip())
    except Exception:
        return None


def candidate_paths():
    system = platform.system()
    paths = []

    if system == 'Windows':
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LocalAppData'),
        ]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe',
        ]
        for base in envs:
            if base:
                for suffix in suffixes:
                    paths.append(os.path.join(base, suffix))
    elif system == 'Darwin':
        paths.extend([
            '/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',
        ])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            resolved = shutil.which(name)
            if resolved:
                paths.append(resolved)
        paths.extend([
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ])

    # De-duplicate while preserving order
    seen = set()
    ordered = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            ordered.append(p)
    return ordered


def main():
    ap = argparse.ArgumentParser(description='Check local Chrome version against CVE-2026-10904 fixed builds.')
    ap.add_argument('--path', help='Explicit path to Chrome binary/exe', default=None)
    args = ap.parse_args()

    system = platform.system()
    fixed = FIXED_MAC if system == 'Darwin' else FIXED_DEFAULT

    paths = [args.path] if args.path else candidate_paths()
    found_any = False

    for path in paths:
        if not path:
            continue
        if not os.path.exists(path) and not shutil.which(path):
            continue
        found_any = True
        version = run_version(path)
        if not version:
            continue

        if version < fixed:
            print(f'VULNERABLE - {path} version {".".join(map(str, version))} < fixed {".".join(map(str, fixed))}')
            sys.exit(1)
        else:
            print(f'PATCHED - {path} version {".".join(map(str, version))} >= fixed {".".join(map(str, fixed))}')
            sys.exit(0)

    if not found_any:
        print('UNKNOWN - Chrome binary not found in common locations')
    else:
        print('UNKNOWN - Chrome found but version could not be determined')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a contained browser exploit, not an estate-wide host-RCE fire drill. Because the reassessed verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, you should inventory Chrome versions immediately, make sure update policy is actually working, and clean up unmanaged or pinned builds so everything moves to 149.0.7827.53/54 or later. The noisgate remediation SLA is ≤365 days, but given Chrome's endpoint footprint, most enterprises should finish well before that for high-risk users and unmanaged pockets rather than letting this age in backlog.

Sources

  1. Chrome Releases 2026 archive
  2. Chrome Early Stable Update for Desktop (149.0.7827.53/.54)
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. Chromium Site Isolation overview
  7. Chromium Site Isolation design document
  8. StatCounter browser market share in the United States
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.