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

Insufficient policy enforcement in Actor in Google Chrome prior to 149

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

This is a side door in the browser’s AI valet service, not a broken front gate

CVE-2026-11018 is a navigation-policy bypass in Chrome's Actor component, fixed in Chrome 149.0.7827.53/54 for Windows/macOS and 149.0.7827.53 for Linux. In plain English: a malicious site can try to make Chrome's Actor/Glic automation layer cross navigation boundaries it was supposed to respect, letting the browser assistant follow or trigger navigation paths that should have been blocked.

The raw bug class sounds worse than the operational reality. This is not memory corruption, not sandbox escape, and not code execution; it is a policy/control failure in a niche browser-automation path tied to Chrome's glic/Actor framework. Google tagged it *Medium* in the release notes, but without a CVSS score and with very low EPSS, no KEV entry, no public exploit evidence, and a sharply limited exposed population, the defender-grade call is LOW.

"= ASSESSED AT LOW: remote on paper, but real-world reach is narrow because it lives in Chrome's Actor/Glic automation path"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a crafted page

The attacker needs a victim to browse to attacker-controlled content that can exercise the relevant navigation flow. The weaponized tool here is just a crafted HTML/JS page aimed at browser logic, not shellcode or a memory-corruption primitive.
Conditions required:
  • Victim uses a vulnerable Chrome build prior to 149.0.7827.53
  • Victim visits attacker-controlled web content
Where this breaks in practice:
  • This is still a client-side browser bug, so the attacker has to win user traffic first
  • No evidence this bug is broadly weaponized or embedded in common exploit kits
Detection/coverage: Network scanners will not see this. Coverage is mainly browser version inventory from EDR/MDM and, if available, browser telemetry showing unusual navigation behavior.
STEP 02

Reach the Actor/Glic execution path

The vulnerable logic sits in Chrome's Actor framework, which Chromium's own source ties to the glic UI. That means the attacker is not hitting a universally exercised browser path; they need the victim's environment to have Actor/Glic available and actually engaged in a workflow where navigation gating matters.
Conditions required:
  • Chrome Actor/Glic functionality is enabled or present in the user's build
  • The browsing session enters an Actor-mediated action/navigation path
Where this breaks in practice:
  • This is the biggest severity reducer: most enterprises are not depending on Chrome AI agent workflows at scale
  • Many managed environments disable experimental or assistant features outright
Detection/coverage: Traditional vuln scanners usually stop at version detection. Look for feature-usage telemetry, pilot-ring inventory, or command-line/browser policy states if you manage Chrome centrally.
STEP 03

Bypass intended navigation gating

The exploit abuses insufficient policy enforcement so that a navigation the Actor layer should have blocked is allowed or mishandled. Chromium's Actor code shows explicit navigation-throttle logic and policy checks around cross-origin navigation, enterprise block decisions, and safety checks; this CVE is about those controls not holding in some cases.
Conditions required:
  • Attacker can trigger a navigation flow evaluated by Actor navigation/policy logic
  • The vulnerable code path is hit under the victim's workflow
Where this breaks in practice:
  • Impact is bounded to navigation-policy bypass, not arbitrary native code execution
  • Enterprise policy, Safe Browsing, and feature disablement can still reduce practical abuse paths
Detection/coverage: There is no reliable signature-level scanner for the bypass itself. Best signal is Chrome version plus investigation of suspicious browser navigation chains in endpoint/browser logs.
STEP 04

Convert bypass into user-impact

The attacker still has to turn the navigation bypass into something useful: phishing flow manipulation, origin-trust confusion, or AI-assisted browsing behavior outside intended guardrails. That is meaningfully weaker than gaining process execution or escaping the sandbox, and it usually still depends on user context and browser session state.
Conditions required:
  • Victim is actively interacting with browser content or Actor-mediated actions
  • The resulting navigation leads to a meaningful business outcome for the attacker
Where this breaks in practice:
  • No demonstrated path to OS compromise from this CVE alone
  • Blast radius is mostly the affected browsing session, not the whole endpoint
Detection/coverage: Phishing-resistant auth, URL filtering, and browser telemetry may catch the *downstream abuse*, but not the root flaw directly.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found. Not listed in CISA KEV as checked against the KEV catalog.
Proof-of-concept availabilityNo public PoC located in primary sources. Google notes that bug details may remain restricted until most users are updated in the Chrome release post.
EPSS0.00016 (~0.016%) from the user-provided intel; the FIRST EPSS API is the authoritative feed, but I did not verify a percentile value from a primary source.
KEV statusNo KEV listing; therefore no KEV remediation due date applies per CISA.
Vendor severity / CVSSGoogle labels the bug Medium in the Chrome 149 release notes, but no vendor CVSS score or vector was published in the sources reviewed.
Affected versionsChrome for Desktop before 149.0.7827.53/54 on Windows/macOS and before 149.0.7827.53 on Linux, per Google and the Canadian Centre for Cyber Security.
Fixed versionsUpgrade to Chrome 149.0.7827.53/54 on Windows/macOS or 149.0.7827.53 on Linux.
Component contextChromium's source ties Actor directly to the glic UI in the Actor README, and shows dedicated navigation gating in actor_navigation_throttle.cc and policy enforcement in site_policy.cc.
Scanning / exposure realityThis is an endpoint browser issue, not an internet-facing service. Shodan/Censys/FOFA are not useful exposure gauges here; your meaningful exposure dataset is managed Chrome fleet inventory plus any pilot rings with Actor/Glic enabled.
Disclosure / reporterPublic patch release was 2026-06-02 in Google's stable-channel post; the user-supplied disclosure date is 2026-06-04. Google lists the bug as reported by Google on 2026-03-29.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.2/10)

The decisive factor is exposure population: this bug sits in Chrome's Actor/Glic automation path rather than a universally exercised browser primitive. That turns a superficially remote bug into a narrowly reachable policy bypass with limited blast radius and no evidence of real-world weaponization.

HIGH Affected version boundary and fix train
MEDIUM Exploit-path assessment under restricted bug details
HIGH Priority reduction driven by lack of KEV/exploitation evidence

Why this verdict

  • Feature-path narrowing: this is in Actor/glic, not a browser-wide rendering or JS engine primitive; that sharply cuts the reachable population versus a normal Chrome RCE.
  • No code-exec payoff: the bug is a navigation restriction bypass, not memory corruption, sandbox escape, or native execution.
  • Remote but not broadly exposed: an unauthenticated remote attacker still needs the victim on a crafted page *and* the relevant Actor-mediated workflow to be active.
  • Threat intel is cold: EPSS is extremely low, KEV is negative, and no public exploitation evidence or credible public PoC surfaced in primary sources.
  • Enterprise controls already trim abuse paths: feature disablement, Safe Browsing, URL filtering, and phishing-resistant auth can all limit the downstream value even if the bypass triggers.

Why not higher?

There is no sign this vulnerability is being used in the wild, and the impact stops well short of endpoint compromise. More importantly, the exploit path appears to depend on Chrome's Actor/Glic automation framework, which is not equivalent to "every Chrome user who opens a webpage."

Why not lower?

It is still a remotely triggerable browser flaw in a massively deployed product, and policy-bypass bugs in navigation/security boundaries can be chained into phishing, origin confusion, or guardrail evasion. If you have Chrome AI/Actor pilot populations enabled, the exposed subset is small but real, so this is not an IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Disable Actor/Glic where unused — If your fleet is not intentionally using Chrome's Actor/Glic capabilities, disable them to remove the vulnerable path entirely. Chromium's own README documents --disable-features=GlicActor,GlicActorUi; for a LOW verdict there is no SLA, so handle this as backlog hygiene in your next normal browser policy cycle.
  2. Inventory pilot rings — Identify any business units, dev channels, beta rings, or AI-assistant pilots that have Actor/Glic enabled or heavily used. Prioritize those groups first because they are the only population where this bug meaningfully matters; for LOW, there is no SLA, but do the inventory during routine browser governance work.
  3. Enforce Chrome auto-update compliance — Your strongest control is keeping desktop Chrome on or above 149.0.7827.53/54. For LOW, there is no SLA, so treat this as standard patch hygiene and close it through the normal browser update ring rather than emergency change.
  4. Watch for suspicious browser navigation abuse — Where you have browser or EDR telemetry, flag abnormal redirect chains, access to suspicious domains, and user reports of odd assistant/browser behavior. This will not detect the root bug reliably, but it can catch the phishing or trust-abuse outcomes if someone does try to operationalize it.
What doesn't work
  • A WAF does not fix this; the bug is in client-side browser policy enforcement, not your web app.
  • A perimeter vulnerability scanner will not tell you who is truly at risk; it cannot measure whether Actor/Glic is enabled or used on endpoints.
  • User awareness training alone is not enough because the flaw is a browser-logic bypass, not just a bad click habit.
06 · Verification

Crowdsourced verification payload.

Run this locally on the target endpoint or through your EDR/MDM remote-script feature. Invoke it as python3 check_cve_2026_11018.py on macOS/Linux or py check_cve_2026_11018.py on Windows; standard user rights are enough because it only reads installed Chrome version data.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check Google Chrome version for CVE-2026-11018
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

THRESHOLD = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10, shell=False)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
    except Exception:
        pass
    return None


def parse_version(text):
    if not text:
        return None
    m = VERSION_RE.search(text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def get_windows_version():
    # Try BLBeacon registry first (most reliable without admin rights)
    reg_paths = [
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in reg_paths:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, "registry"

    # Fallback to common executable paths
    candidates = [
        os.path.join(os.environ.get("ProgramFiles", r"C:\Program Files"), "Google", "Chrome", "Application", "chrome.exe"),
        os.path.join(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"), "Google", "Chrome", "Application", "chrome.exe"),
        os.path.join(os.environ.get("LOCALAPPDATA", ""), "Google", "Chrome", "Application", "chrome.exe"),
    ]
    for path in candidates:
        if path and os.path.exists(path):
            out = run_cmd([path, "--version"])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def get_macos_version():
    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"])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def get_linux_version():
    candidates = ["google-chrome", "google-chrome-stable"]
    for name in candidates:
        path = shutil.which(name)
        if path:
            out = run_cmd([path, "--version"])
            ver = parse_version(out)
            if ver:
                return ver, path
    return None, None


def compare_versions(found, threshold):
    if found is None:
        return None
    return found >= threshold


def main():
    system = platform.system().lower()
    if system == "windows":
        ver, source = get_windows_version()
    elif system == "darwin":
        ver, source = get_macos_version()
    elif system == "linux":
        ver, source = get_linux_version()
    else:
        print("UNKNOWN")
        print(f"Unsupported platform: {platform.system()}")
        sys.exit(2)

    if ver is None:
        print("UNKNOWN")
        print("Google Chrome version not found")
        sys.exit(2)

    status = compare_versions(ver, THRESHOLD)
    ver_str = ".".join(str(x) for x in ver)
    threshold_str = ".".join(str(x) for x in THRESHOLD)

    if status is True:
        print("PATCHED")
        print(f"Detected Chrome {ver_str} from {source}; threshold is {threshold_str}")
        sys.exit(0)
    elif status is False:
        print("VULNERABLE")
        print(f"Detected Chrome {ver_str} from {source}; threshold is {threshold_str}")
        sys.exit(1)
    else:
        print("UNKNOWN")
        sys.exit(2)


if __name__ == "__main__":
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat this like a fleet-wide fire drill unless you have explicit Chrome Actor/Glic pilots. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as backlog hygiene: first identify any managed populations with Actor/Glic enabled, then let your standard browser auto-update ring move them to 149.0.7827.53/54 or later. If you do find an AI-agent pilot ring, disable GlicActor/GlicActorUi in that subset while normal patch rollout catches up, but this is still a routine browser-governance item, not an emergency patch window.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  3. Chromium source - Actor README
  4. Chromium source - actor_navigation_throttle.cc
  5. Chromium source - site_policy.cc
  6. FIRST EPSS API documentation
  7. CISA Known Exploited Vulnerabilities Catalog
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.