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

Out of bounds write in V8 in Google Chrome prior to 149

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

This is a second lock on the same door, not a front-door break-in

CVE-2026-11173 is an out-of-bounds write in V8 affecting Google Chrome versions before 149.0.7827.53; Google's May 29, 2026 early-stable release moved desktop builds to 149.0.7827.53/.54. The key detail is the prerequisite baked into the description: the attacker must already have *compromised the renderer process* before this bug becomes useful.

That makes the vendor's HIGH 8.8 look overstated for patch-priority purposes in a large enterprise. Technically, the bug may be valuable as a sandbox-escape or privilege-step inside a browser exploit chain, but operationally it is not a standalone drive-by RCE against a fully patched workstation; it requires a prior exploit stage, has no KEV entry, no public exploitation evidence in the supplied intel, and an extremely low EPSS.

"Dangerous in a browser exploit chain, but not a one-bug internet-to-host compromise"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the first-stage renderer compromise

The attacker still needs a separate bug to get code execution or equivalent control inside Chrome's sandboxed renderer. In practice this means a malicious page, ad slot, or content path that triggers an independent renderer exploit; CVE-2026-11173 is not that initial foothold by itself. *Weaponized tool:* a private browser exploit chain or malicious HTML/JS stage, not a public scanner.
Conditions required:
  • Victim must browse attacker-controlled content or otherwise render hostile web content
  • Attacker needs a separate working renderer compromise first
Where this breaks in practice:
  • This is a hard prerequisite: no initial renderer bug, no path to this CVE
  • Modern browser hardening, Safe Browsing, and exploit mitigations filter out a lot of opportunistic chains
Detection/coverage: Remote scanners cannot validate this step. Detection is mostly indirect: browser crash telemetry, exploit-protection alerts, and EDR memory-protection events.
STEP 02

Trigger the V8 out-of-bounds write from inside the compromised renderer

Once the renderer is already under attacker control, the attacker can exercise the vulnerable V8 path to corrupt memory in a more useful way. *Weaponized tool:* custom V8 exploit primitives embedded in the same chain. This step is architecture- and build-sensitive, and reliability matters more than raw reachability.
Conditions required:
  • Attacker already controls execution flow or strong primitives inside the renderer
  • Target is running a vulnerable Chrome build before 149.0.7827.53
Where this breaks in practice:
  • The bug adds value only after a prior compromise stage
  • Exploit reliability typically varies by OS build, Chrome build, and mitigation state
Detection/coverage: Very limited pre-exploit scanner coverage. Post-factum signals are crash dumps, unusual renderer termination, or exploit-mitigation telemetry.
STEP 03

Cross the sandbox boundary

Chrome's security model puts the renderer in a restricted target process and relies on a more privileged browser broker for policy-allowed actions. To matter operationally, the attacker must turn the V8 memory corruption into code execution or policy abuse that escapes the renderer's confinement. *Weaponized tool:* broker-IPC abuse or a chained escape payload.
Conditions required:
  • A workable post-corruption primitive is needed, not just a crash
  • A reachable broker or sandbox boundary crossing path must exist
Where this breaks in practice:
  • Chromium's sandbox is specifically designed to constrain compromised renderers
  • OS exploit mitigations and broker policy checks reduce the success rate of generic payloads
Detection/coverage: EDR can sometimes see abnormal child processes, suspicious broker interaction, or memory-execution behavior. Conventional vulnerability scanners usually cannot.
STEP 04

Run code with user-context impact

If the chain works end-to-end, the attacker graduates from a contained renderer compromise to code execution with materially higher impact on the endpoint. *Weaponized tool:* final-stage shellcode or loader. At that point the blast radius is the logged-in user's workstation and whatever that identity can reach.
Conditions required:
  • Successful exploitation of all prior stages
  • Endpoint protections do not block the final payload
Where this breaks in practice:
  • EDR, application control, and downstream privilege barriers still matter after sandbox escape
  • The result is typically user-context compromise, not automatic domain-wide blast radius
Detection/coverage: Good EDR should have the best chance here: anomalous process trees, injection, persistence attempts, or suspicious outbound C2.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence supplied of active exploitation, and not KEV-listed in CISA's catalog as reviewed.
Proof-of-concept availabilityNo public PoC, Metasploit module, or mainstream GitHub exploit surfaced in primary-source review. This looks like private-chain material, not commodity tradecraft.
EPSS0.0008 from the supplied intel; that is effectively near-floor probability and argues against urgent broad-sweep prioritization.
KEV statusNot listed in CISA KEV; no KEV added date.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — this scores like a classic remote user-interaction browser bug, but the real-world description adds a crucial hidden prerequisite: prior renderer compromise.
Affected versionsGoogle Chrome before 149.0.7827.53 per the supplied intel.
Fixed versionsPatch floor is 149.0.7827.53 from the supplied intel; Google's desktop early-stable post says 149.0.7827.53/.54 on Windows and Mac on 2026-05-29.
Exposure / scanning realityShodan/Censys/GreyNoise-style internet exposure data is not very meaningful here because Chrome is endpoint client software, not a server-side listener. This is an endpoint hygiene and exploit-chain problem, not an exposed-service problem.
Disclosure date2026-06-04 from the supplied intel.
Reporter / creditNo authoritative public reporter credit was identified in the sources reviewed.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The decisive factor is the attacker-position requirement: this bug only matters after the renderer is already compromised, which means it is post-initial-access inside the browser exploit chain. That sharply narrows the reachable population compared with a true standalone drive-by Chrome RCE, so it does not deserve emergency fleet-wide treatment absent exploitation evidence.

HIGH Renderer-compromise prerequisite materially lowers enterprise patch priority
MEDIUM Affected-version and fix-floor mapping from public release notes versus supplied CVE text

Why this verdict

  • Start from the vendor's 8.8 baseline, then subtract for attacker position: this is not unauthenticated internet-to-host by itself; it requires a separate renderer compromise first, which is a major downward adjustment of roughly -2.0.
  • Subtract for weak threat heat: no KEV listing, no public exploitation evidence in the supplied intel, and EPSS 0.0008 justify another -0.7.
  • Subtract for limited practical reach: Chrome is everywhere, but this CVE is useful mainly to attackers already building reliable multi-stage browser chains rather than opportunistic mass exploitation, which trims another -0.5.

Why not higher?

If this were a standalone remote browser RCE from a crafted page, the vendor's HIGH would be fair and maybe conservative. But the explicit need for a prior renderer compromise means the exploit chain already depends on another bug, which is exactly the kind of compounding friction that should push severity down for enterprise triage.

Why not lower?

This is still an out-of-bounds write in a massively deployed browser engine, and if it completes a chain the impact on a workstation is real. For targeted attackers who already have the first-stage renderer foothold, this kind of bug can be the difference between a harmless sandboxed crash and meaningful endpoint compromise.

05 · Compensating Control

What to do — in priority order.

  1. Enforce a Chrome version floor — Use your browser management stack, EDR software inventory, or endpoint config management to flag any Chrome build below 149.0.7827.53 as noncompliant. Because this is a MEDIUM verdict, there is no mitigation SLA — go straight to the 365-day remediation window and clear the long tail through normal client patch hygiene.
  2. Kill --no-sandbox exceptions — Audit shortcuts, app wrappers, VDI launchers, kiosk configs, and developer images for Chrome launched with --no-sandbox or similar weakened configurations. That setting removes the exact friction that keeps this CVE from being a bigger operational problem; fix it during the same standard remediation cycle.
  3. Prefer managed browser channels only — Block unmanaged portable browsers and stale side-loaded Chrome installs so you are not chasing invisible laggards outside normal auto-update. This should be folded into standard endpoint governance during the same remediation window.
  4. Watch for browser exploit signals — Make sure EDR captures browser child-process anomalies, memory-protection alerts, and repeated renderer crashes. It will not prevent the bug, but it gives you the best detection chance if an attacker is actually using a chain involving this issue.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much because this is endpoint client software, not an exposed server surface.
  • A WAF or reverse proxy does not meaningfully mitigate a local browser-engine memory corruption bug triggered in the client.
  • MFA and password rotation are good hygiene but do not block renderer-to-sandbox-escape exploit chains on the endpoint.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your remote execution platform as a normal user; admin rights are usually not required. Save it as check_chrome_cve_2026_11173.py and run python3 check_chrome_cve_2026_11173.py on macOS/Linux or py check_chrome_cve_2026_11173.py on Windows.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for CVE-2026-11173 exposure by local Chrome version
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

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

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_version(cmd):
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return out.strip()
    except Exception:
        return None


def candidate_commands():
    system = platform.system()
    cmds = []

    if system == 'Windows':
        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'),
        ]
        for p in paths:
            if p and os.path.exists(p):
                cmds.append([p, '--version'])
    elif system == 'Darwin':
        mac_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
        if os.path.exists(mac_path):
            cmds.append([mac_path, '--version'])
        for name in ['google-chrome', 'chrome', 'chromium', 'chromium-browser']:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
            found = shutil.which(name)
            if found:
                cmds.append([found, '--version'])

    return cmds


def main():
    seen = []
    for cmd in candidate_commands():
        out = run_version(cmd)
        if not out:
            continue
        ver = parse_version(out)
        if ver:
            seen.append((cmd[0], ver, out))

    if not seen:
        print('UNKNOWN - Google Chrome executable not found or version could not be parsed')
        sys.exit(2)

    # Pick the highest discovered version if multiple installs exist
    path, ver, raw = sorted(seen, key=lambda x: x[1], reverse=True)[0]

    print(f'Detected: {path} -> {raw}')
    print(f'Fixed floor: {".".join(map(str, FIXED))}')

    if ver < FIXED:
        print('VULNERABLE')
        sys.exit(1)
    else:
        print('PATCHED')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like an emergency fleet interrupt unless fresh exploitation evidence appears. Put Chrome version auditing into your normal endpoint hygiene sweep, verify endpoints move to at least 149.0.7827.53 (and account for the desktop early-stable 149.0.7827.53/.54 release nuance on Windows/Mac), and clean up any --no-sandbox or unmanaged-browser exceptions; because this reassesses to MEDIUM with no KEV or active exploitation evidence, there is noisgate mitigation SLA — go straight to the 365-day remediation window, and complete patch rollout inside the noisgate remediation SLA of 365 days.

Sources

  1. Chrome Releases: Early Stable Update for Desktop
  2. Chromium Sandbox FAQ
  3. Chromium Sandbox Design (Windows broker/target model)
  4. Chromium Linux Sandbox README
  5. Chromium Multi-Process Architecture
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API Documentation
  8. FIRST EPSS FAQ
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.