← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11184 · CWE-602 · 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

Like a hallway pass that lets a visitor slip past the wrong door without giving them the building keys

CVE-2026-11184 is an *insufficient policy enforcement* bug in Chrome's Actor component that affects Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. The published impact is *bypass navigation restrictions* via a crafted HTML page, which means a malicious site can make the browser perform a navigation the platform policy should have blocked.

Google rated it MEDIUM at 6.3, and that is defensible in a vacuum, but it still overstates the operational urgency for enterprise patch triage. This is client-side, requires user interaction, has no published RCE/data-theft primitive in the advisory, no KEV listing, no public exploit chain, and the practical outcome is policy bypass rather than code execution or sandbox escape.

"This is a browser trust-boundary paper cut, not a fleet-emergency fire"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the user on attacker-controlled HTML

The attacker needs a victim to open a crafted page in a vulnerable Chrome build. The weaponized tool here is a *malicious landing page* delivered through phishing, ads, compromised sites, or chat links, matching the vendor description in the Chrome stable advisory.
Conditions required:
  • Victim uses Chrome prior to 149.0.7827.53
  • Victim opens attacker-controlled content
  • The browsing session is not already blocked by upstream web filtering or Safe Browsing
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Email gateways, secure web gateways, and browser reputation systems often block first-stage delivery
  • This is not a passive network bug; the attacker must win a click
Detection/coverage: Version scanners and browser inventory can identify affected builds, but content-level detection for a one-off crafted page is weak unless your proxy/SWG inspects and logs the destination.
STEP 02

Trigger the navigation-policy bypass

Once the page runs, the exploit attempts to abuse the Actor policy-enforcement weakness to force or allow a navigation that Chrome should have restricted. The practical 'tool' is custom JavaScript/HTML, but the underlying implementation details remain restricted in the Chromium issue, which is a signal that public weaponization is not yet trivial.
Conditions required:
  • The vulnerable code path in Actor is reachable from normal web content
  • The page can invoke the specific navigation scenario the bug affects
Where this breaks in practice:
  • Bug details are still restricted, limiting turnkey exploit reproduction
  • Navigation-restriction bypasses are usually narrower than generic XSS or UXSS primitives
  • Modern site isolation and browser hardening reduce blast radius if the bypass does not chain into a stronger primitive
Detection/coverage: EDR generally will not see meaningful host-level artifacts here. Browser telemetry, proxy logs, and abnormal redirect/navigation patterns are more useful than endpoint malware signatures.
STEP 03

Convert policy bypass into real-world abuse

The attacker still has to turn a navigation bypass into value: phishing, unwanted redirects, auth-flow confusion, or chaining into another browser flaw. The operational 'tool' is usually a social-engineering flow or second-stage web content, not a one-shot takeover primitive.
Conditions required:
  • The bypass meaningfully alters the user's trusted browsing context
  • A target workflow exists where redirected or disallowed navigation creates business impact
Where this breaks in practice:
  • The advisory does not claim code execution, sandbox escape, or cross-origin data theft
  • Business impact depends on follow-on abuse rather than the bug alone
  • MFA, IdP risk controls, and user-visible domain changes blunt many phishing-style outcomes
Detection/coverage: Detection is mostly indirect: suspicious IdP sign-ins, impossible-travel alerts, proxy redirect anomalies, and user-reported weird browser behavior.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the checked sources, and it is not listed in the CISA KEV catalog.
Proof-of-concept availabilityNo reliable public PoC or GitHub exploit surfaced in source review. The linked Chromium issue is sign-in restricted, which usually slows casual weaponization.
EPSSUpstream intel supplied 0.00031, which is extremely low and consistent with a low-likelihood browser policy-bypass rather than a mass-exploitation bug. EPSS should not drive severity alone, but here it supports the downgrade.
KEV statusNot KEV-listed when checked against CISA's authoritative catalog; no date added applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L from the supplied vendor intel. The key limiter is UI:R: the attacker needs the user in the loop.
Affected versionsChrome prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows/macOS per the Chrome stable release note.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux, and 149.0.7827.53/54 or later on Windows/macOS. For enterprise-managed channels, validate the exact build delivered by your browser management platform.
Exposure dataThere is no meaningful Shodan/Censys/FOFA-style internet census for endpoint browser versions, so exposure must be measured from MDM, EDR, SCCM/Intune/Jamf, or Chrome enterprise reporting. This is a *fleet inventory* problem, not an internet-exposure problem.
Disclosure datePublicly disclosed 2026-06-04; the stable desktop fix shipped on June 2, 2026 in Chrome 149.0.7827.53/.54, and the CVE record appeared on June 4, 2026.
ReporterReported by Google on 2026-04-15 in the release advisory; no external researcher credit is listed for this CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

The decisive factor is that this bug is a *user-driven browser policy bypass* with no published RCE, sandbox escape, or data-exfiltration primitive. In practice, it behaves more like a phishing or workflow-confusion enabler than a direct compromise path, so it does not deserve the same queue position as remotely exploitable server bugs or high-confidence browser code-exec flaws.

HIGH Affected version range and fixed build mapping
MEDIUM Assessment that public weaponization remains immature because technical details are still restricted
MEDIUM Final severity downgrade based on operational friction rather than missing vendor facts

Why this verdict

  • User interaction is mandatory: the attacker must get a victim onto crafted HTML, which means this starts after a successful lure or ad-delivery event.
  • The bug class is narrow: the advisory describes *bypass navigation restrictions*, not code execution, sandbox escape, or origin-crossing data theft.
  • No exploitation signal: no KEV listing, no public campaign reporting, and no public PoC reduces the urgency multiplier that would otherwise keep this in MEDIUM.
  • Browser-only blast radius: impact stays in the user's browsing context unless chained with social engineering or another vulnerability.
  • Exposure is broad but shallow: Chrome is everywhere, but widespread installation is not the same as high-severity exploitability when every attack still depends on user interaction and a narrow browser behavior flaw.

Why not higher?

There is no published evidence that this flaw alone yields code execution, sandbox escape, account takeover, or silent data extraction. The entire chain depends on the victim opening crafted content and the attacker successfully converting a navigation-policy bypass into something materially damaging.

Why not lower?

It still affects a massively deployed client application and can plausibly assist phishing, redirect abuse, or web-security boundary confusion at scale. If your environment has many unmanaged browsers or weak browser-update hygiene, the exposure population can still be large enough that this should not be ignored entirely.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure Chrome stable auto-update is functioning across managed Windows, macOS, and Linux endpoints. For a LOW verdict, treat this as backlog hygiene and complete it in your normal browser maintenance cycle rather than opening an incident lane.
  2. Block high-risk web delivery paths — Use SWG/DNS filtering, category controls, and Safe Browsing policy enforcement to reduce first-stage delivery of malicious landing pages. This is the best temporary control because the attack begins with a user opening crafted content.
  3. Harden identity flows — Require phishing-resistant MFA where possible and keep IdP risk policies tuned for suspicious redirects and anomalous sign-ins. That limits the value of any navigation-confusion or redirect abuse the attacker tries to derive from the browser flaw.
  4. Inventory out-of-date Chrome builds — Use EDR, MDM, SCCM, Intune, Jamf, or package inventory to find hosts still below 149.0.7827.53. For a LOW verdict, there is no fixed mitigation SLA; keep this in routine hygiene and drive closure through your standard patch governance.
What doesn't work
  • Network perimeter blocking alone does not solve this, because the trigger is ordinary web content delivered over normal browsing paths.
  • EDR malware signatures will not reliably catch a logic flaw in browser navigation enforcement; there may be no malware artifact at all.
  • Server-side patching is irrelevant here; the vulnerable component is the endpoint browser, so internet-facing appliance patching does nothing.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it as python3 chrome_cve_2026_11184_check.py on macOS/Linux or py chrome_cve_2026_11184_check.py on Windows; no admin rights are required for standard install paths, but wider file-system access improves discovery coverage.

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

import os
import re
import sys
import subprocess
import platform
from pathlib import Path

TARGET = (149, 0, 7827, 53)


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_ver(a, b):
    return (a > b) - (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 '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def candidate_paths():
    paths = []
    system = platform.system().lower()

    if system == 'windows':
        envs = [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]
        rels = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe'
        ]
        for base in envs:
            if base:
                for rel in rels:
                    paths.append(Path(base) / rel)
    elif system == 'darwin':
        paths.extend([
            Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            Path('/Applications/Chromium.app/Contents/MacOS/Chromium')
        ])
    else:
        paths.extend([
            Path('/usr/bin/google-chrome'),
            Path('/usr/bin/google-chrome-stable'),
            Path('/usr/bin/chromium'),
            Path('/usr/bin/chromium-browser'),
            Path('/opt/google/chrome/chrome')
        ])
    return paths


def get_version_from_binary(path):
    if not path.exists():
        return None
    out = run_cmd([str(path), '--version'])
    return parse_version(out)


def get_windows_registry_version():
    keys = [
        r'HKLM\Software\Google\Chrome\BLBeacon',
        r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\Software\Google\Chrome\BLBeacon'
    ]
    for key in keys:
        out = run_cmd(['reg', 'query', key, '/v', 'version'])
        ver = parse_version(out)
        if ver:
            return ver
    return None


def discover_version():
    system = platform.system().lower()

    if system == 'windows':
        ver = get_windows_registry_version()
        if ver:
            return ver, 'registry'

    for path in candidate_paths():
        ver = get_version_from_binary(path)
        if ver:
            return ver, str(path)

    common_cmds = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']
    for cmd in common_cmds:
        out = run_cmd([cmd, '--version'])
        ver = parse_version(out)
        if ver:
            return ver, cmd

    return None, None


def main():
    ver, source = discover_version()
    if not ver:
        print('UNKNOWN - Chrome/Chromium version not found')
        sys.exit(2)

    ver_str = '.'.join(str(x) for x in ver)
    if cmp_ver(ver, TARGET) < 0:
        print(f'VULNERABLE - detected version {ver_str} from {source}; needs >= 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED - detected version {ver_str} from {source}; meets >= 149.0.7827.53')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a stop-everything browser zero-day. Pull a report of Chrome versions below 149.0.7827.53, confirm auto-update health, and fold remediation into your normal browser ring deployment; for a LOW verdict there is no noisgate mitigation SLA and you should treat it as backlog hygiene, while the noisgate remediation SLA is also backlog-oriented with no fixed deadline. If your browser fleet is badly behind or largely unmanaged, accelerate locally, but this still belongs well below any server-side RCE, KEV-listed item, or browser sandbox escape in the queue.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop
  2. Chromium issue 502777516
  3. Chromium Security page
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. Canadian Centre for Cyber Security advisory AV26-544
  8. SecurityWeek coverage of Chrome 149 patch set
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.