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.
3 steps from start to impact.
Land renderer compromise first
- User visits attacker-controlled content
- A separate renderer-compromise vulnerability exists and is successfully exploited
- Target is running Chrome before
149.0.7827.53
- 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
Trigger Network UAF from compromised renderer
- Attacker already controls renderer execution context
- Reachable vulnerable Network code path
- Memory layout favorable enough to recover useful data
- 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
Read sensitive process memory
- Successful UAF exploitation after renderer compromise
- Valuable secrets resident in accessible process memory at exploit time
- 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
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found; not in CISA KEV as of the current catalog review. |
|---|---|
| Proof-of-concept availability | No public PoC located from primary sources. The Chromium issue is restricted, which usually slows copycat exploitation for low-severity chain bugs. |
| EPSS | Provided intel shows 0.00025, which is extremely low. Percentile was not verified from a primary EPSS record during this assessment. |
| KEV status | Not KEV-listed. That matters because Chrome chain helpers that get real traction often show up quickly in public exploitation reporting or emergency advisories. |
| CVSS vector | CVSS: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 versions | Google 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 versions | Fixed 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 data | Internet 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. |
| Timeline | Chrome 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. |
| Reporter | Vendor advisory lists this issue as reported by Google on 2026-03-31, not by an external researcher. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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. - 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.
- 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.
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.
#!/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()
If you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.