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

Inappropriate implementation in Extensions in Google Chrome prior to 149

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

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.

"This looks like a chainable Chrome boundary bug, not a stand-alone internet fire."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land code in the renderer first

The attacker needs an initial browser foothold, typically via a separate Chrome renderer bug or a malicious content path that reaches renderer execution. In practical terms, this means CVE-2026-11168 is rarely the opening move; it is a follow-on primitive inside a larger chain. Weaponized tooling here is whatever delivered the first-stage renderer compromise, not this CVE alone.
Conditions required:
  • User visits attacker-controlled content or another weakness is already present
  • Attacker can execute or reliably influence code flow in the renderer process
Where this breaks in practice:
  • 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
Detection/coverage: Most scanners do not validate this exploit path directly. Detection is indirect: browser crash telemetry, exploit-protection alerts, renderer sandbox anomalies, and suspicious child-process/browser behavior in EDR.
STEP 02

Cross the extension boundary

With renderer control or equivalent boundary influence, the attacker abuses the Extensions flaw to bypass intended policy or implementation restrictions. If the user-supplied description is accurate, the CVE acts as a confidentiality-oriented boundary break; if the official Chrome archive label is the right one, it is still an extension-policy enforcement failure rather than a raw code-exec bug.
Conditions required:
  • Target is running a vulnerable Chrome build before 149.0.7827.53
  • The vulnerable extension/path is reachable from the compromised context
Where this breaks in practice:
  • 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
Detection/coverage: Limited signature coverage. Browser forensics, extension-install telemetry, Chrome enterprise policy logs, and unusual extension API use are the best bets.
STEP 03

Extract sensitive material

The practical impact is data exposure or a policy bypass within the browser trust model, not broad host compromise on its own. Typical value comes from session tokens, cross-origin data, enterprise app state, or stepping-stone access that helps the attacker continue the operation.
Conditions required:
  • Sensitive browser-resident data exists in the affected context
  • Attacker can exfiltrate or reuse what is exposed
Where this breaks in practice:
  • 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
Detection/coverage: Hard to scan for remotely. Focus on suspicious browser network egress, abnormal session reuse, and identity telemetry showing token replay or unusual post-browser access.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the sources reviewed, and not in CISA KEV.
KEV statusNot listed in the CISA KEV catalog as of the reviewed sources.
Proof-of-concept availabilityNo 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.
EPSSUser-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 realityVendor 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 meaningCVSS: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 versionsChrome 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 versionsFixed 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 realityThis 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 / reportingPublicly 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.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.1/10)

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.

MEDIUM Severity reassessment
LOW Exact bug semantics because the public metadata for `CVE-2026-11168` is inconsistent across the user intel and Google's public archive

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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning: treat this as a MEDIUM browser-client issue unless you have independent evidence it is being chained in your environment. There is no noisgate mitigation SLA — go straight to the 365-day remediation window and make sure Chrome reaches 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

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases - 2026 archive
  3. Chromium Issue Tracker - issue 502256049
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS
  7. FIRST EPSS Model
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.