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

Side-channel information leakage in Paint in Google Chrome prior to 149

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

This is peeking through a keyhole, not kicking down the door

CVE-2026-11289 is a client-side side-channel leak in Chrome's Paint path. It affects Google Chrome before 149.0.7827.53 and requires a victim to load attacker-controlled web content, after which the page can try to infer cross-origin data through timing or rendering side effects rather than directly reading protected content.

The published 6.5 MEDIUM CVSS overstates what matters to an enterprise patch queue. In practice this is *not* unauthenticated internet-facing server compromise, *not* code execution, and *not* a turnkey data theft bug; it is a browser-side confidentiality issue with user-interaction, exploit-development friction, no KEV listing, no public exploitation evidence, and a very low EPSS signal.

"A lure-dependent browser info leak with no exploitation evidence and weak real-world attacker ROI."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the victim on attacker-controlled content

The attacker needs a user to open a malicious or compromised webpage in vulnerable Chrome. The delivery mechanism is the usual browser playbook: phishing link, malvertising, poisoned search result, or a compromised legitimate site serving weaponized JavaScript.
Conditions required:
  • Victim uses Chrome older than 149.0.7827.53
  • Victim browses to attacker-controlled or attacker-influenced content
  • JavaScript and normal rendering behavior are available
Where this breaks in practice:
  • Requires *user interaction*; this is not a drive-by against your server estate
  • Enterprise web filtering, Safe Browsing, email security, and browser isolation cut delivery volume
  • Auto-update makes the vulnerable window short on well-managed fleets
Detection/coverage: Traditional vuln scanners will mostly see version state, not exploit attempts. Email/web telemetry and browser crash or unusual navigation logs are more useful than network signatures.
STEP 02

Trigger the Paint side-channel

Using crafted HTML/JS, the page exercises the browser's Paint behavior and measures indirect signals to infer cross-origin state or content characteristics. The weaponized tool here is simply in-browser JavaScript plus browser timing/rendering primitives rather than a standalone exploit kit.
Conditions required:
  • Browser remains on a vulnerable build
  • Attacker can induce measurable rendering differences
  • Target data is present in a context where cross-origin state leaks are meaningful
Where this breaks in practice:
  • Side-channels are notoriously noisy and brittle across hardware, tabs, extensions, throttling, and scheduler behavior
  • Site isolation and modern browser hardening reduce useful leakage paths
  • Practical exploitation usually needs careful tuning, repeatability, and target-specific assumptions
Detection/coverage: No strong signature-based coverage. Restricted Chromium bug details suggest public technical exploit specifics were not broadly released at disclosure time.
STEP 03

Extract useful cross-origin information

If the measurements are stable enough, the attacker can infer sensitive cross-origin facts such as page state, token presence, or other protected content characteristics. This is a confidentiality-only outcome; there is no direct integrity or availability impact and no sandbox escape or code execution path described for this CVE.
Conditions required:
  • Victim is simultaneously authenticated to a valuable target or has sensitive cross-origin context loaded
  • Leaked bits are actually actionable for the attacker
  • Attacker can correlate timing/render output into usable conclusions
Where this breaks in practice:
  • Most enterprises need *both* a vulnerable browser and a high-value authenticated browsing session to the right target
  • Leak quality may be too low for broad automation at scale
  • Even successful leakage often yields partial inference, not full session takeover
Detection/coverage: Hard to detect directly. Focus on browser version compliance and suspicious web-delivery telemetry rather than expecting exploit-prevention products to label this CVE by name.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence found. Not listed in CISA KEV, and Google did not flag this issue as exploited in the release notes.
Public PoC availabilityNo public PoC found in this review. The Chromium issue reference 502239897 appears to remain restricted, which is normal until patch uptake improves.
EPSS0.00028 from the user-supplied intel — effectively background-noise territory for prioritization. I did not independently verify the percentile in this session.
KEV statusNot KEV-listed as of 2026-06-05; no CISA remediation due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — the score is driven by *confidentiality impact in theory*, but it still requires a victim to browse to hostile content.
Affected versionsGoogle Chrome before 149.0.7827.53; the desktop stable advisory covers Windows, macOS, and Linux builds in the 149 stable train.
Fixed versionsPatch to 149.0.7827.53 or later. The desktop advisory lists Linux 149.0.7827.53 and Windows/Mac 149.0.7827.53/.54; Android inherits the corresponding desktop security fixes in 149.0.7827.59.
Scanning / exposure dataShodan/Censys/FOFA are basically irrelevant here. This is a client browser flaw, not an internet-exposed service; measure exposure through endpoint inventory and browser-version compliance, not external scanning.
Disclosure timelineReported by Google on 2026-04-13; fixed in the stable channel release published 2026-06-02, with public vulnerability disclosure surfacing by 2026-06-05.
Vendor severity contextChrome's own release notes classify this bug as Low severity, while the provided CVSS/CNA view is Medium 6.5. For patch operations, the Chrome-internal rating tracks reality better than the abstract CVSS number here.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

The decisive factor is that this is a *client-side, lure-dependent side-channel* with confidentiality-only impact and no evidence of exploitation. It narrows the reachable population to users who visit attacker-controlled content on lagging Chrome builds, which is a completely different risk class than a remotely reachable server bug with the same nominal CVSS mechanics.

HIGH Affected version and fixed build identification
MEDIUM Real-world exploitability downgrade from the published `6.5` score
MEDIUM Assessment that public offensive tooling is not broadly available

Why this verdict

  • Baseline starts at 6.5, then drops for delivery frictionUI:R means the attacker needs a human to browse to hostile content; that is materially weaker than a remotely reachable service flaw.
  • Drop again for attack surface reality — this is a browser client issue, not an internet-facing server you can mass-scan and hit on demand. Reachability depends on user behavior, browser lag, and the victim's browsing context.
  • Drop again for exploit-development friction — side-channel leaks in rendering paths are noisy and environment-sensitive. Real-world reliability is usually much worse than the clean CVSS model implies.
  • Drop again for threat intel — no KEV listing, no public exploitation signal found, and EPSS is extremely low (0.00028).
  • Do not over-credit confidentiality impact in a vacuum — the CVSS C:H reflects potential sensitivity of leaked data, but the attacker still needs a workable inference channel and a valuable authenticated target context.

Why not higher?

There is no code execution, no sandbox escape, no privilege escalation, and no indication of active exploitation. The attack requires a victim browser session, attacker-controlled web content, and enough signal quality to turn rendering side effects into useful data — that's real friction, not paperwork friction.

Why not lower?

It still breaks origin boundaries, and browsers sit on every employee workstation. Even a partial cross-origin leak can matter in high-value browsing contexts, so this is not paperwork-only noise and should still be cleaned up through normal browser hygiene.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure Chrome stable auto-update is enabled and relaunch enforcement is working across the fleet. For a LOW verdict there is no mitigation SLA; handle this as backlog hygiene and use normal endpoint compliance processes to drive all hosts to 149.0.7827.53+.
  2. Isolate risky browsing roles — For admins, finance, and users who routinely access sensitive SaaS, prefer browser isolation or hardened browsing profiles to reduce the value of any cross-origin leak. Again, for LOW, do this through normal hardening cadence rather than emergency change windows.
  3. Hunt for version laggards — Query endpoint management and EDR inventory for Chrome versions below 149.0.7827.53 and chase systems with disabled auto-update, stale VDI images, or relaunch debt. There is no mitigation SLA at this severity, but stale browser pockets are where low-grade bugs become operationally relevant.
What doesn't work
  • Perimeter vuln scanning doesn't tell you much here because the vulnerable component is a user browser, not a remotely fingerprintable service.
  • WAF rules are the wrong control plane; this flaw lives in the client render path and is triggered by browsing content, not by inbound traffic to your servers.
  • Password resets don't remediate the browser weakness and only help if you already know a specific session or token was exposed.
06 · Verification

Crowdsourced verification payload.

Run this on the endpoint itself or through your fleet-management execution framework. Invoke with python3 check_chrome_cve_2026_11289.py on macOS/Linux or py check_chrome_cve_2026_11289.py on Windows; no admin rights are required if standard install paths are readable.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11289.py
# Detects whether local Google Chrome is vulnerable to CVE-2026-11289
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

THRESHOLD = (149, 0, 7827, 53)


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()
    except Exception:
        pass
    return None


def windows_paths():
    candidates = []
    for base in [os.environ.get('ProgramFiles'), os.environ.get('ProgramFiles(x86)'), os.environ.get('LocalAppData')]:
        if not base:
            continue
        candidates.append(os.path.join(base, 'Google', 'Chrome', 'Application', 'chrome.exe'))
    return candidates


def mac_paths():
    return [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
    ]


def linux_paths():
    paths = []
    for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
        p = which(name)
        if p:
            paths.append(p)
    paths.extend([
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/opt/google/chrome/chrome',
        '/snap/bin/chromium',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
    ])
    # dedupe while preserving order
    seen = set()
    out = []
    for p in paths:
        if p not in seen:
            seen.add(p)
            out.append(p)
    return out


def detect_version():
    system = platform.system().lower()
    candidates = []

    if 'windows' in system:
        candidates = windows_paths()
    elif 'darwin' in system:
        candidates = mac_paths()
    else:
        candidates = linux_paths()

    for path in candidates:
        if os.path.exists(path):
            out = run_cmd([path, '--version'])
            ver = parse_version(out)
            if ver:
                return path, ver, out

    # Fallback for Windows registry via PowerShell if binary path was not found
    if 'windows' in system:
        ps = which('powershell') or which('pwsh')
        if ps:
            script = r"""
$paths = @(
 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe',
 'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe'
)
foreach ($p in $paths) {
  try {
    $item = Get-ItemProperty -Path $p -ErrorAction Stop
    if ($item.'(default)') { Write-Output $item.'(default)'; break }
  } catch {}
}
"""
            chrome_path = run_cmd([ps, '-NoProfile', '-Command', script])
            if chrome_path and os.path.exists(chrome_path.strip()):
                out = run_cmd([chrome_path.strip(), '--version'])
                ver = parse_version(out)
                if ver:
                    return chrome_path.strip(), ver, out

    return None, None, None


def main():
    path, ver, raw = detect_version()
    if not ver:
        print('UNKNOWN')
        sys.exit(2)

    if cmp_ver(ver, THRESHOLD) < 0:
        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: do not burn an emergency patch window on this one unless your browser estate is badly unmanaged. For a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA; treat it as backlog hygiene, let Chrome auto-update carry most of the load, and use your next software-compliance sweep to eliminate any endpoints still below 149.0.7827.53, with extra attention to privileged browsing populations and stale VDI/golden images.

Sources

  1. Chrome Stable Channel Update for Desktop (149.0.7827.53/.54)
  2. Chromium issue tracker reference 502239897
  3. Chromium severity guidelines
  4. Chromium Security page
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS overview
  7. FIRST EPSS API documentation
  8. GovCERT.HK alert for Chrome 149 vulnerabilities
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.