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

Script injection in Accessibility in Google Chrome prior to 149

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

This is a hidden door inside a house key you already should not have handed out

CVE-2026-11157 is a UXSS/script-injection flaw in Chrome Accessibility affecting Google Chrome before 149.0.7827.53. The attack does not start from a website alone: the attacker must first convince the user to install a malicious Chrome extension, after which the crafted extension can inject arbitrary scripts or HTML through the Accessibility component.

Google's Medium 5.4 label is directionally fair in a vacuum, but for enterprise patch triage this lands lower in practice. The decisive friction is the prerequisite chain: user interaction + malicious extension installation + browser-side execution. In managed fleets that already restrict extension installs, the reachable population collapses fast; in unmanaged fleets, the extension problem is the bigger risk than this individual bug.

"This is a bad-extension amplifier, not a clean remote exploit. Patch it, but don't let CVSS bully your queue."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a malicious extension

The attacker needs the user to install a crafted Chrome extension. That can happen via direct social engineering, a trojanized productivity tool, or a store-listed extension that later turns hostile. The extension is the delivery vehicle; without it, this CVE does not fire.
Conditions required:
  • User can install extensions or policy allows the specific extension
  • Attacker can socially engineer the user or control an extension supply-chain path
  • Chrome version is older than 149.0.7827.53
Where this breaks in practice:
  • Managed Chrome commonly blocks or allowlists extensions
  • Users still see install prompts and trust indicators
  • Security teams often monitor new extension installs on managed endpoints
Detection/coverage: Good administrative coverage if you manage Chrome extensions centrally; weak coverage on unmanaged browsers. Traditional network scanners will not find this.
STEP 02

Trigger Accessibility UXSS path

Once installed, the crafted extension abuses the Accessibility bug to inject arbitrary script or HTML. The practical value is bypassing some intended browser trust boundaries, turning a malicious extension into a broader page-manipulation primitive than policy intended.
Conditions required:
  • Extension executes in the victim browser
  • Victim browses content/context the attacker wants to influence
  • The vulnerable code path in Accessibility is reachable from the extension
Where this breaks in practice:
  • Bug details are typically restricted until patch adoption rises
  • Some extension permission models and site-access scoping may still constrain impact
  • Browser restarts and extension review/removal break persistence
Detection/coverage: Endpoint telemetry may show unusual extension behavior, DOM injection, or newly installed extension IDs, but signature-level CVE detection is limited.
STEP 03

Use injected script for browser-layer abuse

With UXSS, the attacker can tamper with page content, phish within trusted sites, or steal data exposed to the browser context that would otherwise be isolated. This is serious for the affected user session, but it is still bounded by browser/session context rather than immediate host takeover.
Conditions required:
  • Victim accesses targeted web apps
  • Injected content can run in the relevant page context
  • Session cookies or sensitive workflows are present
Where this breaks in practice:
  • MFA, conditional access, and re-auth challenges reduce session abuse value
  • HttpOnly cookies and app-side anti-CSRF controls still matter
  • EDR/browser protection can flag suspicious extension-driven behavior
Detection/coverage: Look for abnormal extension IDs, sudden page-script injections tied to extension processes, and browser telemetry showing unauthorized extension activity.
STEP 04

Escalate through stolen sessions or user trust

Real-world impact is usually downstream: session theft, internal app tampering, or credential capture through browser trust abuse. The blast radius is often one user profile at a time, unless the same malicious extension is broadly deployed across the fleet.
Conditions required:
  • The attacker can monetize or reuse stolen browser context
  • The extension remains installed long enough to act
  • Targeted SaaS sessions are valuable
Where this breaks in practice:
  • Per-user scope limits immediate enterprise-wide blast radius
  • SOC can respond by revoking sessions and removing the extension
  • Managed profile resets and browser policy refreshes contain spread
Detection/coverage: Identity logs and SaaS session anomaly detections are more useful here than classic vulnerability scanners.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in reviewed sources as of 2026-06-05.
KEV statusNot listed in CISA KEV as of 2026-06-05 (CISA KEV).
PoC availabilityNo public PoC located in primary sources reviewed; Chromium issue details are typically restricted until patch uptake improves.
EPSS0.00013 (very low), which matches the heavy prerequisite chain and lack of observed exploitation in current reporting.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N — the score assumes network reachability, but the real-world gate is extension installation by the victim.
Affected versionsGoogle Chrome before 149.0.7827.53 on desktop platforms; Chrome release materials show 149.0.7827.53/.54 for Windows/macOS early stable and 149.0.7827.53 for Linux-related testing artifacts.
Fixed version149.0.7827.53 (Linux / baseline fix) and 149.0.7827.53/.54 for Windows and macOS early stable rollout references.
Exposure realityNot internet-enumerable. Shodan/Censys/FOFA-style exposure data is mostly irrelevant because this is a client-side browser bug, not a remotely scanned service.
Disclosure date2026-06-04 in the published CVE record aggregation reviewed.
Researcher / reportingPublic sources reviewed credit the Chrome CNA / Chromium issue tracker; no external researcher attribution was exposed in the accessible primary references.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.4/10)

The single biggest severity suppressor is that exploitation requires the victim to install a malicious extension first. That makes this a post-governance browser trust failure, not a clean unauthenticated remote compromise path, and sharply narrows both reachable population and immediate blast radius.

HIGH Prerequisite-chain assessment: malicious extension install is the decisive friction
MEDIUM Impact assessment: likely browser trust-boundary bypass rather than host compromise
MEDIUM Exploit maturity assessment: no public PoC or KEV evidence found in reviewed sources

Why this verdict

  • Downgraded for attacker position: despite the AV:N vector, the attacker effectively needs user-enabled code execution inside the browser via a malicious extension.
  • Downgraded for exposure population: managed enterprise Chrome deployments often block or allowlist extensions, so only a subset of fleets are realistically exposed.
  • Downgraded for blast radius: the immediate impact is usually per-user browser/session abuse, not instant fleet-wide compromise or server-side takeover.

Why not higher?

This is not a drive-by web exploit and not a clean pre-auth remote code execution path. The attack chain assumes a prior governance failure around extension installation, which is strong downward pressure on enterprise priority.

Why not lower?

It is still a real trust-boundary break in a massively deployed browser, and malicious extensions are a proven attacker vehicle. In environments that allow user-installed extensions, this bug can amplify an otherwise constrained extension into more dangerous page-level abuse.

05 · Compensating Control

What to do — in priority order.

  1. Allowlist extensions only — If you manage Chrome, move users to an approved-extension-only model using enterprise policy. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the highest-value control because it kills the prerequisite the CVE depends on.
  2. Block high-risk permissions — Use Chrome app/extension policy controls to block or restrict extensions requesting broad site access and sensitive permissions. For a LOW verdict there is no SLA (treat as backlog hygiene); implement as part of normal browser-governance hardening.
  3. Review newly installed extensions — Hunt for recent installs, especially consumer productivity tools, AI helpers, coupon/shopping extensions, and force-installed third-party helpers. For a LOW verdict there is no SLA (treat as backlog hygiene), but this is the fastest way to cut practical risk while patching rolls through normal channels.
  4. Enable user request workflows — Require users to request extensions through admin approval instead of self-installing from the store. For a LOW verdict there is no SLA (treat as backlog hygiene); this turns extension risk from an endpoint problem into a governed change-control problem.
What doesn't work
  • Network perimeter controls don't help much; this is executed inside the browser after extension installation, not through an exposed server port.
  • WAF rules are mostly irrelevant because the exploit primitive lives in the local browser/extension trust boundary.
  • MFA alone reduces downstream session abuse but does not stop malicious DOM/script injection in the browser session already running on the endpoint.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke with python3 chrome_cve_2026_11157_check.py on macOS/Linux or py chrome_cve_2026_11157_check.py on Windows; standard user rights are usually enough, though Windows registry access may be easier with normal desktop-user context than with locked-down service accounts.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11157 local exposure check for Google Chrome
# Checks installed Chrome version against fixed version 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    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 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_windows_version():
    candidates = [
        [r'reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
        [r'reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver, out

    exe_paths = [
        r'C:\Program Files\Google\Chrome\Application\chrome.exe',
        r'C:\Program Files (x86)\Google\Chrome\Application\chrome.exe',
        os.path.expandvars(r'%LOCALAPPDATA%\Google\Chrome\Application\chrome.exe'),
    ]
    for path in exe_paths:
        if path and os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return ver, out
    return None, ''


def get_macos_version():
    path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(path):
        out = run_cmd([path, '--version'])
        ver = parse_version(out)
        if ver:
            return ver, out
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        out = run_cmd(['/usr/bin/defaults', 'read', plist, 'KSVersion'])
        ver = parse_version(out)
        if ver:
            return ver, out
    return None, ''


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


def compare_versions(a, b):
    return (a > b) - (a < b)


def main():
    system = platform.system().lower()
    if 'windows' in system:
        ver, raw = get_windows_version()
    elif 'darwin' in system:
        ver, raw = get_macos_version()
    elif 'linux' in system:
        ver, raw = get_linux_version()
    else:
        print('UNKNOWN - Unsupported OS: {}'.format(platform.system()))
        sys.exit(2)

    if not ver:
        print('UNKNOWN - Google Chrome version not found')
        sys.exit(2)

    ver_str = '.'.join(str(x) for x in ver)
    fixed_str = '.'.join(str(x) for x in FIXED)

    if compare_versions(ver, FIXED) < 0:
        print('VULNERABLE - Installed Chrome version {} is older than fixed version {}'.format(ver_str, fixed_str))
        sys.exit(1)
    else:
        print('PATCHED - Installed Chrome version {} is at or above fixed version {}'.format(ver_str, fixed_str))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as browser hygiene, not an emergency fire drill. Because the reassessed verdict is LOW, there is no noisgate mitigation SLA and no SLA (treat as backlog hygiene) for compensating controls; use your normal browser governance cycle to tighten extension allowlisting and approval workflows. For the actual fix, move vulnerable Chrome versions to 149.0.7827.53 or later inside the noisgate remediation SLA for LOW findings — backlog hygiene rather than a dated emergency — but if you discover ungoverned user-installed extensions in a sensitive population, accelerate those subsets ahead of the general fleet.

Sources

  1. Chrome Releases: Early Stable Update for Desktop (May 29, 2026)
  2. Vulnerability-Lookup entry for CVE-2026-11157
  3. CISA Known Exploited Vulnerabilities Catalog
  4. Managing Extensions in Your Enterprise
  5. Chrome app and extension policies
  6. Install and manage extensions
  7. Chrome for Testing availability
  8. Chrome Enterprise previous release notes
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.