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

Inappropriate implementation in Enterprise in Google Chrome prior to 149

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

This is a lockpick that only matters after someone is already standing at the door

CVE-2026-11229 is an *Enterprise* component flaw in Google Chrome that affects desktop builds prior to 149.0.7827.53 on Linux and prior to 149.0.7827.53/54 on Windows and macOS. The vendor description says a *local attacker* can achieve privilege escalation, but only with *physical access to the device*; that is the whole story here. This is not a webpage bug, not a drive-by, and not something an internet scanner is going to find or weaponize at scale.

The vendor's MEDIUM 6.1 baseline overstates operational urgency for most enterprises. Privilege escalation is serious in a lab, but the attack path already assumes the attacker is at the device, which means this is either a stolen/unlocked endpoint, insider misuse, kiosk abuse, or post-initial-access cleanup. That prerequisite collapses the exposed population so hard that the real-world priority lands in LOW, not because the bug is harmless, but because the reachable blast radius is narrow.

"This is a hands-on keyboard problem, not a fleet-wide remote fire drill."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land hands-on access to a vulnerable endpoint

The attacker needs a Chrome desktop install older than the fixed 149.0.7827.53 line and must be physically present at the device. There is no remotely reachable service here; the initial condition is an at-console adversary or someone holding the laptop. *Weaponized tool:* none publicly documented.
Conditions required:
  • Chrome desktop version is older than the fixed build
  • Attacker has physical access to the target device
  • Enterprise feature path is present on the host
Where this breaks in practice:
  • Physical access requirement eliminates internet-scale exploitation
  • Many enterprise endpoints are encrypted, locked, and managed
  • Lost/stolen-device scenarios often fail if the device is powered off or locked
Detection/coverage: External scanners and ASM tools have effectively no coverage because exploitation is local/physical. Version inventory from EDR, MDM, or software asset tooling is the practical detection path.
STEP 02

Obtain a usable local execution context

A local attacker still needs some practical way to execute or interact on the system long enough to trigger the flawed Enterprise implementation. That usually implies an unlocked session, weak kiosk controls, shared workstation abuse, or another pre-existing local foothold. *Weaponized tool:* no public PoC or exploit framework found in reviewed sources.
Conditions required:
  • System is unlocked or attacker can interact locally
  • Local execution or abuse path exists on the endpoint
Where this breaks in practice:
  • Auto-lock, smartcard login, and kiosk hardening break many real attacks
  • Physical presence without session access often goes nowhere on modern laptops
Detection/coverage: Look for anomalous local logons, session unlocks, kiosk breakouts, and interactive console activity around Chrome launches. EDR can see the *context* but not reliably signature this CVE specifically.
STEP 03

Trigger the Enterprise flaw for privilege gain

The attacker abuses the inappropriate implementation in Chrome's Enterprise code path to elevate privileges beyond what they should have locally. Public details are thin, so the exact primitive is not yet well described in open sources; that uncertainty is why you should treat this as a local hardening and patching issue, not a detection engineering centerpiece. *Weaponized tool:* none publicly documented; reference coverage indicates no known public exploits.
Conditions required:
  • Target is actually vulnerable
  • Attacker can exercise the affected Enterprise code path
Where this breaks in practice:
  • No public exploit steps lower copycat risk
  • Thin technical detail slows opportunistic abuse
Detection/coverage: No high-confidence network or IDS signature exists. Post-event detection is more likely via EDR telemetry on spawned processes, privilege changes, or unexpected parent/child chains involving Chrome.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo known active exploitation in reviewed sources. Not listed in CISA KEV, and reviewed coverage does not describe live campaigns.
Public PoC availabilityNo public PoC found. Reviewed aggregator coverage shows no exploit references, and no researcher write-up with reproduction steps was identified.
EPSS0.00008 (*prompt-supplied intel*). That is effectively floor-level exploitation probability and aligns with the local/physical-only attack path.
KEV statusNot KEV-listed as of the reviewed CISA catalog source; no KEV add date exists.
CVSS vector meaningCVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N means physical access required, no prior privileges, no user interaction, and high confidentiality/integrity impact *if* the attacker is already at the device.
Affected versionsChrome Enterprise desktop prior to 149.0.7827.53. Public ecosystem advisories describe fixed desktop builds as 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/macOS.
Fixed versionsPatch line: 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS). If your distro or enterprise packaging backports Chrome fixes, trust the vendor package metadata rather than upstream numbering alone.
Exposure / scanning realityInternet exposure is basically irrelevant. Shodan/Censys-style discovery does not map cleanly because the exploit path is local and physical, so reachable population is constrained to endpoints an attacker can touch.
Disclosure timelineCVE published June 4, 2026. Google pushed the 149.0.7827.53/.54 desktop update on May 29, 2026 and government advisory amplification followed on June 3, 2026.
Reporter / creditsNot publicly credited in the reviewed sources. Available advisories name the bug class and affected version line, but do not expose a public researcher attribution for this CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.9/10)

The decisive factor is the physical-access requirement. That turns this from a remotely exploitable fleet problem into a narrow endpoint abuse case, so the reachable population and attacker scaling potential are both sharply limited.

HIGH Attack-path friction is materially higher than the vendor score suggests
MEDIUM Exact exploitation mechanics are underspecified in public sources

Why this verdict

  • Major downgrade for attacker position: vendor starts at 6.1, but AV:P means the attacker must be physically at the device, which implies a stolen, unattended, kiosk, insider, or already-compromised endpoint scenario rather than internet-reachable abuse.
  • Further downgrade for exposure population: Chrome is ubiquitous, but this specific step is not externally exposed. A remote adversary cannot spray this across 10,000 hosts the way they can with browser RCE, gateway bugs, or VPN flaws.
  • Further downgrade for operational evidence: no KEV listing, no active-exploitation reporting, no public PoC, and a near-zero EPSS all argue against emergency handling.

Why not higher?

If this were unauthenticated remote, sandbox-escape-adjacent, or already being used in the wild, the score would jump fast because Chrome is everywhere. But the physical/local prerequisite is a hard gate, and public sources do not show an exploit ecosystem forming around it.

Why not lower?

It still produces privilege escalation on a real enterprise endpoint, which matters for shared workstations, kiosks, and stolen-but-unlocked devices. Also, Chrome is massively deployed, so even a narrow local bug deserves routine correction rather than a paperwork-only dismissal.

05 · Compensating Control

What to do — in priority order.

  1. Enforce aggressive screen lock and full-disk encryption — Make physical possession insufficient for exploitation. Auto-lock, pre-boot authentication, and disk encryption are the best compensating controls because they directly attack the main prerequisite; for a LOW verdict there is no mitigation SLA, so treat this as backlog hygiene and verify policy coverage in the normal endpoint hardening cycle.
  2. Harden kiosk and shared-device profiles — If you run Chrome in kiosk, lab, or front-desk scenarios, reduce the chance of local interaction abuse with restricted shells, session timeouts, and peripheral controls. These are the few environments where this CVE is more than theoretical; again, no mitigation SLA applies for LOW, so fold this into standard workstation baseline maintenance.
  3. Use asset inventory to find pre-149 builds — Pull Chrome version data from EDR, MDM, or software inventory and identify hosts below the fixed version line. This is the practical control because network scanners will not meaningfully surface a local/physical-only browser flaw; for LOW, handle in routine backlog hygiene.
What doesn't work
  • A perimeter WAF or email gateway does nothing here because the attack is not a remote content-delivery path.
  • Internet attack-surface management will not prioritize this correctly because there is no meaningful external service exposure to measure.
  • MFA does not materially help once the attacker is already physically interacting with an unlocked local session.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote execution tool. Invoke with python3 check_chrome_cve_2026_11229.py on macOS/Linux or py check_chrome_cve_2026_11229.py on Windows; no administrator rights are required, but the script needs permission to execute Chrome binaries or read their standard install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11229.py
# Detects whether Google Chrome is older than 149.0.7827.53.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (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 compare_versions(a, b):
    return (a > b) - (a < b)


def run_version(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)
        out = (p.stdout or '').strip()
        return parse_version(out), out
    except Exception:
        return None, ''


def candidate_commands():
    system = platform.system()
    cmds = []

    if system == 'Windows':
        env = os.environ
        local = env.get('LOCALAPPDATA', '')
        pf = env.get('PROGRAMFILES', '')
        pfx86 = env.get('PROGRAMFILES(X86)', '')
        candidates = [
            Path(local) / 'Google/Chrome/Application/chrome.exe',
            Path(pf) / 'Google/Chrome/Application/chrome.exe',
            Path(pfx86) / 'Google/Chrome/Application/chrome.exe',
        ]
        for p in candidates:
            if p and p.exists():
                cmds.append([str(p), '--version'])
        where = shutil.which('chrome') or shutil.which('chrome.exe')
        if where:
            cmds.append([where, '--version'])

    elif system == 'Darwin':
        candidates = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ]
        for p in candidates:
            if Path(p).exists():
                cmds.append([p, '--version'])
        for name in ['google-chrome', 'chrome', 'chromium', 'chromium-browser']:
            where = shutil.which(name)
            if where:
                cmds.append([where, '--version'])

    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
            where = shutil.which(name)
            if where:
                cmds.append([where, '--version'])
        extra = [
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
        ]
        for p in extra:
            if Path(p).exists():
                cmds.append([p, '--version'])

    # de-dup while preserving order
    seen = set()
    uniq = []
    for c in cmds:
        key = tuple(c)
        if key not in seen:
            seen.add(key)
            uniq.append(c)
    return uniq


def main():
    cmds = candidate_commands()
    if not cmds:
        print('UNKNOWN - Google Chrome executable not found in common locations')
        sys.exit(2)

    for cmd in cmds:
        ver, raw = run_version(cmd)
        if ver is None:
            continue

        if compare_versions(ver, FIXED) < 0:
            print(f'VULNERABLE - detected version {".".join(map(str, ver))} via {cmd[0]}')
            sys.exit(1)
        else:
            print(f'PATCHED - detected version {".".join(map(str, ver))} via {cmd[0]}')
            sys.exit(0)

    print('UNKNOWN - executable found but version could not be parsed')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: do not burn emergency cycles on this one unless you run exposed kiosks, shared consoles, or have a recent lost-device incident. For a LOW verdict there is no noisgate mitigation SLA and effectively no noisgate remediation SLA beyond backlog hygiene, so roll the Chrome update into your normal browser maintenance cadence, verify encryption and auto-lock coverage this cycle, and clear any straggler builds below 149.0.7827.53 during the next routine endpoint patch wave.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop
  2. Canadian Centre for Cyber Security advisory AV26-544
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS overview
  5. SecurityWeek - Chrome 149 Patches 429 Vulnerabilities
  6. VulDB entry for CVE-2026-11229
  7. CVE.org record for CVE-2026-11229
  8. NVD record for CVE-2026-11229
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.