← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11182 · 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 the browser's apartment wall, not a master key to the whole building

CVE-2026-11182 is an information-disclosure flaw in Chrome's SVG handling that can let a malicious webpage read data that should stay isolated by the browser's same-origin boundary. Based on the vendor intel and reviewed release material, affected builds are Chrome versions before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS; *inference:* the reviewed sources do not show an Extended Stable backport yet, so managed 148.x fleets should be treated as potentially exposed until Google explicitly says otherwise.

Google's MEDIUM 6.5 label is about right in the real world. The exposure population is enormous because Chrome is everywhere and the attacker only needs a victim to render a crafted page, but the payload is still *confidentiality-only*, there is no known KEV entry or public exploitation evidence, and the likely blast radius is a user's browser session rather than host takeover.

"This is a browser same-origin crack, not a fleet-wide breaker: patch it routinely, not like a zero-day fire."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a malicious HTML/SVG page

The attacker uses a phishing link, malvertising, or a compromised site to get the victim to render attacker-controlled HTML that embeds the hostile SVG content. There is no authentication prerequisite and no need for prior host compromise; this is classic browser drive-by delivery.
Conditions required:
  • Unauthenticated remote attacker can get a user to open or render a webpage
  • Victim is using a vulnerable Chrome build
  • Browser can reach the attacker-controlled site
Where this breaks in practice:
  • Email security, DNS filtering, SWG, and browser reputation services block a meaningful chunk of first-contact URLs
  • User interaction is still required
  • Enterprise browser isolation deployments can kill the attack before local rendering
Detection/coverage: Network controls may catch the lure URL, but vulnerability scanners will mostly detect this via browser version inventory rather than content signatures.
STEP 02

Trigger the vulnerable SVG code path

The page must execute the exact SVG rendering path that mishandles origin boundaries and exposes protected data. In practice that means the exploit has to survive browser-version differences, page timing, and any mitigations Google ships in later builds.
Conditions required:
  • Attacker can serve crafted SVG/HTML content tailored to the vulnerable build
  • Victim browser allows the page to render the relevant SVG path
Where this breaks in practice:
  • No public proof-of-concept was found in the reviewed sources
  • Chrome often restricts bug details until most users are updated, which slows opportunistic weaponization
  • Minor build drift matters in browser exploitation
Detection/coverage: There is usually no stable IDS signature here; watch for crashes, renderer anomalies, and exploit-chain follow-on behavior, but version-based exposure tracking is the primary control.
STEP 03

Read cross-origin data from the victim session

If the bug is successfully hit, the page can pierce same-origin isolation and disclose data associated with other origins the victim can access. That can include tokens, page content, or other session-linked material, but it does not by itself imply code execution, sandbox escape, or persistence on the endpoint.
Conditions required:
  • Victim is logged into or has browser-accessible state for another origin worth stealing
  • The specific data the attacker wants is exposed by the flawed path
Where this breaks in practice:
  • The prize is only as valuable as the victim's active browser state
  • Modern web app hardening like SameSite cookies, CSP, token scoping, and short session lifetimes can limit payoff
  • Some targets require victim-specific workflow timing
Detection/coverage: Hard to detect directly. Look for unusual browser-to-browser-origin access patterns in web telemetry and downstream suspicious account activity.
STEP 04

Exfiltrate via normal web requests

Once data is read in the page context, the attacker can send it out through ordinary HTTPS requests, image beacons, or fetch/XHR. This keeps the attack low-noise and blends into standard browser traffic unless you have strong outbound inspection or browser telemetry.
Conditions required:
  • Attacker can receive outbound web traffic from the victim browser
  • Stolen data is small enough to exfiltrate through normal browser requests
Where this breaks in practice:
  • SWG, DLP, CASB, or browser isolation can reduce exfil paths
  • Enterprise egress controls may block newly registered or low-reputation domains
Detection/coverage: Detection is mostly behavioral: suspicious beaconing to fresh domains, odd POSTs from browser processes, and anomalous account usage after page visits.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in the reviewed vendor and CISA material as of 2026-06-05; the CVE is not in CISA KEV.
Proof-of-concept availabilityNo public PoC located. Chrome release notes routinely state bug details may remain restricted until most users are patched, which is a real brake on immediate copycat weaponization.
EPSS0.00028 from the user-provided intel. That is extremely low; *percentile was not available in the reviewed source set*.
KEV statusNot KEV-listed. No CISA due date, no federal emergency signal, no evidence of observed exploitation.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — internet-reachable and easy to deliver, but still user-interaction dependent and confidentiality-only.
Affected versionsPer the provided vendor intel, Chrome before 149.0.7827.53 is affected. For desktop rollout nuance, Google published 149.0.7827.53/.54 first as an early stable release to a small percentage of Windows/macOS users.
Fixed versionsReviewed sources show fixes at Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54. *Inference:* no explicit Extended Stable backport for this CVE was visible in the reviewed sources, so do not assume 148.x is safe.
Scanning / exposure realityThis is not an internet-scannable server bug. Shodan/Censys-style exposure counts are basically the wrong lens; the real exposure is your installed browser population and how many users can be lured to hostile content.
Disclosure date2026-06-04 from the supplied intel block.
Reporter / researcherNot publicly attributed in the reviewed release material for this specific CVE. That is common for Chrome issues while details remain partially restricted.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (6.1/10)

The decisive factor is that this is a drive-by, confidentiality-only browser bug with no evidence of active exploitation. Chrome's install base keeps it relevant, but the lack of code execution, lack of KEV status, and dependence on a victim rendering a malicious page keep it out of the high-priority emergency lane.

HIGH Version range and patched build assessment
MEDIUM Real-world exploitability without public technical details
HIGH No-KEV / no-public-exploitation assessment as of 2026-06-05

Why this verdict

  • Wide reach, limited outcome: attacker position is unauthenticated remote and the reachable population is huge because Chrome is everywhere, so the vendor baseline is not crazy.
  • User interaction is real downward pressure: the chain still requires the victim to render attacker content, which means email security, DNS/SWG, and browser isolation can stop the first step in many enterprises.
  • Confidentiality-only impact keeps it out of HIGH: this is a same-origin boundary failure, not host compromise, not sandbox escape, and not a persistence foothold.
  • No exploitation pressure: no KEV listing, no public zero-day statement, no public PoC found, and EPSS is extremely low, so there is no evidence-based reason to upgrade severity.
  • Population narrowing at step 3 matters: the attacker only wins valuable data when the victim also has useful cross-origin session state in that browser, which cuts down practical payoff versus the raw CVSS story.

Why not higher?

If this had active exploitation, a clean public PoC, or it chained directly to code execution or sandbox escape, the score would jump. But on the evidence available, this is still a browser data-leak issue that needs a victim session and a lure, not a fast-moving enterprise-breach primitive.

Why not lower?

I am not pushing this down to LOW because browser bugs ride on the most exposed attack surface you own: users opening web content all day. Even without code execution, a same-origin bypass can still steal tokens or sensitive app data from high-value users, so it deserves routine patch-cycle attention rather than backlog neglect.

05 · Compensating Control

What to do — in priority order.

  1. Force auto-update compliance — Verify Chrome is actually honoring your managed update channel and target version policy. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browser fleets should not drift; use this now to collapse exposure before stragglers accumulate.
  2. Harden web egress and click controls — Keep phishing protection, DNS filtering, SWG reputation blocking, and safe browsing controls tight because they interrupt the only mandatory first step: getting a user to render the hostile page. There is no mitigation SLA for MEDIUM here, so treat this as standing control hygiene while you roll the patch.
  3. Use browser isolation for risky user groups — Remote/browser isolation is one of the few controls that directly shrinks exploitability for client-side rendering bugs by moving page execution away from the endpoint. Prioritize execs, finance, admins, and internet-heavy users while you complete remediation in the normal window.
  4. Reduce session-value in the browser — Shorter session lifetimes, stronger token scoping, SameSite cookies, and re-authentication for sensitive actions reduce what a cross-origin leak can actually buy an attacker. This does not replace patching, but it caps blast radius for this class of browser confidentiality flaw.
What doesn't work
  • A WAF on your own apps does not fix a client-side browser parsing flaw; the malicious page can live anywhere on the internet.
  • Perimeter vulnerability scanning is the wrong tool because this is not a listening service; the exposure is endpoint version sprawl, not open ports.
  • MFA alone helps with account takeover after theft, but it does not stop cross-origin data disclosure inside an already authenticated browser session.
  • Extension allowlisting alone is not a fix because the reported path is a crafted webpage/SVG render issue, not primarily a rogue-extension problem.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent. Invoke it with python3 chrome_cve_2026_11182_check.py on macOS/Linux or py chrome_cve_2026_11182_check.py on Windows; no admin rights are usually required, but Windows registry reads and some install paths may work more reliably in an elevated shell.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11182 Chrome version check
# Output: 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)
WIN_MAC_THRESHOLD = (149, 0, 7827, 53)  # .54 is also patched; .53 and above are acceptable


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 ver_to_str(v):
    return '.'.join(str(x) for x in v)


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_versions_windows():
    found = []
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]

    for exe in candidates:
        if os.path.exists(exe):
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                found.append((exe, v))

    reg_paths = [
        r'HKLM\Software\Google\Chrome\BLBeacon',
        r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\Software\Google\Chrome\BLBeacon',
    ]
    for key in reg_paths:
        out = run_cmd(['reg', 'query', key, '/v', 'version'])
        v = parse_version(out)
        if v:
            found.append((key, v))

    return dedupe(found)


def get_versions_macos():
    found = []
    candidates = [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        os.path.expanduser('~/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:
                found.append((exe, v))
    return dedupe(found)


def get_versions_linux():
    found = []
    commands = ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']
    for cmd in commands:
        path = which(cmd)
        if path:
            out = run_cmd([path, '--version'])
            v = parse_version(out)
            if v:
                found.append((path, v))
    return dedupe(found)


def dedupe(items):
    seen = set()
    out = []
    for src, ver in items:
        key = (src, ver)
        if key not in seen:
            seen.add(key)
            out.append((src, ver))
    return out


def is_patched(ver):
    return ver >= THRESHOLD


def main():
    system = platform.system().lower()
    if 'windows' in system:
        found = get_versions_windows()
    elif 'darwin' in system:
        found = get_versions_macos()
    else:
        found = get_versions_linux()

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

    vulnerable = []
    patched = []
    unknown = []

    for src, ver in found:
        if is_patched(ver):
            patched.append((src, ver))
        else:
            vulnerable.append((src, ver))

    if vulnerable:
        print('VULNERABLE')
        for src, ver in vulnerable:
            print(f'  source={src} version={ver_to_str(ver)} threshold={ver_to_str(THRESHOLD)}')
        if patched:
            for src, ver in patched:
                print(f'  patched_install={src} version={ver_to_str(ver)}')
        sys.exit(1)

    if patched:
        print('PATCHED')
        for src, ver in patched:
            print(f'  source={src} version={ver_to_str(ver)} threshold={ver_to_str(THRESHOLD)}')
        sys.exit(0)

    print('UNKNOWN: unable to determine vulnerability state')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a routine-but-real browser patch: identify Chrome 148.x and early 149.x holdouts, make sure your managed update channel is actually advancing them, and use click-protection/browser-isolation controls for high-risk users while rollout finishes. Because this reassessment is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice you should still fold it into your next normal endpoint/browser wave, and complete the actual vendor update well inside the noisgate remediation SLA of ≤365 days rather than burning emergency change capital on it.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome for Testing availability - stable 149.0.7827.53
  3. Chrome Enterprise - browser release channels
  4. Chrome Enterprise - manage Chrome updates
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS data and statistics
  7. FIRST EPSS API documentation
  8. Google Chrome stable release note showing restricted bug-detail practice
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.