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

Insufficient policy enforcement in Paint in Google Chrome prior to 149

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

This is a forged backstage pass, not a crowbar through the data-center door

CVE-2026-11142 is a Chrome client-side same-origin policy bypass in the Paint component. A victim has to browse to attacker-controlled HTML, and affected builds are Chrome versions before 149.0.7827.53; Google lists the fix in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and Mac, with Android inheriting the same desktop security fixes in 149.0.7827.59.

Google's MEDIUM 6.5 baseline is close, but a little generous once you do the friction audit. This is not wormable, not unauthenticated service exposure, not code execution, and not a perimeter-scannable server bug; it is a user-driven browser trust-boundary break that matters because Chrome is everywhere, but the practical blast radius usually stays bounded to the victim's browser session and whatever web apps they are already logged into.

"A real browser trust-boundary bug, but still a lure-driven client-side issue with narrow per-user blast radius."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on malicious HTML

The attacker needs to deliver a crafted web page or ad frame that the victim opens in a vulnerable Chrome build. The effective tool is just crafted HTML/JavaScript delivered over the web; no public named exploit kit or repo was found during this review. Because the bug sits in a browser rendering path, the initial access method is classic lure traffic rather than network reachability to an exposed enterprise service.
Conditions required:
  • Victim is using Chrome prior to 149.0.7827.53
  • Victim browses to attacker-controlled or attacker-influenced content
  • JavaScript and the relevant rendering path are reachable
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Requires a viable lure or ad-delivery path
  • Enterprise browser isolation or aggressive ad/script controls can suppress the page before exploit logic runs
Detection/coverage: Perimeter vuln scanners will miss this entirely. Coverage comes from browser version inventory, EDR telemetry, web proxy logs, and enterprise browser-management compliance reporting.
STEP 02

Trigger Paint policy bypass

The malicious page exercises the vulnerable Paint code path to break expected same-origin enforcement. The practical offensive tool here is the browser's own rendering engine; the attacker is abusing a trust-boundary mistake, not dropping a payload on disk. Google kept the underlying Chromium issue restricted, which is typical when fix uptake is still in progress.
Conditions required:
  • The vulnerable Paint code path is actually hit by the crafted page
  • The browser has not auto-updated yet
Where this breaks in practice:
  • Bug details are restricted, which slows reliable weaponization
  • No public proof-of-concept or exploit repository was found
  • Modern Chrome hardening reduces exploit reliability for many renderer-side logic bugs
Detection/coverage: No signature-grade network IOC is likely. Detection is mostly indirect: suspicious cross-origin browser behavior, anomalous web session activity, or crash/telemetry artifacts if the page is unstable.
STEP 03

Abuse the broken origin boundary

Once origin checks are bypassed, the attacker can potentially perform actions the victim's browser should not permit across site boundaries. In the vendor-supplied scoring, the dominant impact is integrity, which points to cross-origin action abuse rather than full data disclosure or host compromise. The weaponized effect is account/session misuse inside the browser, not operating-system takeover.
Conditions required:
  • Victim is concurrently authenticated to target web apps
  • Target workflows depend on browser-enforced origin trust
  • Application-side defenses do not independently block forged actions
Where this breaks in practice:
  • Impact is often limited to the victim's current sessions
  • CSRF tokens, re-auth prompts, step-up MFA, and app-side origin checks can blunt downstream abuse
  • Not every site exposes a meaningful action primitive even if origin handling is weakened
Detection/coverage: Best detection lives in the web apps: impossible user actions, origin/referrer anomalies, abnormal session behavior, and identity-provider risk signals.
STEP 04

Translate browser abuse into enterprise impact

Real damage depends on what the victim can access: SSO portals, SaaS admin consoles, internal web apps, finance systems, or support tooling. On a 10,000-host fleet the population is large, but each successful exploit still usually burns down one user context at a time unless combined with broader identity or post-auth application weaknesses.
Conditions required:
  • Victim has access to sensitive enterprise web applications
  • Those applications trust the browser session enough for meaningful state changes
Where this breaks in practice:
  • Per-user blast radius is smaller than RCE or sandbox escape
  • No evidence of in-the-wild exploitation or KEV listing at disclosure
  • This is harder to operationalize at scale than browser memory-corruption bugs with code execution upside
Detection/coverage: SOC teams should correlate browser-version noncompliance with identity anomalies and suspicious SaaS admin actions; generic network IDS is low value here.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public active exploitation evidence found in the sources reviewed, and not listed in CISA KEV as of this reassessment.
Public PoC statusNo public PoC or exploit repo found via web search. The Chromium issue is present but access is restricted, which slows copycat weaponization.
EPSS0.00016 (user-supplied intel), which is extremely low and consistent with a non-KEV, client-side logic bug without public weaponization.
KEV statusNot KEV-listed. CISA's catalog did not show CVE-2026-11142 during this review.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — remote and low complexity, but requires user interaction and does not indicate code execution or availability impact.
Affected versionsGoogle describes Chrome prior to 149.0.7827.53 as affected. This is a broad client footprint problem because Chrome is ubiquitous, but it is still a browser-side exposure rather than an internet-facing service.
Fixed versionsDesktop fix lands in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). Google also states Android 149.0.7827.59 includes the same corresponding desktop security fixes.
Scanner / exposure realityNot internet-scannable in the Shodan/Censys/GreyNoise sense; those platforms will not tell you where vulnerable browsers sit. You need endpoint/browser inventory, MDM, EDR, or enterprise browser-management telemetry.
Disclosure timelineReported by Google on 2026-04-11 in the stable-channel fix list; publicly disclosed 2026-06-04 in the CVE/CNA record.
Researcher / reporterThe stable-channel advisory attributes the bug to Google rather than an external researcher, and the Chromium bug link is 501668745.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The decisive downward pressure is that this is a lure-dependent client-side browser bug, not an exposed server-side foothold. It can absolutely matter in a Chrome-heavy estate, but without RCE, KEV status, public weaponization, or broad blast radius beyond the victim's browser session, it stays in MEDIUM.

HIGH Affected/fixed version mapping from Google's release notes
MEDIUM Real-world exploitability assessment without public bug details
HIGH No KEV status and low exploitation signal at disclosure

Why this verdict

  • UI:R cuts the score down — the attacker needs the victim to load crafted web content, which is materially weaker than an internet-facing unauthenticated service exploit.
  • Client-side only, not perimeter-reachable — this is a browser-session problem, so Shodan/Censys-style exposure scaling does not apply and SOC teams must already have endpoint/browser inventory to even find it.
  • Integrity impact is real but bounded — the main consequence is cross-origin action abuse inside the victim's logged-in browser context, not host takeover or broad tenant compromise.
  • No exploitation evidence — no KEV listing, no public PoC found, and Google kept bug details restricted, all of which reduce immediate operational risk.
  • Chrome ubiquity keeps it from going LOW — unlike a niche plugin flaw, this sits in a massively deployed browser, so even a medium-grade trust-boundary bug can hit a large user population if version lag exists.

Why not higher?

There is no evidence here of sandbox escape, arbitrary code execution, wormability, or active exploitation. The attack still needs a victim browsing event and usually only buys the attacker whatever abuse they can squeeze from that user's active web sessions.

Why not lower?

A same-origin policy bypass is still a browser trust-boundary failure, not cosmetic noise. In a large enterprise with federated SaaS and always-on SSO sessions, per-user session abuse can translate into meaningful account actions, especially against internal admin portals and business apps.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use enterprise browser management, MDM, or endpoint tooling to drive Chrome to 149.0.7827.53/54 or later and measure drift. For a MEDIUM verdict there is no mitigation SLA, so keep this in normal change flow and close it inside the 365-day remediation window, though most teams should finish browser rollout much sooner because the operational cost is low.
  2. Tighten risky web content paths — Reduce exposure to malicious HTML delivery by hardening ad/script controls, disabling unnecessary extension sprawl, and using browser isolation for high-risk user groups. There is no mitigation SLA — go straight to the remediation window — but these controls are useful while patch compliance catches up.
  3. Watch for web-session abuse — Ask IAM and SaaS owners to review anomalous state-changing actions, suspicious origin/referrer patterns, and step-up authentication triggers from managed Chrome endpoints that remain below the fixed version. This is especially relevant for admin portals where a browser trust-boundary miss can still translate to real business impact.
  4. Prioritize exposed user populations — Front-load updates for admins, finance, HR, help desk, and developers who maintain long-lived authenticated browser sessions. Even without a formal mitigation deadline for MEDIUM, these cohorts carry more downstream blast radius if the browser session is abused.
What doesn't work
  • External vulnerability scanning doesn't help because vulnerable Chrome clients are not an internet-facing service surface.
  • A WAF by itself will not reliably stop a browser-internal same-origin policy bypass once the victim loads attacker-controlled content.
  • Rebooting browsers or hosts without updating does nothing durable; the vulnerable code path remains until the patched version is installed.
  • Email-only controls are insufficient because delivery can come from web ads, compromised sites, chat links, docs, or any other browser lure path.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR remote execution channel. Invoke with python3 chrome_cve_2026_11142_check.py; no admin rights are required for basic version detection, but broader path coverage on Windows/macOS/Linux is better with a standard managed-user context.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_cve_2026_11142_check.py
# Check Google Chrome version against CVE-2026-11142 fixed builds.
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

TARGET = (149, 0, 7827, 53)  # minimum fixed baseline


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text 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)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
        return (p.stdout or p.stderr).strip()
    except Exception:
        return ''


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

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        programfiles = os.environ.get('ProgramFiles', '')
        programfilesx86 = os.environ.get('ProgramFiles(x86)', '')
        paths = [
            os.path.join(programfiles, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(programfilesx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        for p in paths:
            if p and os.path.exists(p):
                cmds.append([p, '--version'])
        # Registry fallback via PowerShell
        cmds.append(['powershell', '-NoProfile', '-Command', "(Get-Item 'HKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\App Paths\\chrome.exe').GetValue('')"])
        cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKLM:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])
        cmds.append(['powershell', '-NoProfile', '-Command', "(Get-ItemProperty 'HKCU:\\Software\\Google\\Chrome\\BLBeacon' -ErrorAction SilentlyContinue).version"])

    elif system == 'darwin':
        mac_paths = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ]
        for p in mac_paths:
            if os.path.exists(p):
                cmds.append([p, '--version'])
        cmds.append(['mdls', '-name', 'kMDItemVersion', '/Applications/Google Chrome.app'])

    else:
        names = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
        for name in names:
            path = shutil.which(name)
            if path:
                cmds.append([path, '--version'])
        # Package manager fallbacks
        cmds.append(['bash', '-lc', "dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null"])
        cmds.append(['bash', '-lc', "rpm -q --qf '%{VERSION}-%{RELEASE}\n' google-chrome-stable 2>/dev/null"])

    return cmds


def get_version():
    seen = []
    for cmd in candidate_commands():
        out = run_cmd(cmd)
        if out:
            seen.append(out)
            ver = parse_version(out)
            if ver:
                return ver, out
    return None, '\n'.join(seen)


def main():
    ver, raw = get_version()
    if not ver:
        print('UNKNOWN: Google Chrome version not detected')
        sys.exit(2)

    # Windows/Mac may be 149.0.7827.54; Linux noted as 149.0.7827.53.
    # Treat any version >= 149.0.7827.53 as patched for this CVE.
    if cmp_ver(ver, TARGET) >= 0:
        print(f'PATCHED: detected Chrome version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}')
        sys.exit(0)
    else:
        print(f'VULNERABLE: detected Chrome version {ver[0]}.{ver[1]}.{ver[2]}.{ver[3]}')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a managed browser-version compliance problem, not a perimeter emergency. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for this MEDIUM verdict, but because Chrome updates are low-friction you should still push your managed fleet to 149.0.7827.53/54 or later in the next browser maintenance cycle, verify laggards with endpoint inventory, and reserve extra attention for privileged user groups; the formal noisgate remediation SLA is ≤365 days.

Sources

  1. Google Chrome stable desktop update 149
  2. Google Chrome for Android update 149
  3. Chromium issue 501668745
  4. Chromium Security page
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. FIRST EPSS documentation
  8. Vulnerability-Lookup entry for CVE-2026-11142
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.