This is less a drive-by landmine than a tripwire hidden behind a very specific button press
CVE-2026-11177 is a use-after-free in Chrome's Omnibox UI affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. In plain English: a remote site can steer a user into a narrow browser-UI state, and if the user performs the required specific Omnibox interaction, Chrome can touch memory after it has already been freed.
The raw 8.8 / HIGH CVSS-style label overstates enterprise urgency for this one. Google’s own June 2, 2026 Chrome 149 release classified this bug as Chromium security severity: Medium, and that tracks reality better: this is still a real memory corruption issue in a massively deployed browser, but the chain is narrowed by UI:R, a specific gesture requirement, no public PoC, no KEV listing, and no evidence of in-the-wild abuse as of June 6, 2026.
4 steps from start to impact.
Lure the user into attacker-controlled web content
- Target uses Google Chrome desktop in an affected version
- Target opens attacker-controlled content
- Email gateways, Safe Browsing, URL filtering, and user training cut delivery volume hard
- This is not an unauthenticated service exposed on the internet; it is a client-side opportunity bug
Drive a very specific Omnibox interaction
- User interacts with the Omnibox in the attacker-shaped state
- The crafted page successfully induces that exact gesture path
- This is materially harder than plain click-and-browse exploitation
- Modern browser UX, password managers, and enterprise hardening reduce how often users manually manipulate the address bar in attacker-controlled flows
Trigger the use-after-free in browser UI code
- Precise state manipulation inside the Omnibox component
- Attacker-controlled timing or object lifetime reuse succeeds
- Reliability is unknown and likely non-trivial
- Chrome exploit mitigations and allocator behavior raise the bar above 'bug exists'
Achieve meaningful post-corruption impact
- Attacker converts the UAF into stable exploitation
- Endpoint protections fail to block follow-on behavior
- No public PoC or in-the-wild campaign evidence
- EDR and browser sandboxing limit blast radius compared with a server-side RCE
The supporting signals.
| In-the-wild status | No public exploitation evidence found as of 2026-06-06; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | No public PoC located. Chromium bug details are not publicly useful without sign-in, and Google kept the technical issue restricted at disclosure time. |
| EPSS | 0.00068 (~0.068% 30-day exploitation probability). That is low signal, which fits a newly disclosed, interaction-heavy browser bug with no public weaponization. |
| KEV status | Not KEV-listed. No KEV date-added or due date applies. |
| Severity mismatch | Your supplied downstream score is 8.8 / HIGH with CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, but Google’s June 2, 2026 Chrome 149 advisory labels CVE-2026-11177 as Chromium security severity: Medium. |
| Affected versions | Google Chrome before 149.0.7827.53; Chrome desktop release notes show fixes in 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac). |
| Fixed versions | Minimum safe target for fleet policy: 149.0.7827.53 or later. On Windows/macOS, 149.0.7827.54 is the common stable desktop build; Linux is 149.0.7827.53. |
| Exposure reality | This is a client-side browser flaw, so Shodan/Censys/FOFA are basically the wrong measurement tool. Exposure is driven by endpoint install base and lagging browser restart/update behavior, not internet-facing ports. |
| Disclosure timeline | Vendor disclosure landed with Chrome 149 stable on 2026-06-02; the CVE record was disclosed on 2026-06-04. |
| Reporter | Reported by gevakun on 2026-04-14, per Google’s Chrome release advisory. |
noisgate verdict.
The single biggest downward pressure is the specific Omnibox gesture requirement on top of ordinary user interaction. That moves this out of the 'drive-by browser RCE' bucket and into a narrower, harder-to-operationalize client-side exploit path despite the scary memory-corruption class.
Why this verdict
- Downward adjustment: requires user interaction plus a specific UI gesture — not just a page view, but a narrow Omnibox action path.
- Downward adjustment: client-side only — attacker reach depends on getting code in front of the user; there is no server-side, wormable, unauthenticated exposure surface.
- Downward adjustment: no public exploit signal — no KEV, no observed campaign reporting, no public PoC, and a very low EPSS.
- Upward adjustment: memory corruption in a ubiquitous browser still matters — Chrome is everywhere, so even a narrow exploit path can create meaningful fleet risk if patch hygiene is weak.
Why not higher?
Because every prerequisite compounds friction: the attacker needs remote content delivery, then the victim must perform a specific Omnibox gesture, then the bug must be made reliable enough to matter. That is not how mass browser exploitation usually looks when a bug is truly patch-now critical. There is also no evidence of public weaponization or active exploitation.
Why not lower?
Because it is still a use-after-free in a top-tier browser UI component, not a cosmetic spoofing issue. Even without public exploit code, memory-safety bugs in Chrome deserve patching attention across a large fleet, especially where auto-update and restart compliance are sloppy.
What to do — in priority order.
- Enforce Chrome auto-update and restart compliance — Make sure endpoint policy actually lands Chrome 149+ and forces the browser to restart so the fix is loaded into memory. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser bugs belong in the next normal endpoint/browser wave, not in a forgotten backlog.
- Tighten browser-channel governance — Block unmanaged Chromium forks and stale portable browser installs so your inventory does not lie to you. There is no mitigation SLA here, but this control reduces the population that remains quietly vulnerable during the remediation window.
- Use Safe Browsing, URL filtering, and mail-link detonation — These controls do not fix the bug, but they reduce the attacker’s ability to get crafted content in front of users. For this MEDIUM issue, treat this as exposure reduction while you complete patch rollout inside the remediation window.
- Watch crash and browser anomaly telemetry — Collect Chrome crash spikes, EDR browser-memory alerts, and unusual browser child-process behavior to catch failed exploit attempts or testing. Again, no mitigation SLA applies, but this is cheap detection value for enterprises with large Chrome estates.
- A WAF does not meaningfully help; this is not a server-side request-processing flaw.
- Network perimeter scanning will not surface exposure; the risk lives on endpoints and in browser version lag.
- MFA is irrelevant to exploitability; it may reduce phishing outcomes generally, but it does not block the Omnibox memory bug itself.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR scripting channel. Invoke it as python3 check_chrome_11177.py on Linux/macOS or py check_chrome_11177.py on Windows; it needs only standard user rights and prints VULNERABLE, PATCHED, or UNKNOWN.
#!/usr/bin/env python3
# check_chrome_11177.py
# Detect local Chrome/Chromium version and assess exposure to CVE-2026-11177.
# 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, List
FIXED_MIN = (149, 0, 7827, 53)
WINDOWS_CANDIDATES = [
r"C:\Program Files\Google\Chrome\Application\chrome.exe",
r"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe",
r"C:\Program Files\Chromium\Application\chrome.exe",
r"C:\Program Files (x86)\Chromium\Application\chrome.exe",
]
MAC_CANDIDATES = [
"/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
"/Applications/Chromium.app/Contents/MacOS/Chromium",
]
LINUX_CANDIDATES = [
"google-chrome",
"google-chrome-stable",
"chromium",
"chromium-browser",
"/usr/bin/google-chrome",
"/usr/bin/google-chrome-stable",
"/usr/bin/chromium",
"/usr/bin/chromium-browser",
]
def run_cmd(cmd: List[str]) -> Optional[str]:
try:
p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
out = (p.stdout or "") + "\n" + (p.stderr or "")
return out.strip()
except Exception:
return None
def parse_version(text: str) -> Optional[Tuple[int, int, int, int]]:
if not text:
return None
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_str(v: Tuple[int, int, int, int]) -> str:
return ".".join(str(x) for x in v)
def compare_versions(a: Tuple[int, int, int, int], b: Tuple[int, int, int, int]) -> int:
return (a > b) - (a < b)
def find_linux_binary() -> Optional[str]:
for c in LINUX_CANDIDATES:
if os.path.isabs(c) and os.path.exists(c):
return c
path = shutil.which(c)
if path:
return path
return None
def find_windows_binary() -> Optional[str]:
local_app = os.environ.get("LOCALAPPDATA")
if local_app:
user_candidate = os.path.join(local_app, "Google", "Chrome", "Application", "chrome.exe")
if os.path.exists(user_candidate):
return user_candidate
for c in WINDOWS_CANDIDATES:
if os.path.exists(c):
return c
return None
def find_mac_binary() -> Optional[str]:
for c in MAC_CANDIDATES:
if os.path.exists(c):
return c
return None
def get_binary_and_version() -> Tuple[Optional[str], Optional[Tuple[int, int, int, int]], Optional[str]]:
system = platform.system().lower()
if system == "windows":
binary = find_windows_binary()
elif system == "darwin":
binary = find_mac_binary()
else:
binary = find_linux_binary()
if not binary:
return None, None, None
output = run_cmd([binary, "--version"])
ver = parse_version(output or "")
return binary, ver, output
def main() -> int:
binary, ver, raw = get_binary_and_version()
if not binary:
print("UNKNOWN: Chrome/Chromium binary not found")
return 2
if not ver:
print(f"UNKNOWN: Could not parse version from {binary}")
if raw:
print(raw)
return 2
print(f"Detected: {binary}")
print(f"Version: {version_str(ver)}")
print(f"Fixed minimum for CVE-2026-11177: {version_str(FIXED_MIN)}")
if compare_versions(ver, FIXED_MIN) < 0:
print("VULNERABLE")
return 1
print("PATCHED")
return 0
if __name__ == "__main__":
sys.exit(main())
If you remember one thing.
Sources
- Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
- Google Chrome Releases - June 2026 archive
- Chromium issue reference for CVE-2026-11177
- Chrome 149 release notes
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS overview
- FIRST EPSS API documentation
- Canadian Centre for Cyber Security advisory for Chrome 149 fixes
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.