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

Out of bounds read in Dawn in Google Chrome prior to 149

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

This is a second-story window, not the front door

CVE-2026-10927 is an out-of-bounds read in Chrome's Dawn component, the graphics layer behind WebGPU, fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS. The key catch is in Google's own description: the attacker must have already compromised the renderer process before this bug becomes useful, which makes it a post-compromise browser-chain primitive rather than a clean one-shot drive-by.

Google rated it HIGH (8.3), which is fair if you score pure technical impact inside a browser exploit chain. For enterprise patch triage, though, that overstates the standalone risk: this bug requires a prior browser exploit stage, lives behind Chrome's sandbox and Site Isolation design, has no KEV listing, very low EPSS, and no public in-the-wild exploitation evidence located. That combination pushes it down to MEDIUM for most fleets.

"High on paper, medium in practice: this only matters after the attacker already owns the renderer."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land malicious browser content

The attacker first needs the target to render hostile web content, typically via a phishing link, ad-tech delivery, or a compromised site. The practical weapon here is a custom HTML/JavaScript harness that reaches GPU/WebGPU code paths; I did not locate a public PoC repo specific to CVE-2026-10927.
Conditions required:
  • User browses to attacker-controlled or attacker-influenced content
  • Chrome version is older than the fixed build
  • Relevant Dawn/WebGPU code path is reachable on the platform
Where this breaks in practice:
  • This is still UI-required browser exposure, not unauthenticated service exposure
  • Many enterprise web gateways, URL filtering stacks, and browser isolation products reduce delivery success
  • WebGPU reachability can vary by platform, feature state, and enterprise policy
Detection/coverage: Commodity scanners can usually detect outdated Chrome versions, but they cannot prove exploitability of the Dawn path from outside the host.
STEP 02

Compromise the renderer first

This CVE does not provide the initial foothold by itself. The attacker needs a separate renderer exploit or logic flaw first; the effective tool is a distinct renderer-stage exploit chain paired with the malicious page. This prerequisite is the biggest downward pressure on severity because it implies the attacker has already cleared the hardest browser barrier.
Conditions required:
  • A separate renderer compromise exists and is reliable enough to run first
  • The victim's browser hardening and patch level still allow that first-stage exploit
Where this breaks in practice:
  • Reliable modern Chrome renderer exploitation is expensive and noisy to develop
  • Browser auto-update, exploit mitigations, and sandboxing sharply reduce the usable population
  • Most opportunistic threat actors do not burn two-stage browser chains on broad enterprise users
Detection/coverage: EDR may catch renderer crashes, abnormal child-process behavior, or exploit-like memory events, but browser exploit detection remains uneven.
STEP 03

Trigger Dawn out-of-bounds read

With renderer control in hand, the attacker exercises the vulnerable Dawn code path to obtain an out-of-bounds read primitive. The likely weapon is still the same custom WebGPU/graphics harness, now driven from an already-compromised renderer context, to sample adjacent process memory and extract useful data.
Conditions required:
  • Compromised renderer can invoke the vulnerable Dawn path
  • Memory layout and code path are stable enough for useful reads
Where this breaks in practice:
  • Out-of-bounds read is weaker than a direct write or use-after-free RCE primitive
  • Memory disclosure alone often needs additional grooming and chaining to become operationally valuable
  • Platform-specific behavior in GPU stacks can hurt exploit reliability
Detection/coverage: Version-only checks will miss active abuse; there is little signature-grade network detection for a renderer-resident Dawn memory disclosure.
STEP 04

Use the leak to advance the chain

The attacker uses stolen memory to bypass mitigations, expose sensitive data in-process, or improve a follow-on sandbox-escape/browser-privilege step. The weaponized outcome is a multi-bug exploit chain, not a single-CVE win, and that matters: impact can be high, but only after several prerequisites line up.
Conditions required:
  • Leaked memory contains secrets, pointers, or cross-context data valuable to the attacker
  • A follow-on chain stage exists to convert the read into meaningful compromise
Where this breaks in practice:
  • Chrome's sandbox and Site Isolation limit what a compromised renderer should be able to reach directly
  • Cross-site and OS-level impact typically needs another bug or policy weakness
  • Many enterprise sessions do not contain high-value browser-resident secrets at the moment of exploitation
Detection/coverage: Post-exploitation detections shift to EDR, identity telemetry, and browser forensics; no mainstream scanner will confirm this chain stage directly.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public in-the-wild exploitation evidence located as of 2026-06-05; not listed in CISA KEV.
KEV statusNo — absent from the CISA Known Exploited Vulnerabilities Catalog.
PoC availabilityNo public PoC or turnkey exploit repo for CVE-2026-10927 was located. Expect only custom exploit-chain code if this is used at all.
EPSS0.00068 from user-supplied intel; that is a very low exploitation probability signal relative to internet-facing mass-exploitation candidates. Source framework: FIRST EPSS.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the big tells are AC:H and UI:R, and Google's description adds an even more important real-world prerequisite: renderer compromise first.
Affected versionsChrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/.54 on Windows/macOS, per the stable release notes.
Fixed versionsPatched in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS. Chrome's Android stable release notes state desktop security fixes generally carry over to the corresponding mobile release.
Exposure populationChrome is ubiquitous in enterprise, but this is client-side endpoint exposure, not directly measurable internet service exposure. Shodan/Censys/FOFA-style internet scans are not meaningful for prioritizing this CVE.
Disclosure date2026-06-04 in the advisory data you supplied; the stable channel security release published 2026-06-02 and includes the fixed CVE.
ReporterReported by Google on 2026-04-06 in the Chrome stable channel security notes.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The decisive factor is the prerequisite that the attacker must already have compromised the renderer process. That turns this from a broad drive-by browser risk into a post-initial-exploitation chain component with a much smaller reachable population and much higher attacker cost.

HIGH Affected/fixed version mapping from Google's release notes
MEDIUM Severity downgrade based on real-world exploit-chain friction
MEDIUM Assessment that no public PoC/in-the-wild evidence is currently available

Why this verdict

  • Renderer compromise required: this is not a clean remote entry point; it assumes the attacker already beat Chrome once, which is major downward pressure on urgency.
  • Client-side, UI-driven exposure: the reachable population is every browser endpoint in theory, but exploitation still depends on users rendering hostile content and the attacker having a working first-stage renderer exploit.
  • Low threat telemetry: no KEV listing, no located public PoC, and a very low EPSS all argue against broad opportunistic exploitation right now.

Why not higher?

If this were a standalone remote code execution bug or an immediately weaponizable sandbox escape with public exploitation evidence, it would stay in HIGH or higher. But the chain starts with 'attacker already owns the renderer', which means this CVE is mostly useful to advanced operators already carrying a separate browser exploit stage.

Why not lower?

This still sits inside Chrome, one of the most widely deployed enterprise applications on the planet, and browser exploit chains remain strategically valuable. Even a read primitive can matter for mitigation bypass, secret leakage, or stabilizing a follow-on escape, so writing it off as backlog-only would be too casual.

05 · Compensating Control

What to do — in priority order.

  1. Force evergreen browser updates — Make sure Chrome auto-update is enforced and that stragglers are surfaced in fleet management. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window, but for browsers you should still close version drift quickly because chained browser bugs age badly.
  2. Tighten WebGPU and risky browser features where not needed — If business workflows do not require WebGPU or advanced graphics features, restrict them through enterprise policy for high-risk user groups and unmanaged browsing tiers. There is no mitigation SLA for MEDIUM here; treat this as hardening that reduces exploit-chain surface while you remediate within the 365-day window.
  3. Protect high-risk users with browser isolation or stronger web filtering — Executives, admins, developers, and helpdesk operators are the people worth spending a two-stage browser chain on. Apply stronger link isolation, category filtering, or remote browser isolation to those cohorts to make stage-one delivery and renderer compromise materially harder.
  4. Monitor for stale Chrome populations — Inventory endpoints that missed the Chrome 149 rollout and treat them as hygiene debt. MEDIUM means no mitigation SLA, but it does not mean you should tolerate unknown browser versions across a 10,000-host fleet.
What doesn't work
  • A network perimeter scanner won't tell you whether the vulnerable Dawn path is reachable or whether WebGPU is enabled on endpoints; this is client software, not a server socket problem.
  • MFA is valuable for downstream account abuse, but it does not stop the browser memory bug itself.
  • A generic WAF is largely irrelevant here because the exploit executes in the browser client, not against your web app edge.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/EDR remote execution layer. Save as check_cve_2026_10927.py and invoke with python3 check_cve_2026_10927.py on macOS/Linux or py check_cve_2026_10927.py on Windows; no admin rights are required if the browser is installed in standard locations.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Chrome/Chromium version against CVE-2026-10927 fixed builds
# 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 pathlib import Path

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 version_ge(a, b):
    return a >= b


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


def candidates_windows():
    paths = []
    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 not base:
            continue
        for suf in suffixes:
            p = Path(base) / Path(suf)
            paths.append(str(p))
    return paths


def candidates_macos():
    return [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
        str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        str(Path.home() / 'Applications/Chromium.app/Contents/MacOS/Chromium'),
    ]


def candidates_linux():
    return [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
        '/opt/google/chrome/chrome',
    ]


def detect_version():
    system = platform.system().lower()
    paths = []

    if 'windows' in system:
        paths = candidates_windows()
    elif 'darwin' in system:
        paths = candidates_macos()
    else:
        paths = candidates_linux()

    for path in paths:
        if Path(path).exists():
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return path, ver, out

    # Fallback to PATH resolution
    for cmd in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        out = run_cmd([cmd, '--version'])
        ver = parse_version(out)
        if ver:
            return cmd, ver, out

    return None, None, None


def main():
    path, ver, raw = detect_version()
    if not ver:
        print('UNKNOWN')
        sys.exit(2)

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


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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser hygiene issue, not an incident-level fire drill. Because the reassessed verdict is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; that means getting endpoints to Chrome 149.0.7827.53/54 or later by June 4, 2027 under the noisgate remediation SLA. In practice, for a 10,000-host fleet, push the update in your next managed browser wave, identify machines with broken auto-update, and reserve priority handling for high-risk user groups and any endpoints stuck on older Chrome branches.

Sources

  1. Chrome Stable Channel Update for Desktop (June 2, 2026)
  2. Chromium issue 500090141
  3. Chromium Security homepage
  4. Chromium Docs - Threat Model and Defenses Against Compromised Renderers
  5. Chromium Site Isolation
  6. CISA Known Exploited Vulnerabilities Catalog
  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.