Like a thief who only gets in after you hand over a staff badge and open the side door
CVE-2026-11238 is a Chrome DevTools information exposure bug. Per the CVE record, Chrome versions prior to 149.0.7827.53 are affected; Google's desktop release notes map that to Linux <149.0.7827.53 and Windows/macOS <149.0.7827.53/.54. Exploitation is not webpage-only: the attacker has to convince the user to install a *malicious Chrome extension*, which then abuses the DevTools flaw to read potentially sensitive data from Chrome process memory.
The user-supplied 5.9/MEDIUM overstates the real enterprise risk. Google's own release post classifies this one as *Low*, and the decisive friction is obvious: this is not unauthenticated remote exploitation from the internet, it is a second-stage abuse path that depends on successful extension installation first. In managed fleets with extension allowlists, install restrictions, or force-managed browsers, the reachable population collapses fast.
3 steps from start to impact.
Land a malicious extension
- Target is running Chrome prior to
149.0.7827.53 - User can install extensions or browser is weakly managed
- Attacker can socially engineer the user into installing the extension
- Many enterprises block self-service extension installs or use allowlists
- Security-aware users are conditioned to distrust random extension prompts
- Managed Chrome can force-approved extensions only
Abuse DevTools memory exposure
- Extension has execution context on the victim browser
- Victim browser version is vulnerable
- Extension can reach the buggy DevTools path
- Bug details remain restricted in Chromium issue tracking
- Extension permission model and policy controls may limit practical reach
- Exploit reliability may vary by browser state and user workflow
Harvest whatever secrets are in memory
- Sensitive data must actually be present in browser memory
- Attacker needs outbound exfil path from the browser
- Victim must be using data worth stealing during the attack window
- Blast radius is typically one user/browser profile at a time
- Enterprise proxies, DLP, or browser monitoring may expose exfil patterns
- No evidence yet of broad, repeatable commodity exploitation
The supporting signals.
| In-the-wild status | No confirmed active exploitation. CISA KEV does not list CVE-2026-11238, and the CVE JSON's SSVC block marks Exploitation: none. |
|---|---|
| Public PoC status | No trustworthy public PoC found. The Chromium issue remains restricted, which usually means exploit details are still being withheld while the fix propagates. |
| EPSS | Very low threat signal. User-supplied EPSS is 0.00015; percentile was not independently confirmed from FIRST during this assessment. |
| KEV status | Not KEV-listed as checked against CISA's catalog on 2026-06-06. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N overstates exposure in practice because the real-world chain clearly requires user installation of a malicious extension. That's meaningful attacker-position friction even if the formal vector doesn't model it cleanly. |
| Affected versions | CVE record says Chrome prior to 149.0.7827.53. Google's desktop release note maps the fixed desktop rollout to Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. |
| Fixed versions | Upgrade to Chrome 149.0.7827.53 or later on Linux and 149.0.7827.53/.54 or later on Windows/macOS. |
| Exposure model | Not internet-scannable. This is an endpoint/browser version plus extension-governance problem, not a Shodan/Censys perimeter exposure problem. |
| Timeline | Chrome shipped the stable desktop fix on 2026-06-02; the CVE record was published on 2026-06-04; the CISA ADP enrichment carrying the 5.9 CVSS appeared on 2026-06-05. |
| Reporter | Reported by Google on 2026-03-26, per the Chrome stable release advisory. |
noisgate verdict.
The decisive factor is that exploitation requires a malicious extension to be installed first, which makes this a *governance and user-consent problem* rather than an internet-reachable browser break. That prerequisite sharply limits exposed population in well-managed enterprises and keeps the blast radius near the individual browser profile.
Why this verdict
- Requires malicious extension install first — this is not unauthenticated remote exploitation from a webpage alone; the attacker must first win an extension-install social-engineering battle.
- Reachable population is narrower than CVSS suggests — managed Chrome fleets commonly block or tightly govern extensions, which compounds downward pressure on severity.
- Impact is confidentiality-only and user-scoped — the record describes reading sensitive process memory, not sandbox escape, host RCE, or tenant-wide compromise.
Why not higher?
There is no evidence of active exploitation, no KEV listing, no public PoC of note, and no direct remote drive-by path from the public internet. The chain starts with a prerequisite many enterprises already control: unauthorized extension installation.
Why not lower?
It still exposes potentially sensitive browser-resident data, which can include sessions and business information for the affected user. In loosely managed environments where users freely install extensions, the practical risk is real enough that this should stay above IGNORE.
What to do — in priority order.
- Tighten extension policy — Use Chrome Enterprise allowlists/blocklists and approved-extension-only policy so arbitrary extensions cannot be installed. For a
LOWverdict there is no fixed mitigation deadline, but this is worth folding into normal browser hardening because it cuts off the exploit prerequisite entirely. - Inventory installed extensions — Pull extension inventories from managed browsers and hunt for unknown IDs, sideloaded packages, and extensions with risky permissions. For
LOW, treat this as backlog hygiene and complete it during the next routine browser governance review. - Alert on unexpected extension installs — If you have browser telemetry, EDR, or admin-console reporting, generate alerts for installs outside your approved catalog. This catches the prerequisite abuse step faster than waiting on version-only vulnerability scans.
- Roll the fixed Chrome build — Update browsers to
149.0.7827.53/.54or later through your regular browser maintenance channel. Because this scoredLOW, do it as normal patch hygiene rather than an emergency campaign.
- A perimeter scanner won't help; this is a client-side browser flaw with no exposed listening service.
- A generic WAF doesn't meaningfully reduce risk because the exploit path is a malicious extension, not a malicious inbound web request to your infrastructure.
- MFA does not stop the initial bug trigger; it may reduce value of stolen sessions, but it does not prevent extension installation or in-browser memory reads.
Crowdsourced verification payload.
Run this on the target endpoint or through your fleet agent on Windows, macOS, or Linux. Invoke it with python3 check_cve_2026_11238.py; no admin rights are usually required, but reading some install paths on locked-down systems may work better with local admin.
#!/usr/bin/env python3
# CVE-2026-11238 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):
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_lt(a, b):
return 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 '') + ' ' + (p.stderr or '')
return p.returncode, out.strip()
except Exception:
return 1, ''
def candidate_commands():
system = platform.system().lower()
cmds = []
if system == 'windows':
local = os.environ.get('LOCALAPPDATA', '')
pf = os.environ.get('PROGRAMFILES', '')
pf86 = os.environ.get('PROGRAMFILES(X86)', '')
paths = [
Path(local) / 'Google/Chrome/Application/chrome.exe',
Path(pf) / 'Google/Chrome/Application/chrome.exe',
Path(pf86) / 'Google/Chrome/Application/chrome.exe',
]
for p in paths:
cmds.append([str(p), '--version'])
cmds.append(['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'])
cmds.append(['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'])
elif system == 'darwin':
paths = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
]
for p in paths:
cmds.append([p, '--version'])
cmds.append(['mdfind', 'kMDItemCFBundleIdentifier == "com.google.Chrome"'])
else:
for name in ['google-chrome', 'google-chrome-stable', '/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
cmds.append([name, '--version'])
return cmds
def extract_version_from_output(output):
return parse_version(output)
def main():
found_versions = []
for cmd in candidate_commands():
rc, out = run_cmd(cmd)
if not out:
continue
# macOS mdfind fallback: if Chrome app exists, try running it
if cmd[0] == 'mdfind':
for line in out.splitlines():
app = line.strip()
if app.endswith('Google Chrome.app'):
binpath = app + '/Contents/MacOS/Google Chrome'
rc2, out2 = run_cmd([binpath, '--version'])
ver = extract_version_from_output(out2)
if ver:
found_versions.append((binpath, ver))
continue
ver = extract_version_from_output(out)
if ver:
found_versions.append((' '.join(cmd), ver))
if not found_versions:
print('UNKNOWN - Google Chrome version not found')
sys.exit(2)
# Prefer highest discovered version in case multiple installs exist
best_path, best_ver = sorted(found_versions, key=lambda x: x[1], reverse=True)[0]
if version_lt(best_ver, FIXED):
print(f'VULNERABLE - Google Chrome {best_ver[0]}.{best_ver[1]}.{best_ver[2]}.{best_ver[3]} found via {best_path}; fixed version is 149.0.7827.53+')
sys.exit(1)
else:
print(f'PATCHED - Google Chrome {best_ver[0]}.{best_ver[1]}.{best_ver[2]}.{best_ver[3]} found via {best_path}')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53/.54 or later through normal browser maintenance. For a LOW reassessment there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so this is not an emergency patch push; document the rationale, fix it in routine browser servicing, and prioritize extension-governance cleanup where users still have broad install freedom.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.