This is a second lock behind the first break-in, not an unlocked front door
CVE-2026-11168 affects Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. Your supplied metadata describes an *Extensions* flaw that lets a remote attacker who has already compromised the renderer expose data across a boundary; Google's public Chrome 149 release archive, however, labels CVE-2026-11168 as Insufficient policy enforcement in Extensions, so the public record is inconsistent on the exact bug class. Either way, this is not a clean one-click pre-auth browser takeover by itself.
paragraph 2: Google's MEDIUM 6.5 baseline is close, but still a little generous for enterprise patch triage if the prior-renderer-compromise prerequisite is real. A bug that only matters *after* the attacker already landed code in the renderer, or that depends on abusing extension policy boundaries, is classic exploit-chain material: useful to an attacker, important to patch, but not something that should jump ahead of active RCEs, sandbox escapes with in-the-wild use, or KEV-listed edge services.
3 steps from start to impact.
Land code in the renderer first
- User visits attacker-controlled content or another weakness is already present
- Attacker can execute or reliably influence code flow in the renderer process
- This prerequisite already assumes a successful initial exploit stage
- Modern Chrome hardening, sandboxing, and site isolation make first-stage reliability non-trivial
- EDR, browser exploit protections, and safe browsing controls may disrupt the chain before this CVE matters
Cross the extension boundary
- Target is running a vulnerable Chrome build before
149.0.7827.53 - The vulnerable extension/path is reachable from the compromised context
- Enterprise extension allowlists and restricted extension installs shrink reachable attack surface
- Some deployments disable or tightly govern non-approved extensions
- The exact bug details remain partially restricted by Google, which raises uncertainty about exploit reliability
Extract sensitive material
- Sensitive browser-resident data exists in the affected context
- Attacker can exfiltrate or reuse what is exposed
- Impact is bounded by what the browser/session actually contains
- Strong session controls, re-auth prompts, conditional access, and short-lived tokens limit downstream value
- No public evidence currently shows widespread operational use of this CVE
The supporting signals.
| In-the-wild status | No public exploitation evidence found in the sources reviewed, and not in CISA KEV. |
|---|---|
| KEV status | Not listed in the CISA KEV catalog as of the reviewed sources. |
| Proof-of-concept availability | No public PoC located from Google, Project Zero, exploit-db, or common researcher channels in the reviewed sources. Google also notes bug details may stay restricted until most users are updated. |
| EPSS | User-supplied EPSS is 0.00028 — effectively background noise. That lines up with a bug that looks more useful in an exploit chain than as a mass-exploitation starter. See FIRST EPSS and the EPSS model overview. |
| Vendor severity vs reality | Vendor baseline is MEDIUM / 6.5. I keep it MEDIUM, but trim it down because the most plausible reading requires prior renderer compromise or an extension-policy path, both of which sharply reduce real-world reachable population. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote delivery with user interaction required, confidentiality impact only, and no integrity/availability hit. That is already a softer shape than Chrome RCEs and sandbox escapes. |
| Affected versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS, based on Google's June 2, 2026 stable release and the Canadian advisory summarizing it. |
| Fixed versions | Fixed in Chrome 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). Chrome generally self-updates quickly in managed fleets if policy does not defer restarts too aggressively. |
| Exposure / scanning reality | This is not meaningfully internet-census-scannable the way VPNs, hypervisors, or web middleware are. Shodan/Censys/GreyNoise-style exposure counts do not materially help because Chrome desktop is an endpoint client issue, not a public-facing service footprint. |
| Disclosure / reporting | Publicly disclosed 2026-06-04 per your intel; Google's Chrome 149 desktop stable update shipped 2026-06-02. The Chrome archive shows CVE-2026-11168 reported by Google on 2026-04-13. |
noisgate verdict.
The decisive downward pressure is the attacker-position requirement: if this CVE only pays off after renderer compromise, then it is a *post-initial-exploit chain component*, not an opening-move vulnerability. Chrome is ubiquitous, but ubiquity alone does not outweigh a prerequisite that already assumes the attacker has cleared Chrome's first security boundary.
Why this verdict
- Prior compromise required: the user-supplied description says the attacker must have *already compromised the renderer process*. That is a major downgrade from a stand-alone browser RCE.
- User interaction still matters: the supplied CVSS includes
UI:R, so the reachable population depends on users being driven into attacker-controlled content or another exploit chain stage succeeding first. - No active exploitation signal: no KEV listing, no public exploit evidence found, and a very low EPSS all argue against treating this like an emergency fleet fire.
- Impact is confidentiality-focused: the supplied vector is
C:H/I:N/A:N, which is serious but materially less urgent than bugs that immediately hand over code execution or durable host compromise. - Endpoint, not edge: this is a browser client issue with no meaningful internet-exposed census footprint, so the exploitable population is whatever vulnerable browser estate remains, not every internet-facing node.
Why not higher?
I did not score this HIGH because the best available reading makes it a *chain enhancer* rather than the initial intrusion vector. No KEV entry, no credible public PoC, no observed campaigns, and no direct integrity or availability impact keep it out of the top patch lane.
Why not lower?
I did not drop this to LOW because Chrome is everywhere, the bug sits in a high-value trust boundary, and confidentiality loss in enterprise browser sessions can still produce meaningful follow-on harm. Even chain-only browser flaws matter when they help attackers turn a renderer foothold into useful data access.
What to do — in priority order.
- Enforce Chrome auto-update — Make sure browser update policies are not deferring stable-channel uptake longer than necessary. For a MEDIUM noisgate verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice you should still close lagging update rings quickly because browsers age badly.
- Tighten extension allowlisting — Restrict installs to approved extensions and review any policy exceptions. This directly reduces the attack surface around extension-boundary abuse and should stay in place as a standing control, not just until this specific patch lands.
- Use browser telemetry in EDR — Alert on unusual browser child processes, suspicious extension installation events, and anomalous Chrome command-line flags. This does not prevent exploitation, but it is your best chance to catch the *first-stage* compromise that this CVE likely depends on.
- Isolate high-risk browsing — Apply remote browser isolation or hardened browsing profiles to admins, finance, and privileged SaaS operators where session theft hurts most. Use it where patch rollout is slow or unmanaged BYOD browsers remain in scope.
- A network IPS signature will not reliably save you here; this is browser/client logic and likely chain-dependent, not a neat server-side pattern match.
- Perimeter vulnerability scans do not meaningfully measure exposure because Chrome desktop is not a public-facing service.
- MFA alone does not stop browser-resident data exposure or token theft once an attacker is already operating inside the browser context.
Crowdsourced verification payload.
Run this on the target endpoint or through your endpoint management tooling. Invoke it as python3 check_chrome_cve_2026_11168.py with standard user rights; local admin is not required. It checks installed Google Chrome version across Windows, macOS, and Linux and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_cve_2026_11168.py
# Determine whether local Google Chrome is below the fixed version for CVE-2026-11168.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple
FIXED = (149, 0, 7827, 53)
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
if not m:
return None
return tuple(int(x) for x in m.groups())
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 get_version_windows() -> Optional[Tuple[int, int, int, int]]:
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 path in candidates:
if path and os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v
# Fallback to registry query via reg.exe
reg_paths = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon',
]
for reg_path in reg_paths:
out = run_cmd(['reg', 'query', reg_path, '/v', 'version'])
v = parse_version(out)
if v:
return v
return None
def get_version_macos() -> Optional[Tuple[int, int, int, int]]:
candidates = [
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
]
for path in candidates:
if os.path.exists(path):
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v
return None
def get_version_linux() -> Optional[Tuple[int, int, int, int]]:
for exe in ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']:
path = shutil.which(exe)
if path:
out = run_cmd([path, '--version'])
v = parse_version(out)
if v:
return v
return None
def compare_versions(found: Tuple[int, int, int, int], fixed: Tuple[int, int, int, int]) -> int:
if found < fixed:
return -1
if found > fixed:
return 1
return 0
def main() -> int:
system = platform.system().lower()
version = None
if 'windows' in system:
version = get_version_windows()
elif 'darwin' in system:
version = get_version_macos()
elif 'linux' in system:
version = get_version_linux()
else:
print('UNKNOWN: unsupported operating system')
return 2
if not version:
print('UNKNOWN: could not determine installed Chrome version')
return 2
verdict = compare_versions(version, FIXED)
version_str = '.'.join(str(x) for x in version)
fixed_str = '.'.join(str(x) for x in FIXED)
if verdict < 0:
print(f'VULNERABLE: installed Chrome version {version_str} is below fixed version {fixed_str}')
return 1
else:
print(f'PATCHED: installed Chrome version {version_str} is at or above fixed version {fixed_str}')
return 0
if __name__ == '__main__':
sys.exit(main())
If you remember one thing.
149.0.7827.53/54 through normal browser update channels; if you have stalled rings, unmanaged endpoints, or sensitive users running older builds, use extension allowlisting and high-risk browsing isolation as temporary controls while you complete patching. In plain terms: enforce update compliance now, finish the fleet under the noisgate remediation SLA of ≤365 days, and do not let this displace actively exploited edge-service CVEs.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.