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

Use after free in Network in Google Chrome prior to 149

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

This is the second lock on an already-opened door

CVE-2026-11249 is a use-after-free in Chrome's Network component affecting Google Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. On its own it does not give an internet attacker initial code execution; the attacker first needs to compromise the renderer process, then use this bug to read potentially sensitive memory through a crafted HTML page.

The vendor's MEDIUM 4.7 label is already restrained, but it still overstates day-one enterprise urgency a bit because CVSS does a poor job representing the already-compromised-renderer prerequisite. In real fleets this is a post-exploitation chain component with limited standalone blast radius, no KEV listing, and a tiny EPSS signal, so it lands as LOW for patch-priority purposes even though you still want it swept up in normal browser currency.

"This is a chain helper, not a frontline incident driver: it only matters after a renderer compromise."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land renderer compromise first

The attacker needs a separate browser bug or chain that yields code execution or equivalent control inside Chrome's renderer process. The weaponized step here is typically a crafted webpage plus a distinct renderer bug; CVE-2026-11249 is not that initial bug. Without renderer compromise, this CVE is inert.
Conditions required:
  • User visits attacker-controlled content
  • A separate renderer-compromise vulnerability exists and is successfully exploited
  • Target is running Chrome before 149.0.7827.53
Where this breaks in practice:
  • Modern Chrome sandboxing means attackers need another bug before this one matters
  • Email/web filtering, Safe Browsing, exploit mitigations, and site isolation reduce reliable first-stage compromise
  • This prerequisite implies the attacker is already past the hard part
Detection/coverage: Standalone vuln scanners can version-check for exposure, but they cannot prove exploitability because the prerequisite is a separate renderer compromise.
STEP 02

Trigger Network UAF from compromised renderer

Once inside the renderer, the attacker drives the vulnerable Network code path using crafted page behavior to hit the use-after-free. The likely tooling is custom exploit JavaScript/HTML paired with the prior renderer foothold and internal IPC/browser interactions.
Conditions required:
  • Attacker already controls renderer execution context
  • Reachable vulnerable Network code path
  • Memory layout favorable enough to recover useful data
Where this breaks in practice:
  • Use-after-free reliability varies by platform, build flags, and allocator behavior
  • Chrome's exploit mitigations and frequent releases shorten the viable window
  • Google kept the underlying issue detail gated behind a restricted issue tracker, limiting public weaponization data
Detection/coverage: EDR/browser telemetry may only show a renderer crash or abnormal browser behavior; signature-based detection for this specific UAF is weak.
STEP 03

Read sensitive process memory

The stated impact is confidentiality: the attacker may obtain sensitive information from process memory. Practically, that means this bug is better viewed as an info-leak primitive that can aid a larger chain, not as a direct enterprise-takeover bug.
Conditions required:
  • Successful UAF exploitation after renderer compromise
  • Valuable secrets resident in accessible process memory at exploit time
Where this breaks in practice:
  • Impact is limited to information disclosure, not direct integrity or availability loss
  • Recovered data may be noisy, partial, or low-value depending on timing
  • Blast radius is usually the current browser/session context, not the whole endpoint
Detection/coverage: Memory disclosure is hard to observe directly; defenders mostly rely on crash analytics, browser update compliance, and correlation with adjacent browser exploit activity.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found; not in CISA KEV as of the current catalog review.
Proof-of-concept availabilityNo public PoC located from primary sources. The Chromium issue is restricted, which usually slows copycat exploitation for low-severity chain bugs.
EPSSProvided intel shows 0.00025, which is extremely low. Percentile was not verified from a primary EPSS record during this assessment.
KEV statusNot KEV-listed. That matters because Chrome chain helpers that get real traction often show up quickly in public exploitation reporting or emergency advisories.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N — the score reflects remote reach plus user interaction, but it under-models the renderer-compromise prerequisite called out in the description.
Affected versionsGoogle Chrome prior to 149.0.7827.53; vendor release notes show Linux at 149.0.7827.53 and Windows/macOS at 149.0.7827.53/54.
Fixed versionsFixed in Chrome 149 stable: Linux 149.0.7827.53, Windows/macOS 149.0.7827.53/54. openSUSE also references Chromium 149.0.7827.53 in maintenance patching.
Scanning / exposure dataInternet scan data from Shodan/Censys/FOFA is not especially meaningful here because this is a client-side browser flaw, not a server-side exposed service. Your true exposure metric is endpoint/browser version inventory.
TimelineChrome 149 stable shipped on 2026-06-02; the NVD record for this CVE was published on 2026-06-04; CISA-ADP CVSS enrichment appears on 2026-06-05.
ReporterVendor advisory lists this issue as reported by Google on 2026-03-31, not by an external researcher.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive factor is the attacker position requirement: this bug only becomes useful after an attacker has already compromised Chrome's renderer process. That makes it a narrow, post-initial-exploitation confidentiality primitive rather than a practical initial-access path across a 10,000-host fleet.

HIGH Assessment that the renderer-compromise prerequisite materially suppresses real-world severity
MEDIUM Assessment that public weaponization remains limited due to restricted bug details and no PoC found

Why this verdict

  • Major downward pressure: requires prior renderer compromise — this is not unauthenticated remote-to-impact by itself; it assumes the attacker already beat Chrome once.
  • Impact is bounded to information disclosure — the published effect is memory disclosure, not direct code execution, sandbox escape, or endpoint takeover.
  • Population-wide exploitability is narrow — every real deployment must satisfy user browsing, renderer compromise, vulnerable version, and successful UAF reliability; each prerequisite compounds downward pressure.
  • Exploit economics are poor — no KEV listing, no public exploitation evidence found, and a very low EPSS score all argue against urgent adversary focus.
  • Endpoint controls should break the chain earlier — Safe Browsing, exploit mitigations, EDR, and web filtering are more likely to stop the prerequisite stage than this bug itself.

Why not higher?

It is not higher because the vulnerability is explicitly post-compromise within the browser attack chain. If the description said a remote attacker could trigger it directly from a webpage without first compromising the renderer, this would score materially higher despite the confidentiality-only impact.

Why not lower?

It is not IGNORE because Chrome is ubiquitous and attackers do chain low-severity browser bugs when they already have a suitable first-stage primitive. Even a narrow memory disclosure bug can improve exploit reliability or leak material that helps a broader browser compromise.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Push Chrome/Chromium onto managed auto-update rings and verify version compliance across endpoints. For a LOW verdict there is no mitigation SLA; treat this as normal hygiene and get the actual fixed build deployed through your standard browser currency process.
  2. Reduce untrusted browsing surface — Route high-risk users through stronger web isolation, category filtering, or remote browser isolation where available. This does not fix the bug, but it reduces the odds that an attacker can land the prerequisite renderer compromise that this CVE depends on.
  3. Hunt for stale Chrome builds — Use EDR, software inventory, or config management to identify endpoints still below 149.0.7827.53. For a LOW verdict there is no mitigation SLA; fold this into your regular browser update cleanup and exception management.
  4. Prioritize adjacent browser alerts — If you see renderer crashes, exploit protection alerts, suspicious browser child-process behavior, or reports of other Chrome RCEs, raise the priority of this CVE in those affected cohorts. The bug matters most as part of a chain, so context should drive action.
What doesn't work
  • WAFs and perimeter IPS don't meaningfully protect a client-side browser memory-safety bug delivered through normal web content.
  • MFA is irrelevant to the exploit path; this is about browser process state, not account login hardening.
  • Relying on KEV absence alone is not enough for exceptioning; KEV is a useful signal, but the right reason to downgrade here is the renderer-compromise prerequisite, not merely the lack of a KEV entry.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent. Invoke it with python3 check_chrome_cve_2026_11249.py on macOS/Linux or py check_chrome_cve_2026_11249.py on Windows; no admin rights are usually needed unless your management tooling restricts process execution or registry reads.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11249.py
# 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(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_ver(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=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def windows_version():
    try:
        import winreg
    except Exception:
        return None, None

    reg_paths = [
        (winreg.HKEY_CURRENT_USER, r'Software\\Google\\Chrome\\BLBeacon', 'version'),
        (winreg.HKEY_LOCAL_MACHINE, r'Software\\Google\\Chrome\\BLBeacon', 'version'),
        (winreg.HKEY_LOCAL_MACHINE, r'Software\\WOW6432Node\\Google\\Chrome\\BLBeacon', 'version'),
    ]
    for hive, path, name in reg_paths:
        try:
            key = winreg.OpenKey(hive, path)
            val, _ = winreg.QueryValueEx(key, name)
            ver = parse_version(str(val))
            if ver:
                return 'Google Chrome', ver
        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'])
            ver = parse_version(out)
            if ver:
                return exe, ver
    return None, None


def mac_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'])
            ver = parse_version(out)
            if ver:
                return exe, ver
    return None, None


def linux_version():
    names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']
    for name in names:
        exe = shutil.which(name)
        if exe:
            out = run_cmd([exe, '--version'])
            ver = parse_version(out)
            if ver:
                return exe, ver
    return None, None


def main():
    system = platform.system().lower()
    source, ver = None, None

    if 'windows' in system:
        source, ver = windows_version()
    elif 'darwin' in system:
        source, ver = mac_version()
    else:
        source, ver = linux_version()

    if not ver:
        print('UNKNOWN - Google Chrome/Chromium version not found')
        sys.exit(2)

    ver_str = '.'.join(str(x) for x in ver)
    fixed_str = '.'.join(str(x) for x in FIXED)

    if cmp_ver(ver, FIXED) < 0:
        print(f'VULNERABLE - detected {ver_str} from {source}; fixed version is {fixed_str} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - detected {ver_str} from {source}; fixed baseline is {fixed_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as fleet hygiene, not an interrupt-driven fire. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for the actual browser update, but in practice Chrome should already be on your fast evergreen track, so use your normal browser compliance process to get everything to 149.0.7827.53/54 and close exceptions well before the noisgate remediation SLA outer bound; only accelerate to immediate attention if you uncover a matching renderer-compromise campaign or adjacent Chrome exploit activity in your environment.

Sources

  1. NVD CVE-2026-11249
  2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue 497989379
  4. Chrome 149 release notes
  5. Chrome Releases: Early Stable Update for Desktop (May 29, 2026)
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. openSUSE Chromium 149 patchinfo
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.