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

Inappropriate implementation in SVG in Google Chrome prior to 149

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

This is a peephole in a skyscraper, not a blown-open front door

CVE-2026-11180 is a Chrome desktop SVG implementation flaw that lets a remote attacker leak cross-origin data by getting a user to load a crafted HTML page. Affected builds are Chrome before 149.0.7827.53 on Linux and effectively before 149.0.7827.53/.54 on Windows and macOS, matching Google's June 2, 2026 stable release that fixed the issue.

Google calling this MEDIUM is basically right. The bug is internet-reachable through normal browsing and Chrome is everywhere, but the exploit chain still depends on user interaction, successful browser-side cross-origin abuse, and it only buys confidentiality impact rather than code execution or sandbox escape. No KEV listing, no confirmed in-the-wild exploitation, and a near-zero EPSS keep this out of HIGH.

"Wide reach, but this is still a click-to-trigger data leak, not a takeover bug."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Lure the target onto attacker HTML

The attacker needs the victim to render a malicious page in vulnerable Chrome. In practice this is a phishing link, ad-tech redirect, or compromised site hosting a custom HTML/JavaScript harness; there is no public weaponized framework tied to this CVE yet.
Conditions required:
  • Victim is using Chrome prior to 149.0.7827.53/.54
  • Victim loads attacker-controlled web content
  • JavaScript and SVG rendering are allowed
Where this breaks in practice:
  • Requires a real user to browse to attacker content
  • Enterprise URL filtering, browser isolation, and mail filtering cut delivery volume
  • Chrome's fast auto-update shrinks the vulnerable population quickly
Detection/coverage: Secure web gateways and browser telemetry can usually see the delivery event, but not reliably fingerprint this CVE specifically.
STEP 02

Trigger the SVG cross-origin read condition

The malicious page uses a crafted SVG path to reach cross-origin data that should stay isolated. The working exploit would be a custom browser exploit harness using attacker HTML + SVG primitives to coerce a same-browser cross-origin leak.
Conditions required:
  • The targeted cross-origin resource is reachable from the victim browser session
  • The underlying SVG bug is reachable in the victim's platform/browser build
  • Target data is present in a form the bug can expose
Where this breaks in practice:
  • Cross-origin leaks are usually brittle and context-dependent
  • Modern site isolation, CORB/ORB-style protections, cookie partitioning, and app-layer anti-framing behavior reduce what is actually exposed
  • The attacker needs a target site or resource worth stealing from the same browser context
Detection/coverage: Network IDS generally won't catch this; browser exploit telemetry, crash reporting, and abnormal DOM/SVG behavior are better bets, but coverage is uneven.
STEP 03

Harvest sensitive cross-origin content

If exploitation succeeds, the attacker can read data they should not have been able to read across origins. Think session-bound content, rendered secrets, or application data visible to the victim browser rather than OS-level compromise.
Conditions required:
  • Victim is authenticated to the target origin or has otherwise accessible sensitive data
  • The bug exposes usable data rather than noise
  • Attacker can parse and exfiltrate the returned content
Where this breaks in practice:
  • Impact is limited to confidentiality; no direct code execution or persistence
  • Blast radius is tied to what the victim browser can already access
  • Many enterprise sessions are further constrained by conditional access and short-lived tokens
Detection/coverage: DLP or proxy logging may catch the outbound exfiltration if it is obvious; most endpoint scanners will simply flag an outdated Chrome version, not active exploitation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found. I found no vendor statement of active abuse, no KEV entry, and no public campaign reporting tied to this CVE.
Proof-of-concept availabilityNo public PoC located. I found references to the Chrome advisory and the Chromium issue, but no public GitHub exploit repo or researcher release for this specific CVE.
EPSS0.00028 from the user-provided intel block; that is extremely low and consistent with a bug that is hard to operationalize at scale. Percentile was not confirmed from authoritative public data during this review.
KEV statusNot KEV-listed as of the review date. That matters because Chrome bugs that are actually getting burned in the wild often show up fast in vendor or CISA exploitation signals.
CVSS and what it really meansCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N says internet-reachable with no auth, but user interaction is mandatory and the payoff is data disclosure only. That is materially less dangerous operationally than a browser RCE with the same reach.
Affected versionsChrome prior to 149.0.7827.53 on Linux and the corresponding fixed June 2026 desktop stable release for Windows/macOS. In enterprise terms: any desktop endpoint still lagging behind the June 2, 2026 stable channel security update.
Fixed versionsGoogle shipped fixes in 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS via the June 2, 2026 desktop stable update.
Exposure footprintBroad endpoint population, poor external scanability. This is a client-side browser bug, so Shodan/Censys-style internet census data is not the right exposure lens; your real question is unmanaged or update-lagging desktop Chrome in the fleet.
Disclosure timingCVE publication landed 2026-06-04, while Google's stable desktop fix shipped 2026-06-02. That means there was already a patch path before public CVE metadata spread widely.
Reporter / originPublic advisory metadata points back to Google/Chrome CNA and a linked Chromium issue. I did not confirm an externally named researcher from the public sources available at review time.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.8/10)

The decisive factor is that exploitation requires a user to render attacker-controlled content in the browser and only yields cross-origin data exposure, not code execution. This is a real browser security boundary failure, but the combination of UI requirement, no exploitation evidence, and confidentiality-only impact keeps it in MEDIUM.

HIGH Patch floor and affected version range
MEDIUM Operational severity downgrade based on lack of exploit evidence and expected exploit brittleness
LOW Public exploit maturity, because the Chromium bug details are not fully public

Why this verdict

  • Start from vendor 6.5, then trim for UI friction: the attacker needs a victim to open attacker-controlled web content, which cuts mass exploitation compared with silent server-side or network-side bugs.
  • Confidentiality-only outcome: successful exploitation leaks cross-origin data but does not directly provide code execution, persistence, or integrity impact, so the blast radius is materially narrower than Chrome RCEs.
  • No live-fire indicators: no KEV listing, no confirmed in-the-wild exploitation, no public PoC, and a very low EPSS all argue against treating this like an urgent edge-exposed emergency.

Why not higher?

It is not HIGH because the chain is not unauthenticated-and-silent in the way defenders actually feel pain. A user has to browse to attacker content, the exploit likely depends on brittle browser state, and the end state is data leakage from the browser context rather than endpoint takeover.

Why not lower?

It is not LOW because Chrome is massively deployed and the entry condition is still just get the user to visit a page. Cross-origin data leakage can absolutely matter in SSO-heavy enterprises, especially where browsers hold active sessions to cloud apps and internal portals.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure managed desktop Chrome is pinned to the current stable channel and that update deferrals are not stretching past normal policy. For a MEDIUM verdict there is no mitigation SLA, so use this as a hygiene control while you work toward the remediation window.
  2. Route risky browsing through browser isolation — For high-risk users and unmanaged web destinations, force remote browser isolation or equivalent rendering separation. This reduces the chance that attacker HTML executes in the same local browser context that holds enterprise sessions; there is no mitigation SLA for MEDIUM, but it is still a high-value exposure reducer.
  3. Tighten outbound web filtering — Block newly registered domains, ad-tech detours, and suspicious HTML/SVG-heavy lures at the secure web gateway. That directly attacks step 1 of the chain by reducing how often users ever land on the attacker page.
  4. Prioritize privileged browsing profiles — Focus validation on admins, finance, HR, and developer endpoints first because browser-held sessions are where this bug gets its value. Even without a formal mitigation SLA, reducing privileged-session exposure pays off quickly.
What doesn't work
  • Traditional network vulnerability scanners won't tell you who is actively exploitable here; this is a client-side browser versioning problem, not a remotely banner-grabbable service flaw.
  • MFA does not stop the browser-side read itself; it may limit downstream account abuse, but it does not prevent cross-origin content from being exposed once the victim is already signed in.
  • Server-side WAF rules at your perimeter do little if the exploit page lives on a third-party or compromised external site and the vulnerable code path is inside the local browser.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory tooling. Invoke it with python3 check_chrome_cve_2026_11180.py on macOS/Linux or py check_chrome_cve_2026_11180.py on Windows; no admin rights are required, but local access to read installed application metadata is needed.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for CVE-2026-11180 exposure by installed Google Chrome 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

PATCH_VERSION = (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_version(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)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


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'),
    ]
    for exe in candidates:
        if exe and os.path.exists(exe):
            out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{exe}').VersionInfo.ProductVersion"])
            v = parse_version(out)
            if v:
                return exe, v
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return exe, v
    return None, 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 exe in candidates:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return exe, v
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        out = run_cmd(['/usr/bin/defaults', 'read', '/Applications/Google Chrome.app/Contents/Info', 'KSVersion'])
        v = parse_version(out)
        if v:
            return plist, v
    return None, None


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


def main():
    system = platform.system().lower()
    source, version = None, None

    if 'windows' in system:
        source, version = get_windows_version()
    elif 'darwin' in system:
        source, version = get_macos_version()
    elif 'linux' in system:
        source, version = get_linux_version()
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

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

    if cmp_version(version, PATCH_VERSION) < 0:
        print(f'VULNERABLE: detected version {".".join(map(str, version))} from {source}; requires >= 149.0.7827.53')
        sys.exit(1)
    else:
        print(f'PATCHED: detected version {".".join(map(str, version))} from {source}; meets >= 149.0.7827.53')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, pull your Chrome version inventory and confirm which endpoints missed the June 2, 2026 desktop stable update to 149.0.7827.53/.54. Because this reassessment lands at MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; use routine browser-hardening controls meanwhile, then complete version normalization within the noisgate remediation SLA of ≤365 days. In practice, because this is a browser bug with a broad endpoint footprint, most teams should close it far faster than the formal SLA even though it does not justify an emergency change window.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2026)
  2. Chrome 149 release notes
  3. FIRST EPSS overview
  4. FIRST EPSS API documentation
  5. CISA Known Exploited Vulnerabilities Catalog
  6. Canadian Centre for Cyber Security advisory for Chrome 149 update
  7. Chromium design doc - Blocking Cross-Site Documents / CORB context
  8. NVD entry
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.