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

Use after free in Omnibox in Google Chrome prior to 149

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

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.

"This is a memory-safety bug, but the attack needs a user-driven Omnibox gesture and there is no live exploit signal."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user into attacker-controlled web content

The attacker needs the target to open a crafted page or redirected site in Chrome. This is standard browser-bug delivery: phishing, malicious ads, or compromised sites do the distribution work; the bug itself does not provide initial reach.
Conditions required:
  • Target uses Google Chrome desktop in an affected version
  • Target opens attacker-controlled content
Where this breaks in practice:
  • 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
Detection/coverage: Scanner coverage is mostly version-based. Web scanners and external ASM platforms generally will not see this because the exposure sits on endpoints, not servers.
STEP 02

Drive a very specific Omnibox interaction

The report explicitly says exploitation requires the user to engage in a specific UI gesture in the Omnibox. That is the decisive friction point: the attacker is not just asking for a page view, but for an extra browser-UI action at the right moment.
Conditions required:
  • User interacts with the Omnibox in the attacker-shaped state
  • The crafted page successfully induces that exact gesture path
Where this breaks in practice:
  • 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
Detection/coverage: There is little dependable network-side detection here. Telemetry is more likely to come from browser crash reports or EDR child-process / browser instability analytics than from IDS signatures.
STEP 03

Trigger the use-after-free in browser UI code

If the user reaches the vulnerable state, freed Omnibox memory can be reused and then referenced again, producing memory corruption. In practice that commonly means browser instability first; turning that into reliable code execution is a separate exploit-engineering problem that the CVSS number does not capture.
Conditions required:
  • Precise state manipulation inside the Omnibox component
  • Attacker-controlled timing or object lifetime reuse succeeds
Where this breaks in practice:
  • Reliability is unknown and likely non-trivial
  • Chrome exploit mitigations and allocator behavior raise the bar above 'bug exists'
Detection/coverage: Crash telemetry, browser faulting events, and EDR memory-corruption detections may catch failed attempts, but signature coverage for a non-public browser exploit is usually poor.
STEP 04

Achieve meaningful post-corruption impact

The upper-bound risk is arbitrary code execution in the browser context, but there is no public evidence that this bug alone delivers a dependable, weaponized outcome. For enterprise triage, that means you should treat it as a patchable client-side memory corruption with broad fleet relevance, not as a proven mass-exploitation emergency.
Conditions required:
  • Attacker converts the UAF into stable exploitation
  • Endpoint protections fail to block follow-on behavior
Where this breaks in practice:
  • No public PoC or in-the-wild campaign evidence
  • EDR and browser sandboxing limit blast radius compared with a server-side RCE
Detection/coverage: Expect version-based detection from VM tools. Expect weak exploit-detection fidelity unless a later campaign operationalizes the bug.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found as of 2026-06-06; not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC located. Chromium bug details are not publicly useful without sign-in, and Google kept the technical issue restricted at disclosure time.
EPSS0.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 statusNot KEV-listed. No KEV date-added or due date applies.
Severity mismatchYour 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 versionsGoogle 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 versionsMinimum 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 realityThis 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 timelineVendor disclosure landed with Chrome 149 stable on 2026-06-02; the CVE record was disclosed on 2026-06-04.
ReporterReported by gevakun on 2026-04-14, per Google’s Chrome release advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

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.

HIGH Affected/fixed version boundaries from Google Chrome 149 release notes
MEDIUM Real-world exploitability assessment given limited public technical detail
HIGH No active exploitation / no KEV status as of 2026-06-06

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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())
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat this like a fire drill, but do not let it drift either: push Chrome 149.0.7827.53+ through your normal browser-update channel, force browser restarts where your fleet habitually lags, and clean up unmanaged browser installs. For a MEDIUM noisgate verdict there is noisgate mitigation SLA: no mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤365 days, but for a 10,000-host Chrome estate the sane move is to land it in the next routine browser rollout, not at day 364.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - June 2026 archive
  3. Chromium issue reference for CVE-2026-11177
  4. Chrome 149 release notes
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. Canadian Centre for Cyber Security advisory for Chrome 149 fixes
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.