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

Inappropriate implementation in CSS in Google Chrome prior to 149

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

This is a forged visitor badge at the browser front desk, not a master key to the building

CVE-2026-11186 is a Chrome CSS implementation flaw that can let a remote attacker inject arbitrary script or HTML via a crafted page. Affected builds are Chrome versions prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS; Android inherits the corresponding desktop security fixes in 149.0.7827.59 unless otherwise noted by Google.

Google scored it MEDIUM (6.1), and that is basically right. The amplifier is obvious: Chrome is everywhere, so a browser bug can touch a very large population fast. But the downward pressure matters more here: exploitation requires user interaction, impact is browser-session level rather than OS-level, there is no current KEV listing or public in-the-wild evidence, and the technical details are still partly restricted while the fix rolls out.

"Broad client exposure, but this is still a one-click browser-origin bug, not a host takeover event."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Stage a lure with a crafted HTML/CSS payload

The attacker builds a web page that exercises the buggy CSS path and positions injected HTML or script to execute in an unintended browser context. No public weaponized kit is visible from authoritative sources yet, so this is currently a custom exploit path rather than commodity tradecraft.
Conditions required:
  • Attacker can host or inject a malicious web page
  • Victim uses a vulnerable Chrome build before 149.0.7827.53
Where this breaks in practice:
  • No public PoC was located in authoritative or mainstream security sources
  • Exact bug details may still be embargoed/restricted while the fix propagates
Detection/coverage: Exposure scanners can identify vulnerable Chrome versions on managed endpoints, but network scanners cannot reliably see this bug from the Internet.
STEP 02

Get the user to browse to it with phish / malvertising / compromised site

The attacker still needs a victim to render the page. In real enterprise deployments that means phishing, ads, chat links, a compromised third-party site, or watering-hole delivery.
Conditions required:
  • User interaction: victim must visit or render attacker-controlled content
  • Enterprise controls do not block the destination first
Where this breaks in practice:
  • Email security, DNS filtering, Secure Web Gateway, and browser reputation systems reduce click-through
  • Users must actually load the page; this is not an unauthenticated server-side exploit
Detection/coverage: Web proxy, DNS, and email telemetry may catch delivery. Browser exploit-specific signatures are unlikely unless a vendor publishes IOC logic later.
STEP 03

Trigger browser-origin confusion with the CSS exploit

If the vulnerable path is reached, the attacker may inject script or HTML in a way Chrome should have prevented. Practically, that is a browser trust-boundary break: it can enable session theft, DOM tampering, or actions as the user within the affected browsing context.
Conditions required:
  • Victim reaches the vulnerable code path
  • Chrome mitigations do not fully contain the impact for that case
Where this breaks in practice:
  • Chrome sandboxing and Site Isolation reduce what a single renderer-origin bug can typically reach
  • The CVSS impact is low/low/none, which argues against broad system compromise
Detection/coverage: EDR is usually weak at detecting successful UXSS-style browser abuse unless it later causes credential theft, suspicious child processes, or abnormal token use.
STEP 04

Monetize the browser session using credential theft or transaction tampering

The realistic payoff is browser-session abuse, not instant host ownership. Think stolen cookies, altered page content, fake prompts, or actions in SaaS apps where the victim is already authenticated.
Conditions required:
  • Victim has active sessions worth stealing or abusing
  • Targeted application lacks additional session-binding or step-up controls
Where this breaks in practice:
  • MFA does not stop session reuse once tokens are stolen, but step-up auth and conditional access can limit high-risk actions
  • Blast radius is usually bounded to the user and active browser context, not fleet-wide host compromise
Detection/coverage: Identity telemetry, impossible-travel/session-anomaly analytics, and SaaS audit logs are more likely to reveal impact than host telemetry.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current evidence of active exploitation found in Google release notes, and the CVE is not present in CISA KEV based on catalog checks.
Proof-of-concept availabilityNo public PoC located in authoritative sources reviewed as of 2026-06-05; treat that as an absence-of-evidence call, not proof none exists.
EPSS0.00026 (~0.026%), which is very low. That supports deprioritizing this below browser RCEs and KEV-listed Chrome bugs.
KEV statusNot KEV-listed as checked against the CISA Known Exploited Vulnerabilities Catalog.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N — remote and easy to trigger, but requires user interaction and does not score for availability impact.
Affected versionsChrome prior to 149.0.7827.53; Google states fixed stable desktop builds are 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux, 149.0.7827.53/54 or later on Windows/macOS, and corresponding Android build 149.0.7827.59 carrying desktop security fixes.
Scanning / exposure realityThis is a client-side browser issue, so Shodan/Censys/FOFA are poor exposure gauges. Real exposure should be measured from EDR, software inventory, Chrome enterprise management, or package telemetry—not Internet scanning.
Disclosure timelineGoogle published the stable desktop update on 2026-06-02; the CVE metadata in your intel block shows disclosed 2026-06-04.
ReporterGoogle release notes attribute the bug as reported by Google on 2026-04-15.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (6.4/10)

The decisive factor is user interaction plus browser-scoped impact: the attacker needs the victim to render malicious content, and the likely outcome is session abuse or web-origin compromise rather than direct host takeover. Chrome's huge install base keeps this relevant, but the lack of KEV/in-the-wild evidence and the absence of OS-level impact keep it out of HIGH.

HIGH No active exploitation / no KEV status
MEDIUM Practical exploitability while bug details remain partially restricted
HIGH Affected/fixed version boundaries from Google's release notes

Why this verdict

  • Baseline holds: Google already placed this at MEDIUM 6.1, and the published vector says remote/no-privs but *user-interaction required* with only low confidentiality/integrity impact.
  • User must browse attacker content: that implies phishing, malvertising, or a compromised site. Modern email gateways, SWGs, DNS filtering, and Safe Browsing add real-world drag before exploit code ever runs.
  • Browser bug, not box-owning bug: this is script/HTML injection in Chrome CSS, not a memory-corruption path to native code execution. The blast radius is usually the user's active browser session and web apps, not the endpoint OS.
  • No exploit pressure signals: no KEV entry, no public exploitation note from Google, and an EPSS of 0.00026 all push this down versus Chrome bugs that are already being used in the wild.
  • Reachable population is broad but not uniformly exploitable: Chrome is ubiquitous, but only vulnerable unmanaged or not-yet-updated clients matter, and Chrome's auto-update materially shrinks the exposure window in managed fleets.

Why not higher?

This does not earn HIGH because the chain is not straight-through unauthenticated compromise of a service or endpoint. The attacker needs a user to render malicious content, and the published impact is low confidentiality/low integrity with no availability hit, which is a long way from reliable enterprise-wide compromise.

Why not lower?

This is not LOW because Chrome is one of the widest exposure surfaces in the enterprise, and a browser-origin break can still steal SaaS sessions or tamper with business workflows. Even without RCE, one-click client-side abuse against a heavily used browser deserves real patching attention.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Verify policy-backed auto-update on all managed endpoints and browsers, especially VDI and kiosk pools. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but auto-update validation should happen in the normal browser operations cycle because it closes this and the other 428 fixes in the same release.
  2. Filter risky web delivery paths — Tighten Secure Web Gateway, DNS, and phishing controls around newly registered domains, ad-tech categories, and user-clicked external links. There is no mitigation SLA — go straight to the 365-day remediation window, but this is the best temporary drag on the required user-interaction step.
  3. Harden session abuse defenses — Use conditional access, step-up auth for sensitive actions, and shorter session/token lifetimes where business allows. There is no mitigation SLA — go straight to the 365-day remediation window, and these controls specifically reduce the value of any browser-session theft this class of bug could enable.
  4. Inventory stragglers aggressively — Query software inventory, EDR, or Chrome enterprise telemetry for versions below 149.0.7827.53 and isolate unmanaged exceptions such as lab hosts, offline laptops, gold images, and nonpersistent VDI templates. There is no mitigation SLA — go straight to the 365-day remediation window, so use regular hygiene processes rather than emergency change windows.
What doesn't work
  • Relying on MFA alone does not solve browser-session theft; once a session cookie is stolen or an in-session action is performed, MFA may never be challenged again.
  • A perimeter vulnerability scanner will not tell you much here because Chrome clients are not meaningfully Internet-fingerprintable for this flaw.
  • Generic server-side WAF rules do little if the lure is a malicious page on the open web or a compromised third-party site rendered directly by the user.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet management tool. Invoke it as python3 chrome_cve_2026_11186_check.py on macOS/Linux or py chrome_cve_2026_11186_check.py on Windows; no admin rights are usually needed, though elevated access may help enumerate machine-wide install paths.

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

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

PATCH_LINUX = (149, 0, 7827, 53)
PATCH_WIN_MAC = (149, 0, 7827, 53)


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


def detect_linux():
    candidates = [
        shutil.which('google-chrome'),
        shutil.which('google-chrome-stable'),
        shutil.which('chromium-browser'),
        shutil.which('chromium'),
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable'
    ]
    for c in candidates:
        if c and os.path.exists(c):
            out = run_cmd([c, '--version'])
            v = parse_version(out)
            if v:
                return ('Linux', c, v, out)
    return None


def detect_macos():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
    ]
    for c in candidates:
        if os.path.exists(c):
            out = run_cmd([c, '--version'])
            v = parse_version(out)
            if v:
                return ('macOS', c, v, out)
    return None


def detect_windows():
    exe_names = []
    for base in filter(None, [
        os.environ.get('ProgramFiles'),
        os.environ.get('ProgramFiles(x86)'),
        os.environ.get('LocalAppData')
    ]):
        exe_names.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))

    for c in exe_names:
        if os.path.exists(c):
            out = run_cmd([c, '--version'])
            if not out:
                ps = f"(Get-Item '{c}').VersionInfo.ProductVersion"
                out = run_cmd(['powershell', '-NoProfile', '-Command', ps])
            v = parse_version(out)
            if v:
                return ('Windows', c, v, out)
    return None


def main():
    system = platform.system().lower()
    info = None

    if 'linux' in system:
        info = detect_linux()
    elif 'darwin' in system:
        info = detect_macos()
    elif 'windows' in system:
        info = detect_windows()
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

    if not info:
        print('UNKNOWN: Google Chrome not found or version unreadable')
        sys.exit(2)

    os_name, path, version, raw = info
    patch = PATCH_LINUX if os_name == 'Linux' else PATCH_WIN_MAC

    print(f'Detected platform: {os_name}')
    print(f'Executable: {path}')
    print(f'Raw version output: {raw}')
    print(f'Parsed version: {".".join(map(str, version))}')
    print(f'Patched threshold: {".".join(map(str, patch))}')

    if version_ge(version, patch):
        print('PATCHED')
        sys.exit(0)
    else:
        print('VULNERABLE')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning, pull an endpoint inventory of Chrome versions and verify that managed systems are at least 149.0.7827.53/149.0.7827.54, with special attention to VDI images, kiosks, and unmanaged exceptions where auto-update often fails silently. Because this is MEDIUM and there is no mitigation SLA — go straight to the 365-day remediation window under the noisgate mitigation SLA model; the practical plan is to validate browser-update policy now and clean up stragglers in your normal patch cycle, while the actual version upgrade must still land within 365 days under the noisgate remediation SLA.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. Google Chrome Releases 2026 archive
  3. Chromium issue 502805170
  4. Chromium Security page
  5. Chromium Site Isolation overview
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. 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.