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

Inappropriate implementation in Paint in Google Chrome prior to 149

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

This is a peephole drilled through Chrome’s privacy wall, not a front-door kick-in

CVE-2026-11139 is a Chrome client-side information disclosure issue in the Paint pipeline. A malicious site can reportedly abuse the flaw in Chrome versions prior to 149.0.7827.53 to leak *cross-origin* data via crafted web content, which means the prize is whatever the victim browser can already see or render from another origin during that session.

Google rated it MEDIUM at 6.5, and that is a little generous in enterprise terms. Same-origin-policy failures matter, but this one still requires user interaction, browser-side exploit reliability, and a victim who is simultaneously authenticated to something worth stealing; there is no evidence here of code execution, sandbox escape, KEV listing, or in-the-wild exploitation.

"Serious browser isolation break, but it still needs a user on a vulnerable Chrome build to bite."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the victim into a hostile page

The attacker needs the target to open a malicious site or attacker-controlled content in a vulnerable Chrome build. This is classic browser exploitation territory: phishing, malvertising, compromised third-party sites, or links dropped into chat and email are the realistic delivery channels.
Conditions required:
  • Victim is running Chrome earlier than 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced web content
  • JavaScript and normal web rendering are available
Where this breaks in practice:
  • Requires user interaction
  • Enterprise URL filtering, email security, Safe Browsing, and web isolation can kill a large slice of delivery attempts
  • Auto-update narrows the vulnerable population quickly for managed Chrome fleets
Detection/coverage: Detection is weak at the exploit semantic level. Web proxies, SWG, browser telemetry, and EDR may see suspicious navigation chains, but version-based exposure detection is the reliable control.
STEP 02

Abuse the Paint bug to cross an origin boundary

Once the page is loaded, attacker JavaScript attempts to trigger the Paint implementation flaw and coerce Chrome into exposing data that should stay isolated by origin rules. In practice this is a browser SOP/privacy boundary failure, not a memory-corruption-to-code-exec chain.
Conditions required:
  • The vulnerable rendering path in Paint is reachable from web content
  • The victim browser is concurrently handling sensitive cross-origin content or state
  • Exploit logic is compatible with the target platform/build
Where this breaks in practice:
  • Exploit reliability can be brittle across OS, GPU, and browser build variation
  • The attacker only gets value if relevant cross-origin data is actually present and reachable in-session
  • No public PoC located, which usually means more engineering cost for attackers
Detection/coverage: Network and EDR products generally do not understand browser-origin violations. Detection tends to be indirect: crash telemetry, anomalous browser child/network behavior, or retroactive hunting once a campaign is known.
STEP 03

Steal session-bound data

If the origin boundary is bypassed, the attacker can exfiltrate page content or other rendered cross-origin information back to their server. The likely impact is theft of sensitive web-session data from SaaS apps or internal portals the victim is already using, not host takeover.
Conditions required:
  • Victim is logged into a sensitive site
  • The leaked data is enough to expose content or tokens worth stealing
  • Outbound exfiltration from the browser is permitted
Where this breaks in practice:
  • Blast radius is usually tied to one user session, not the endpoint or domain
  • Modern SaaS defenses like re-auth, token binding, and conditional access reduce follow-on value
  • Leak scope may be partial or content-specific rather than universal account compromise
Detection/coverage: CASB/SSE telemetry may show odd browser access patterns after the fact, but most defenders will not see the exfil unless they already inspect browser-to-web traffic closely.
STEP 04

Turn browser data into account abuse

The final step is operationalizing whatever was stolen: screenshots, cross-origin page fragments, CSRF-protected data, or workflow details that aid phishing and account takeover. This is where enterprise impact becomes real, but only after the attacker clears several narrowing prerequisites.
Conditions required:
  • Leaked data is actionable
  • Targeted user has access to sensitive business apps
  • The attacker can reuse or monetize the exposed information
Where this breaks in practice:
  • This is post-click and session-dependent, which sharply limits scale compared with RCE browser bugs
  • MFA, device-bound sessions, and downstream detection can stop follow-on abuse
  • Many victims will yield low-value consumer browsing data rather than privileged enterprise data
Detection/coverage: Account monitoring, IdP risk alerts, and SaaS audit logs are more likely to catch the follow-on abuse than the browser bug itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found. Not present in CISA KEV as of the catalog pages reviewed.
Proof-of-concept availabilityNo public PoC located in primary or common secondary references reviewed. That does not make it safe, but it raises attacker effort versus bugs with copy-paste exploit code.
EPSS0.00035 (~0.035% next-30-day probability). The percentile was not directly verifiable from FIRST in this environment; based on comparable FIRST examples, this sits in the low tail, roughly low-teens percentile.
KEV statusNo. No KEV listing date or due date because the CVE is not cataloged by CISA.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote, no auth, but user interaction required and impact is confidentiality-only.
Affected versionsGoogle Chrome prior to 149.0.7827.53; the early-stable desktop release references 149.0.7827.53/.54 for Windows/macOS, with Linux at 149.0.7827.53.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux, and 149.0.7827.53/.54 or later on Windows/macOS. Chrome auto-update and enterprise channel management are the practical delivery path; distro-packaged Chromium may backport fixes under different package version strings.
Exposure realityInternet-wide scanners like Shodan/Censys are a poor fit because this is client browser exposure, not a server socket. The amplifier is product ubiquity: StatCounter showed Chrome at roughly 68% worldwide browser share across devices and over 73% desktop share in early 2026, so reachable victims are abundant even though direct scanner enumeration is not.
Disclosure date2026-06-04 from the user-supplied intel, consistent with the release timing around the Chrome 149 rollout.
Researcher / reportingSpecific reporting researcher was not identified in the sources reviewed. Also note: the user-supplied CWE-352 looks suspect for a cross-origin data leak; that CWE usually maps to CSRF rather than SOP/privacy-boundary failures.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.6/10)

The decisive downward pressure is that exploitation still depends on user interaction and a live victim browser session rather than exposed server software or host-level code execution. The upward pressure is Chrome's enormous installed base and the fact that same-origin boundary failures can expose real SaaS data from already-authenticated users.

HIGH Patch version and affected Chrome branch
MEDIUM Exploit-path assessment from sparse vendor detail
MEDIUM Severity downgrade versus vendor CVSS

Why this verdict

  • User click required: the attacker is unauthenticated and remote, but they still need the victim to load hostile content, which is a real friction point in enterprise fleets.
  • Confidentiality-only impact: the published vector is C:H / I:N / A:N; this is data exposure, not endpoint takeover, persistence, or domain blast radius.
  • Session-dependent value: the bug only matters if the victim is already browsing sensitive cross-origin content that the exploit can actually reach during that session.
  • No active exploitation signals: no KEV, no confirmed campaigns, and a very low EPSS score all push this below urgent browser-zero-day territory.
  • Huge product footprint keeps it out of LOW: Chrome's massive deployment means even medium-grade client bugs can produce real incident volume when a campaign appears.

Why not higher?

This is not an unauthenticated server-side bug, not a pre-auth appliance bug, and not a browser RCE or sandbox escape. The chain is narrower: lure victim, hit a specific browser build, rely on in-session cross-origin value, and then monetize stolen data without a guaranteed host compromise.

Why not lower?

Breaking browser origin isolation is still meaningful because enterprise users spend their day inside authenticated SaaS sessions. Chrome is everywhere, so once delivery works, the reachable victim population is large enough that defenders should not write this off as mere nuisance.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure managed browsers cannot sit below 149.0.7827.53 for long. For a MEDIUM verdict there is no mitigation SLA, so treat this as exposure reduction while you work the patch through normal browser operations and complete remediation within the 365-day window.
  2. Block unmanaged browsers from sensitive apps — Use IdP conditional access, device trust, or enterprise browser controls so high-value SaaS only accepts managed and compliant browser sessions. This reduces the payoff of browser-side data leaks while you patch; again, no mitigation SLA applies for MEDIUM, but it is worth doing where the business risk is high.
  3. Tighten web isolation for risky categories — Send newly registered domains, uncategorized sites, ads, and user-generated content through RBI/SWG isolation where available. That directly attacks step 1 of the chain by making hostile page delivery less likely to reach a vulnerable session before normal remediation is completed.
  4. Use least-privilege browser profiles — Separate admin workflows from general browsing and avoid keeping privileged sessions open in the same browser context users use for casual web activity. This does not fix the bug, but it reduces the data value available to a successful same-origin bypass.
What doesn't work
  • Endpoint AV alone — it may catch delivery infrastructure or follow-on malware, but it will not understand a browser-origin data leak happening inside normal renderer behavior.
  • Network perimeter scanning — this is a client-side browser flaw, so there is no exposed listening service for your scanner to find.
  • MFA by itself — MFA helps with follow-on account abuse, but it does not stop the initial cross-origin data exposure inside an already-authenticated browser session.
06 · Verification

Crowdsourced verification payload.

Run this on the endpoint itself or via your software inventory agent, because you need the locally installed Chrome version. Invoke it with python3 check_chrome_cve_2026_11139.py on macOS/Linux or py check_chrome_cve_2026_11139.py on Windows; standard user rights are usually enough, but admin may be needed if Chrome is installed in a nonstandard location.

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

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

FIXED = (149, 0, 7827, 53)


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def version_str(v):
    return '.'.join(str(x) for x in v)


def get_version_from_command(cmd):
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return parse_version(out.strip())
    except Exception:
        return None


def get_windows_version():
    candidates = [
        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'),
    ]
    ps = (
        "$paths = @('C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',"
        "'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',"
        "'$env:LOCALAPPDATA\\Google\\Chrome\\Application\\chrome.exe');"
        "$found = $paths | Where-Object { Test-Path $_ } | Select-Object -First 1;"
        "if ($found) { (Get-Item $found).VersionInfo.ProductVersion }"
    )
    v = get_version_from_command(["powershell", "-NoProfile", "-Command", ps])
    if v:
        return v
    for path in candidates:
        if os.path.exists(path):
            try:
                out = subprocess.check_output([
                    'powershell', '-NoProfile', '-Command',
                    f"(Get-Item '{path}').VersionInfo.ProductVersion"
                ], stderr=subprocess.STDOUT, text=True, timeout=10)
                v = parse_version(out)
                if v:
                    return v
            except Exception:
                pass
    return None


def get_macos_version():
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]
    for path in candidates:
        if os.path.exists(path):
            v = get_version_from_command([path, '--version'])
            if v:
                return v
    return None


def get_linux_version():
    commands = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium', '--version'],
        ['chromium-browser', '--version'],
    ]
    for cmd in commands:
        v = get_version_from_command(cmd)
        if v:
            return v
    paths = [
        '/opt/google/chrome/google-chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
    ]
    for path in paths:
        if os.path.exists(path):
            v = get_version_from_command([path, '--version'])
            if v:
                return v
    return None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        v = get_windows_version()
    elif 'darwin' in system:
        v = get_macos_version()
    elif 'linux' in system:
        v = get_linux_version()
    else:
        v = None

    if not v:
        print('UNKNOWN - Could not determine local Chrome/Chromium version')
        sys.exit(2)

    print(f'Detected version: {version_str(v)}')
    print(f'Fixed version threshold: {version_str(FIXED)}')

    if v < FIXED:
        print('VULNERABLE')
        sys.exit(1)
    else:
        print('PATCHED')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: confirm your managed Chrome fleet is not lagging below 149.0.7827.53, push the update through your standard browser ring, and use conditional access or browser isolation only where high-value apps justify the extra friction. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA; in practice, because browser updates are low-friction and broadly deployed, most enterprises should clear this in the next normal browser maintenance cycle rather than letting it age for quarters.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases blog homepage
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS API documentation
  5. FIRST EPSS data and fields
  6. Quanteta CVE tracker entry for CVE-2026-11139
  7. VulDB CVE index showing CVE-2026-11139
  8. StatCounter browser market share worldwide
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.