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

Use after free in Views in Google Chrome prior to 149

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

This is a weak interior door inside a building that already assumes the intruder got past the lobby

CVE-2026-10988 is a use-after-free in Chrome Views. The important qualifier is in the description itself: exploitation requires an attacker who has already compromised the renderer process. Affected builds are Chrome versions before 149.0.7827.53; Google pushed 149.0.7827.53/.54 to the Early Stable channel for Windows and Mac on 2026-05-29, and the same version number appeared on Beta for Windows, Mac, and Linux that day.

Google's HIGH 8.8 baseline is defensible if you score the bug as part of a browser exploit chain, because a renderer-to-browser escape can turn a web bug into host compromise. But for patch triage on a 10,000-endpoint fleet, this is not equivalent to a one-click unauthenticated remote RCE. The attacker must first win a separate renderer compromise, then successfully drive a fragile second-stage memory-corruption path, and modern Chrome defenses like sandboxing and Site Isolation exist specifically to make that chain harder.

"This is a second-stage Chrome sandbox-break candidate, not a clean initial-access bug"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain renderer execution with a separate bug

The attacker first needs arbitrary code execution or equivalent control inside a Chrome renderer process, typically via a different memory-corruption or logic bug delivered through web content. CVE-2026-10988 does not provide that entry point on its own; it only becomes relevant after the renderer is already hostile. Weaponization at this stage would use a custom renderer exploit chain rather than any public PoC identified for this CVE.
Conditions required:
  • User visits attacker-controlled or attacker-influenced content
  • A separate renderer compromise exists and works against the target build
  • Chrome sandbox and exploit mitigations are bypassed enough to keep the renderer under attacker control
Where this breaks in practice:
  • This is already a post-initial-compromise state inside the browser
  • No public PoC or turnkey exploit chain for this CVE was identified
  • Renderer exploits are version-sensitive and frequently brittle across channels and platforms
Detection/coverage: Version scanners cannot prove exploitability here; they only identify potentially affected Chrome builds. Detection at this stage comes from browser exploit telemetry, crash spikes, and EDR signals around suspicious browser behavior.
STEP 02

Reach the vulnerable Views path from the compromised renderer

With renderer control, the attacker would use a custom IPC/Mojo trigger to exercise the browser/UI-side Views code path that contains the dangling reference. This is the classic Chrome second-stage pattern: convert sandboxed renderer control into a more privileged browser-process memory corruption primitive. Public bug details were not available, so the exact message flow is presumably still restricted.
Conditions required:
  • Compromised renderer can talk to the relevant browser/UI interface
  • Target is running a vulnerable pre-149.0.7827.53 build
  • The vulnerable object lifetime is reachable in the victim's runtime state
Where this breaks in practice:
  • UI-path bugs are often stateful and timing-sensitive
  • Cross-version reliability usually drops fast when internals shift
  • Restricted bug details slow copycat weaponization
Detection/coverage: No network scanner will see this. Browser crash telemetry, minidumps, and exploit-guard style memory-corruption alerts are the best signals.
STEP 03

Trigger the use-after-free for privileged corruption

The attacker attempts to dereference a freed Views object and shape memory reuse to gain control over code flow or sensitive state in a more privileged process. In practice, this is where exploit engineering cost spikes: a crash is easy, reliable sandbox escape is not. The likely weapon here is a custom memory-corruption exploit, not an off-the-shelf toolkit.
Conditions required:
  • Precise heap manipulation is possible on the victim platform
  • Browser mitigations do not turn the condition into a safe crash first
  • The corrupted object leads to a useful primitive rather than simple denial of service
Where this breaks in practice:
  • Use-after-free bugs are notoriously unstable across allocator behavior and platform differences
  • Chrome hardening frequently converts exploit attempts into crashes
  • A browser-process primitive still may not equal full OS compromise
Detection/coverage: Likely observable as repeated Chrome crashes, abnormal browser restarts, or exploit-protection events rather than a neat signature. Traditional vuln scanners have no visibility into runtime exploit success.
STEP 04

Abuse the escape for impact

If the chain succeeds, the attacker can potentially break out of renderer containment and operate with browser-process privileges, enabling credential theft, cross-site data access, or follow-on local execution paths. This is why Chrome escape bugs matter operationally. But that impact only exists after a successful first-stage renderer compromise and a successful second-stage browser exploit.
Conditions required:
  • Second-stage exploit succeeds reliably enough to be useful
  • Target user session contains valuable browser data or enterprise access
  • EDR and local hardening do not interrupt post-exploitation
Where this breaks in practice:
  • Blast radius is per-compromised endpoint and per-user session, not internet-wide service exposure
  • EDR can still catch suspicious child-process, file-write, or credential-access behavior
  • Enterprise browsers auto-update quickly, shortening the useful exploit window
Detection/coverage: Look for browser spawning unusual children, suspicious access to profile data, credential stores, or abrupt post-crash recovery followed by suspicious activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found. The CVE was not present in CISA KEV at time of review, and I found no primary-source vendor statement claiming exploitation in the wild. Source: CISA KEV catalog
Proof-of-concept availabilityNo public PoC identified. I did not find a public repo, Metasploit module, or vendor-linked reproducer for CVE-2026-10988. Bug details appear restricted or not yet broadly published, which is normal for Chrome security fixes during rollout.
EPSS0.00035 per your intel, which is effectively background noise for enterprise prioritization. EPSS is a probability estimate for observed exploitation, not impact; FIRST's model docs explain that limitation: FIRST EPSS, API docs
KEV statusNot KEV-listed as of review. That matters because KEV absence removes the strongest urgency amplifier for browser bugs.
CVSS vector reality checkVendor vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, scored 8.8 HIGH. For defender triage, that overstates standalone reachability because the description itself adds a real-world prerequisite: the renderer must already be compromised.
Affected versionsChrome prior to 149.0.7827.53. Google announced 149.0.7827.53/.54 for Early Stable desktop on 2026-05-29: release post
Fixed versions149.0.7827.53/.54 or later for the affected desktop train. In practice, treat any later Chrome 149+ stable build as patched for this issue unless your packaging lags the vendor.
Exposure and scanningInternet exposure tools are mostly useless here. Shodan/Censys/FOFA do not meaningfully measure a client-side Chrome Views bug because this is endpoint software, not a remotely exposed server service. Your inventory source of truth is EDR, MDM, browser management, or software asset data—not external scanning.
Disclosure timingDisclosed 2026-06-04 per your intel, after the 2026-05-29 early-stable release that introduced the fixed desktop build number. That sequence is normal for Chrome: fix ships first, details follow later.
Researcher / reportingNo public reporter credit found in the sources reviewed for this specific CVE. Chrome frequently withholds detailed bug information until broad patch adoption; see the pattern in Chrome's security release notes archive: May 2026 release archive
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The single biggest downgrade factor is that this bug requires a pre-compromised renderer process, which makes it a second-stage exploit-chain component, not an initial-access vulnerability. With no KEV listing, no public PoC, and no evidence of active exploitation, the operational risk is real but materially narrower than the vendor's web-reachable CVSS framing suggests.

HIGH Exploit-chain friction from the renderer-compromise prerequisite
MEDIUM Affected/fixed version interpretation from public Chrome release material
MEDIUM Absence of public exploitation or PoC evidence at review time

Why this verdict

  • Major downgrade: requires prior renderer compromise — this is post-initial-access inside the browser, not a standalone drive-by host compromise.
  • Reachable population is narrower than CVSS implies — every internet user can be lured to a page, but only victims for whom an attacker also has a working first-stage renderer exploit can reach this bug.
  • Chrome's own architecture is designed for this exact threat model — sandboxing and Site Isolation reduce blast radius and raise exploit engineering cost even when the renderer is hostile.
  • No exploitation signal — no KEV entry, no public exploit repo, and an extremely low EPSS remove the strongest urgency amplifiers.
  • Still not ignorable — if chained with a renderer bug, a browser-process escape can convert a browser foothold into meaningful endpoint compromise.

Why not higher?

A higher rating would fit only if this were independently reachable from the web, had strong public exploit evidence, or were already in active campaigns. None of those conditions were present in the reviewed sources. The prerequisite of prior renderer compromise compounds with the lack of public tradecraft, pulling this well below emergency-tier browser response.

Why not lower?

This is still a Chrome sandbox-boundary problem, not a cosmetic crash. Chrome is ubiquitous, and second-stage browser escapes are exactly the kind of bugs high-end operators chain when they do have a renderer entry. So while the fleet-level urgency is lower than vendor HIGH, dropping it to LOW or IGNORE would understate the potential impact on targeted users and privileged browsing sessions.

05 · Compensating Control

What to do — in priority order.

  1. Verify browser auto-update health — Confirm your fleet is actually ingesting Chrome updates and relaunching into patched builds. For a MEDIUM verdict there is no mitigation SLA — fold this into the next normal browser operations cycle while ensuring endpoints do not remain stranded on old versions indefinitely.
  2. Preserve sandbox and Site Isolation defaults — Do not weaken Chrome with flags, legacy compatibility settings, or unmanaged variants that disable or erode renderer containment. This matters because the bug only pays off after renderer compromise; keeping containment intact reduces the chance the chain lands useful impact. For MEDIUM, there is no mitigation SLA — keep this as hardening hygiene, not emergency change work.
  3. Prioritize high-risk user rings — Move admins, developers, executives, researchers, and users handling sensitive SaaS sessions onto the latest Chrome build first. These populations get the worst outcome if a renderer exploit is ever paired with this bug. For MEDIUM, there is no mitigation SLA — use your next scheduled browser ring promotion.
  4. Watch for browser crash anomalies — Use EDR, crash telemetry, or helpdesk trend data to spot repeated Chrome crashes or suspicious browser child-process behavior that could indicate exploit testing. This is useful because version scanners cannot tell you whether anyone is attempting the second-stage chain. For MEDIUM, there is no mitigation SLA — add it to routine hunting and monitoring.
What doesn't work
  • A WAF does not materially help because this is a client-side browser memory bug, not a protected web application endpoint.
  • Perimeter scanning does not answer the real question; Shodan/Censys won't tell you which endpoints run vulnerable Chrome builds.
  • Network segmentation is mostly irrelevant to initial reachability because delivery happens through normal user web browsing, and the key prerequisite is renderer compromise.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/remote-exec tooling. Invoke it as python3 chrome_cve_2026_10988_check.py on macOS/Linux or py chrome_cve_2026_10988_check.py on Windows; standard user rights are usually enough because it only reads local version metadata from common Chrome install locations.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-10988 Chrome version check
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import subprocess
import sys
from pathlib import Path

FIXED = (149, 0, 7827, 53)


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


def cmp_version(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        r = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (r.stdout or '') + '\n' + (r.stderr or '')
        return out.strip()
    except Exception:
        return ''


def windows_candidates():
    roots = [
        os.environ.get('ProgramFiles', r'C:\Program Files'),
        os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'),
        os.environ.get('LocalAppData', ''),
    ]
    rels = [
        r'Google\Chrome\Application\chrome.exe',
        r'Google\Chrome Beta\Application\chrome.exe',
        r'Google\Chrome Dev\Application\chrome.exe',
    ]
    out = []
    for root in roots:
        if not root:
            continue
        for rel in rels:
            p = Path(root) / rel
            if p.exists():
                out.append(p)
    return out


def mac_candidates():
    return [
        Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        Path('/Applications/Google Chrome Beta.app/Contents/MacOS/Google Chrome Beta'),
        Path('/Applications/Google Chrome Dev.app/Contents/MacOS/Google Chrome Dev'),
        Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
    ]


def linux_candidates():
    names = ['google-chrome', 'google-chrome-stable', 'google-chrome-beta', 'google-chrome-unstable', 'chromium', 'chromium-browser']
    paths = []
    for name in names:
        out = run_cmd(['which', name])
        p = out.splitlines()[0].strip() if out else ''
        if p and Path(p).exists():
            paths.append(Path(p))
    return paths


def get_version_from_binary(path_obj):
    p = str(path_obj)
    if platform.system() == 'Windows':
        ps = [
            'powershell', '-NoProfile', '-Command',
            f"(Get-Item '{p.replace("'", "''")}').VersionInfo.ProductVersion"
        ]
        return parse_version(run_cmd(ps))
    else:
        return parse_version(run_cmd([p, '--version']))


def main():
    system = platform.system()
    if system == 'Windows':
        candidates = windows_candidates()
    elif system == 'Darwin':
        candidates = [p for p in mac_candidates() if p.exists()]
    else:
        candidates = linux_candidates()

    findings = []
    for c in candidates:
        ver = get_version_from_binary(c)
        findings.append((str(c), ver))

    findings = [(p, v) for p, v in findings if v is not None]

    if not findings:
        print('UNKNOWN: Chrome not found in common locations or version could not be parsed')
        sys.exit(2)

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

    if vulnerable:
        print('VULNERABLE')
        for path, ver in vulnerable:
            print(f'  {path} -> {".".join(map(str, ver))} < {".".join(map(str, FIXED))}')
        if patched:
            print('  Note: patched installations were also found:')
            for path, ver in patched:
                print(f'    {path} -> {".".join(map(str, ver))}')
        sys.exit(1)

    print('PATCHED')
    for path, ver in patched:
        print(f'  {path} -> {".".join(map(str, ver))} >= {".".join(map(str, FIXED))}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser fleet hygiene issue with targeted-user sensitivity, not an all-hands emergency. Inventory endpoints still running Chrome below 149.0.7827.53, confirm auto-update and relaunch are working, and push high-risk user rings through first. Because the reassessed verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; that means no mandatory temporary control deadline, and full patch remediation by 2027-06-04 under the noisgate remediation SLA. That said, for a ubiquitous browser, you should still clear this in your next regular browser update cycle rather than letting it age in backlog.

Sources

  1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases archive for May 2026
  3. Chromium Site Isolation overview
  4. Chromium Site Isolation design document
  5. Chromium Memory safety
  6. Chromium Secure Architecture
  7. CISA Known Exploited Vulnerabilities Catalog
  8. 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.