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

Use after free in Viz in Google Chrome prior to 149

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

This is a jailbreak tunnel hidden behind another locked door

CVE-2026-10918 is a use-after-free in Chrome's Viz/compositor stack. On affected builds prior to 149.0.7827.53—with Google showing 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux beta/branch alignment—a remote attacker could potentially turn a renderer compromise into a sandbox escape using crafted web content. That matters because Viz sits on the boundary between untrusted rendering and more privileged browser components.

Google's HIGH 8.3 score is technically fair for exploit-chain value, but it overstates standalone enterprise urgency. This bug does not give an unauthenticated internet attacker host compromise by itself; it assumes the attacker already landed code execution or equivalent control in the renderer. That prerequisite is major real-world friction, and with no KEV listing, no public exploitation signal, and a very low EPSS, this belongs below the top patch queue unless you're protecting high-risk browsing populations.

"High on paper, but this is a second-stage sandbox escape that needs a renderer compromise first."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Win the renderer first

The attacker needs a separate primitive to compromise Chrome's renderer process first—typically a renderer RCE, type confusion, logic flaw, or a malicious extension path. In practice this means CVE-2026-10918 is a chain component, not an entry bug. The weaponized tool here is the attacker's initial browser exploit or extension foothold, not Viz itself.
Conditions required:
  • Target is running a vulnerable Chrome build prior to 149.0.7827.53
  • Attacker can deliver malicious web content or another browser-stage exploit
  • A separate renderer-compromise primitive exists and succeeds
Where this breaks in practice:
  • Requires a prior compromise stage before this CVE matters
  • Modern browser mitigations, extension controls, and Safe Browsing reduce first-stage success
  • User interaction is normally required to reach attacker content
Detection/coverage: Version scanners can flag the vulnerable build, but they cannot prove exploitability because the renderer-compromise prerequisite is external to this CVE.
STEP 02

Drive the compromised renderer into Viz

Once inside the renderer, the attacker uses crafted HTML and rendering operations to exercise the Viz/compositor path. The goal is to shape object lifetime and IPC behavior so freed memory gets reused in a controllable way. The weaponized tool at this stage is a renderer-controlled HTML/graphics trigger path.
Conditions required:
  • Renderer code execution or equivalent control
  • Reachable Viz code path from attacker-controlled page activity
  • Correct browser build and heap state
Where this breaks in practice:
  • Exploit reliability is version-specific and heap-layout sensitive
  • A crash is more likely than a clean escape during development or failed attempts
  • Bug details are commonly restricted early in Chrome release cycles
Detection/coverage: Expect weak network visibility; useful signals are Chrome crash telemetry, repeated renderer/Viz instability, and endpoint browser crash artifacts.
STEP 03

Convert UAF into sandbox escape

If the use-after-free is exploited reliably, attacker control can cross from the sandboxed renderer into a more privileged process boundary. That is the real impact: escaping Chrome's renderer sandbox. The weaponized tool here is the Viz UAF itself, acting as the second-stage privilege boundary break.
Conditions required:
  • Successful reachability into the vulnerable Viz object lifecycle
  • Exploit primitives survive memory-safety defenses sufficiently to gain control
  • Target platform behavior matches the exploit assumptions
Where this breaks in practice:
  • Chrome's memory-hardening work in privileged processes materially raises failure rates
  • Not every sandbox escape yields durable arbitrary code execution on the host
  • A second-stage browser exploit is operationally rarer than single-bug web attacks
Detection/coverage: Remote scanning will miss this. Endpoint visibility may only see abnormal browser child processes, suspicious handle access, or post-escape file/network actions.
STEP 04

Turn browser escape into host objectives

After a successful escape, the attacker still has to translate that foothold into persistence, credential theft, lateral movement, or local privilege escalation. In enterprise reality, EDR, application control, and OS sandboxing often still contest the final move. The weaponized tool becomes commodity post-exploitation tradecraft rather than Chrome-specific exploitation.
Conditions required:
  • Successful sandbox escape
  • Valuable data or reachable follow-on actions on the endpoint
  • Defensive tooling does not block post-escape behavior
Where this breaks in practice:
  • EDR often catches browser-spawned payloads or suspicious memory behavior
  • Least-privilege desktops limit blast radius
  • Admin-separated browsing tiers reduce payoff on commodity endpoints
Detection/coverage: Strongest coverage is EDR on child-process creation, script interpreters, suspicious network beacons, and credential store access after browser activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation signal found in primary-source review, and not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC located in primary-source web/GitHub checks. That's expected for a Chrome sandbox escape that also needs a separate renderer bug.
EPSS0.00068 from the provided intel, which is extremely low and consistent with a niche, chain-dependent exploit.
KEV statusNot KEV-listed as of the disclosure window around 2026-06-04.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the vendor model captures chain value, but it hides the most important operational fact: this assumes prior renderer compromise.
Affected versionsGoogle Chrome prior to 149.0.7827.53. Google release posts show 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux beta/branch alignment.
Fixed versions149.0.7827.53 or later for Linux-aligned builds, and 149.0.7827.53/.54 on Windows/macOS release channels called out by Google.
Scanning and exposure realityNot internet-enumerable in the way server CVEs are. Shodan/Censys-style ASM is mostly irrelevant here; prioritize via endpoint/browser inventory and version telemetry.
Disclosure2026-06-04 per provided intel. Public bug details appear restricted, which is normal for Chrome until patch adoption improves.
Researcher / reportingUnknown publicly from available primary sources. Chrome often withholds bug metadata temporarily during rollout.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

The decisive downgrading factor is the attacker position requirement: this bug needs a renderer compromise first, which means it is not an initial-access web RCE by itself. That sharply narrows both the reachable population and the number of real attacks that can operationalize it, despite the serious technical impact if chained successfully.

HIGH The prerequisite chain materially lowers standalone severity
MEDIUM Affected version boundary and fixed release mapping
MEDIUM No public exploitation / PoC visibility at disclosure time

Why this verdict

  • Major prerequisite drag: exploitation requires the attacker to have already compromised the renderer process, which is a separate bug or foothold and turns this into a second-stage chain element.
  • Exposure is universal but reachability is not: Chrome is everywhere, but only a small fraction of attacks can chain a renderer compromise into a reliable Viz sandbox escape.
  • No exploitation pressure: no KEV listing, no public in-the-wild signal found, and the provided EPSS 0.00068 argue against emergency prioritization for the average enterprise fleet.

Why not higher?

This is not a clean one-click host takeover. The attacker needs user interaction plus a separate successful renderer compromise, and each prerequisite compounds downward pressure on real-world severity. For a 10,000-host patch queue, that makes it materially less urgent than pre-auth remote code execution or directly exploitable browser zero-days.

Why not lower?

A sandbox escape in Chrome still matters because browsers are high-value attack surfaces and this bug can be the difference between a contained renderer exploit and endpoint compromise. If paired with another browser bug, the blast radius can jump quickly, especially on high-risk users who browse untrusted content.

05 · Compensating Control

What to do — in priority order.

  1. Prioritize high-risk browser tiers — Move admins, executives, developers, researchers, and users who regularly browse untrusted sites onto the fixed Chrome build first. For a MEDIUM verdict there is no mitigation SLA, so treat this as targeted risk reduction while patching through normal remediation.
  2. Enforce browser auto-update and version visibility — Make sure Chrome update policies are not pinned behind stale rings and that endpoint telemetry reports exact browser versions. For MEDIUM, there is no mitigation SLA — go straight to standard remediation tracking, but you still want hard data on fleet coverage.
  3. Harden extension and browsing policy — Use Chrome enterprise policy to restrict unapproved extensions, isolate admin browsing, and reduce risky web content exposure where practical. This does not fix the bug, but it raises the cost of the first-stage renderer compromise this CVE depends on.
  4. Watch for browser-led post-exploitation — Tune EDR to alert on browser child processes, script interpreters launched from Chrome, suspicious file writes, and credential access following browser activity. With MEDIUM there is no mitigation SLA, but these detections are the best fallback if an exploit chain lands.
What doesn't work
  • A WAF does not protect endpoint browsers from a client-side memory corruption bug delivered through ordinary web content.
  • Perimeter vulnerability scanners are poor coverage here because the vulnerable asset is the user's browser, not an internet-facing service banner.
  • MFA is irrelevant to the exploit path; it may reduce downstream account abuse, but it does not stop renderer compromise or sandbox escape.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software management agent. Invoke it with python3 check_chrome_cve_2026_10918.py on macOS/Linux or py check_chrome_cve_2026_10918.py on Windows; no admin rights are required unless your EDR blocks process inspection. The script checks common Google Chrome install locations and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10918.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

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

FIXED = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, ...]]:
    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_cmd(cmd: List[str]) -> Optional[str]:
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
        return (p.stdout or p.stderr).strip() or None
    except Exception:
        return None


def version_from_exe(path: str) -> Optional[Tuple[int, ...]]:
    out = run_cmd([path, '--version'])
    if out:
        return parse_version(out)
    return None


def windows_versions() -> List[Tuple[str, Tuple[int, ...]]]:
    found = []
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    for path in candidates:
        if path and os.path.exists(path):
            v = version_from_exe(path)
            if v:
                found.append((path, v))

    # Registry fallback via PowerShell if executable probing fails
    if not found:
        ps = shutil.which('powershell') or shutil.which('pwsh')
        if ps:
            script = r"""
$paths = @(
 'HKLM:\SOFTWARE\Google\Chrome\BLBeacon',
 'HKLM:\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon',
 'HKCU:\SOFTWARE\Google\Chrome\BLBeacon'
)
foreach ($p in $paths) {
  if (Test-Path $p) {
    $v = (Get-ItemProperty -Path $p -ErrorAction SilentlyContinue).version
    if ($v) { Write-Output $v }
  }
}
"""
            out = run_cmd([ps, '-NoProfile', '-Command', script])
            if out:
                for line in out.splitlines():
                    v = parse_version(line.strip())
                    if v:
                        found.append(('registry', v))
    return found


def mac_versions() -> List[Tuple[str, Tuple[int, ...]]]:
    found = []
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            v = version_from_exe(path)
            if v:
                found.append((path, v))
    return found


def linux_versions() -> List[Tuple[str, Tuple[int, ...]]]:
    found = []
    binaries = [
        'google-chrome',
        'google-chrome-stable',
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
    ]
    for b in binaries:
        path = shutil.which(b) if not b.startswith('/') else b
        if path and os.path.exists(path):
            v = version_from_exe(path)
            if v:
                found.append((path, v))
    return found


def compare(v: Tuple[int, ...], fixed: Tuple[int, ...]) -> int:
    # returns -1 if v < fixed, 0 if equal, 1 if v > fixed
    if v < fixed:
        return -1
    if v > fixed:
        return 1
    return 0


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

    if 'windows' in system:
        installs = windows_versions()
    elif 'darwin' in system or 'mac' in system:
        installs = mac_versions()
    elif 'linux' in system:
        installs = linux_versions()
    else:
        print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
        return 2

    if not installs:
        print('UNKNOWN - Google Chrome not found in common install locations')
        return 2

    vulnerable = []
    patched = []

    for path, ver in installs:
        if compare(ver, FIXED) < 0:
            vulnerable.append((path, ver))
        else:
            patched.append((path, ver))

    if vulnerable:
        details = '; '.join(['{}={}'.format(p, '.'.join(map(str, v))) for p, v in vulnerable])
        print('VULNERABLE - found Chrome build(s) older than 149.0.7827.53: {}'.format(details))
        return 1

    details = '; '.join(['{}={}'.format(p, '.'.join(map(str, v))) for p, v in patched])
    print('PATCHED - all discovered Chrome build(s) are >= 149.0.7827.53: {}'.format(details))
    return 0


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a fleet-wide fire drill unless you have a separate signal that renderer-stage exploitation is in play. For a MEDIUM noisgate verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window; patch Chrome through normal browser servicing, but accelerate high-risk user tiers and any systems with looser browsing controls. If new exploitation evidence appears, reclassify immediately; absent that, your noisgate remediation SLA is ≤365 days for the broad fleet.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases - Chrome Beta for Desktop Update (149.0.7827.53)
  3. Chrome Releases - 2026 archive
  4. Google Security Blog - MiraclePtr: protecting users from use-after-free vulnerabilities on more platforms
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. FIRST EPSS overview
  8. Censys Internet Scanning 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.