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

Uninitialized Use in Dawn in Google Chrome prior to 149

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

This is a peephole in the browser wall, not a door kicked off its hinges

CVE-2026-11067 is an uninitialized-use information disclosure bug in Chrome's Dawn component, affecting Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. A remote attacker has to get a user onto a crafted web page, then abuse the memory-handling flaw to read data that should not be exposed from the browser process.

Google's MEDIUM 6.5 rating is directionally right, but still a bit generous for enterprise patch triage. The big limiter is that this is user-driven, client-side, and disclosure-only: no code execution, no sandbox escape, no privilege gain, and no evidence of active exploitation or public weaponization. On 10,000 endpoints, this matters because Chrome is everywhere—but it is still mostly a chain-enabler rather than the breach by itself.

"Patch it, but treat it like a browser infoleak—not a stand-alone enterprise fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user to attacker content

The attacker needs the victim to load a malicious page, ad, or embedded frame in a vulnerable Chrome build. The page must exercise the browser's graphics path in a way that reaches the affected Dawn code path.
Conditions required:
  • Victim runs Chrome prior to 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced web content
  • The vulnerable Dawn path is reachable in that browser/environment
Where this breaks in practice:
  • This is UI:R; no click, no bug
  • Enterprise web filtering, Safe Browsing, mail protection, and user isolation reduce the reachable population
  • Not every browsing session meaningfully reaches WebGPU/Dawn-heavy content
Detection/coverage: Version-based VM/EDR coverage is straightforward; pre-exploit network detection is weak because the trigger is just web content.
STEP 02

Trigger the uninitialized read in Dawn

Once the page is rendered, the crafted content coerces Dawn into using uninitialized memory. The result is an information disclosure primitive rather than direct memory corruption for code execution.
Conditions required:
  • Specific vulnerable code path is hit
  • Memory state aligns enough to leak useful bytes
Where this breaks in practice:
  • Uninitialized-use leaks are noisier and less deterministic than clean RCE primitives
  • Browser hardening and allocator behavior can reduce repeatability and usefulness
Detection/coverage: Exploit-attempt signatures are poor; defenders usually only see the vulnerable version, a browser crash, or abnormal renderer behavior.
STEP 03

Harvest browser-process secrets

The attacker attempts to recover useful data from disclosed process memory: tokens, fragments of cross-origin data, rendered content, or other transient secrets. The exact value depends heavily on what was resident in memory at the time of trigger.
Conditions required:
  • Leaked memory contains sensitive material
  • The attacker can parse and operationalize the leaked bytes
Where this breaks in practice:
  • Leak quality is highly situational
  • Information disclosure alone may yield nothing actionable on many runs
  • Modern browser isolation limits what any single process is holding
Detection/coverage: No reliable enterprise control sees 'memory leaked to JavaScript' directly; telemetry is mostly indirect.
STEP 04

Turn the leak into real impact

In the highest-value scenario, the disclosure is paired with another browser bug or with live session material already in memory. That can help defeat ASLR, expose tokens, or strengthen a broader exploit chain—but that second step is external to this CVE.
Conditions required:
  • Attacker has a follow-on use for leaked data
  • A second exploit, stolen session, or high-value browser secret is available
Where this breaks in practice:
  • This CVE does not provide code execution by itself
  • Meaningful enterprise impact usually requires a second bug or unusually valuable leaked data
Detection/coverage: Chained abuse may surface in downstream identity, session, or browser telemetry, but not as a clean signature for this CVE alone.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo KEV listing and I found no authoritative public evidence of active exploitation as of the June 2026 advisory window.
Public PoC availabilityNo credible public PoC located in the sources reviewed; disclosure details appear intentionally sparse while the fix rolls out.
EPSS0.00035 from the user-supplied intel block; that is very low, and no authoritative percentile was confirmed in source.
KEV statusNot listed in CISA KEV; no date-added or due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote and unauthenticated, but requires user interaction and yields confidentiality impact only.
Affected versionsChrome for Desktop prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows/macOS, per Google-linked advisories.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux; 149.0.7827.53/54 or later on Windows/macOS. Enterprise-managed Chromium derivatives should track equivalent vendor backports separately.
Scanning / exposure realityShodan/Censys-style internet census is not meaningful here because this is a client-side browser flaw, not an exposed listening service. Your exposure count is basically your vulnerable Chrome estate.
Disclosure date2026-06-04 from the supplied intel block; related vendor and government advisories appeared 2026-06-02 to 2026-06-05.
Reporter / researcherNot publicly attributed in the easily accessible vendor-facing sources reviewed.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.4/10)

The decisive factor is that this bug is post-click and disclosure-only: the attacker needs a user to browse attacker content, and the bug by itself does not hand over execution or privilege. Chrome's ubiquity keeps it relevant, but the absence of KEV/exploitation evidence and the need for a second step keep it out of the high-priority emergency lane.

HIGH Affected version range and fixed build
MEDIUM Real-world exploitability in enterprise environments
MEDIUM Public exploit status and PoC availability

Why this verdict

  • UI required drops urgency: this starts with the user loading attacker-controlled content, which immediately narrows reachable population compared with drive-by server flaws.
  • Info disclosure only is a real cap: this CVE leaks memory; it does not grant code execution, sandbox escape, or privilege elevation on its own, so it usually needs chaining.
  • Very low threat telemetry pulls it down: supplied EPSS is extremely low, there is no KEV entry, and no solid public weaponization surfaced in reviewed sources.
  • Wide footprint keeps it from going lower: Chrome is ubiquitous across enterprise fleets, so even a non-RCE browser bug still deserves cleanup at scale.

Why not higher?

If this were an RCE, sandbox escape, or KEV-listed browser zero-day, the score would jump fast. But this one needs user interaction, depends on hitting a specific browser component, and yields a leak whose practical value is inconsistent unless paired with something else.

Why not lower?

It is still a remote browser flaw in one of the most widely deployed applications in the enterprise, and confidentiality bugs in browsers can expose live session material or support exploit chaining. Dismissing it as mere hygiene would understate the fleet-wide exposure surface.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Make sure Chrome relaunch enforcement and version compliance reporting are working across the fleet. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should still be kept on the normal fast update rail because exposure is endpoint-wide.
  2. Disable or restrict WebGPU where business permits — If you have high-risk user groups or kiosk/VDI pools that do not need advanced browser GPU features, restricting WebGPU reduces reachable attack surface in the affected component. For MEDIUM, there is no mitigation SLA, so use this selectively where operationally easy rather than as an emergency program.
  3. Harden risky browsing paths — Apply existing browser isolation, web filtering, Safe Browsing enforcement, and ad/script controls to reduce the odds users ever reach attacker content. This does not replace patching, but it meaningfully cuts exploit delivery opportunities while remediation completes within the 365-day window.
  4. Prioritize high-value user rings — Patch executives, admins, finance, developers, and any unmanaged or frequently roaming endpoints first because the value of leaked browser memory is highest there. Even without a mitigation SLA, ring-based rollout is the pragmatic way to compress risk on a 10,000-host estate.
What doesn't work
  • A perimeter scanner will not save you here; this is a client browser bug, so external attack-surface tools cannot tell you who is vulnerable.
  • MFA does not block exploitation of the browser bug itself; at best it limits follow-on abuse if leaked memory exposes session artifacts that still need reauthentication.
  • A WAF is largely irrelevant because the exploit lives in browser-side content processing, not your inbound web application stack.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent with a local Python 3 interpreter. Invoke as python3 check_chrome_cve_2026_11067.py; it needs only standard user rights, though Windows registry access is used when available. It reports VULNERABLE, PATCHED, or UNKNOWN based on the installed Chrome version versus 149.0.7827.53.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11067.py
# Determine whether local Google Chrome is vulnerable to CVE-2026-11067
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

TARGET = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
    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:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_windows_version():
    try:
        import winreg
    except Exception:
        return None

    reg_paths = [
        (winreg.HKEY_CURRENT_USER, r'Software\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\Google\Chrome\BLBeacon'),
        (winreg.HKEY_LOCAL_MACHINE, r'SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon'),
    ]
    for hive, path in reg_paths:
        try:
            with winreg.OpenKey(hive, path) as key:
                value, _ = winreg.QueryValueEx(key, 'version')
                v = parse_version(str(value))
                if v:
                    return v
        except OSError:
            pass

    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 exe in candidates:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v
    return None


def get_macos_version():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for exe in candidates:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v
    return None


def get_linux_version():
    commands = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in commands:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v
    paths = [
        '/opt/google/chrome/google-chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/snap/bin/chromium',
        '/usr/bin/chromium-browser',
        '/usr/bin/chromium',
    ]
    for exe in paths:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v
    return None


def main():
    system = platform.system().lower()
    version = None

    if 'windows' in system:
        version = get_windows_version()
    elif 'darwin' in system:
        version = get_macos_version()
    elif 'linux' in system:
        version = get_linux_version()
    else:
        print('UNKNOWN - unsupported platform: {}'.format(platform.system()))
        sys.exit(2)

    if not version:
        print('UNKNOWN - could not determine Chrome version')
        sys.exit(2)

    if cmp_version(version, TARGET) < 0:
        print('VULNERABLE - installed Chrome version {} is older than {}'.format('.'.join(map(str, version)), '.'.join(map(str, TARGET))))
        sys.exit(1)
    else:
        print('PATCHED - installed Chrome version {} is at or above {}'.format('.'.join(map(str, version)), '.'.join(map(str, TARGET))))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as fleet hygiene with teeth, not an outage-level incident: verify Chrome auto-update and relaunch compliance, patch high-value user rings first, and use WebGPU restriction only where it is cheap and operationally safe. For a MEDIUM verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤365 days, though in practice you should roll this through your normal browser update channel far sooner than that because Chrome exposure scales with every endpoint.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases homepage / 2026 archive context
  3. Canadian Centre for Cyber Security AV26-544
  4. GovCERT.HK A26-06-08 Multiple Vulnerabilities in Google Chrome
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. CVE.org record URL
  8. Quanteta CVE tracker entry
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.