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

Inappropriate implementation in DataTransfer 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 privacy wall, not a front door kicked off its hinges

CVE-2026-11161 is a Chrome client-side information disclosure bug in DataTransfer handling. Affected builds are Chrome versions earlier than 149.0.7827.53 on Linux and earlier than 149.0.7827.53/.54 on Windows and macOS, with the practical fixed floor for enterprises being 149.0.7827.53 or later. The stated impact is cross-origin data leakage through a crafted HTML page, which means the attacker is abusing browser trust boundaries to read data they should not get, not executing code on the endpoint.

Google's MEDIUM 4.3 label is basically fair in the real world. The bug is remotely reachable through web content and Chrome is everywhere, but the chain still needs a user to hit attacker-controlled content, the impact is confidentiality-only and rated low, and there is no evidence in the sources reviewed of KEV listing, public exploitation, or a commodity exploit kit path. For a 10,000-host fleet, this belongs in your normal browser update machinery, not in your emergency patch lane.

"Keep it in the browser patch train, not the incident bridge."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Host a crafted lure page

The attacker builds a malicious HTML/JavaScript page that exercises the vulnerable DataTransfer behavior. The likely weaponized component is plain browser-native JavaScript rather than a named framework, because the bug lives in web platform handling and does not require a local helper. No public PoC repo was identified in the reviewed sources.
Conditions required:
  • Victim uses Chrome prior to 149.0.7827.53
  • Attacker can get the victim to load attacker-controlled web content
Where this breaks in practice:
  • No confirmed public PoC lowers opportunistic abuse
  • Email gateways, web filters, Safe Browsing, and user behavior all reduce lure success
Detection/coverage: Traditional vuln scanners do not directly prove exploitability here; they mostly detect vulnerable Chrome versioning.
STEP 02

Trigger the browser boundary mistake

Once rendered, the page invokes the relevant browser interaction path to coerce DataTransfer into exposing cross-origin data. The exact primitive is not public in the reviewed sources, but the effect described by the CVE is a same-origin boundary failure leading to unauthorized data disclosure.
Conditions required:
  • The vulnerable browser code path is reachable from page content
  • The victim performs whatever interaction the page requires, consistent with UI:R
Where this breaks in practice:
  • User interaction is explicitly required by the supplied CVSS vector
  • Browser mitigations and changing implementation details often make client-side bug repro brittle across minor builds
Detection/coverage: Network telemetry may only show a user visiting a web page; EDR generally will not surface a browser-internal policy failure unless it leads to a downstream artifact.
STEP 03

Collect leaked cross-origin data

If the primitive works, the attacker exfiltrates the leaked material using standard browser egress methods such as fetch, sendBeacon, or an image request. In practice this is valuable only if the leaked data contains session-bound or application-sensitive content.
Conditions required:
  • Interesting data is present in the browser context at the time of exploitation
  • Outbound browser traffic to the attacker is allowed
Where this breaks in practice:
  • Impact is limited to whatever data the primitive can actually expose
  • No integrity or availability impact means no direct host takeover from this CVE alone
Detection/coverage: Proxy, CASB, or DNS logs may catch exfil domains, but they will not attribute the behavior specifically to CVE-2026-11161.
STEP 04

Use the stolen data for follow-on access

The practical follow-on is session abuse, data theft, or targeted account misuse against web apps the victim is already using. That matters, but it is a second-stage outcome dependent on what was leaked, not a guaranteed endpoint compromise.
Conditions required:
  • Leaked data includes reusable tokens, sensitive app data, or internal content
  • Target applications do not independently block replay or anomalous session use
Where this breaks in practice:
  • Modern SaaS controls, conditional access, short-lived tokens, and step-up auth can limit reuse
  • Blast radius is per-user session context, not a wormable infrastructure event
Detection/coverage: Identity telemetry and SaaS audit logs are more useful than host telemetry for spotting downstream abuse.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence found of active exploitation in the reviewed sources as of 2026-06-06.
KEV statusNot listed in CISA KEV in the reviewed catalog source; no federal due date applies. Source: CISA KEV catalog
Proof-of-concept availabilityNo public PoC, Metasploit module, or Exploit-DB entry was identified in the reviewed sources. That lowers copy-paste attacker adoption.
EPSSSupplied intel says 0.00012. That is extremely low predicted 30-day exploitation probability; percentile was not confirmed from an authoritative query in the reviewed sources. EPSS reference: FIRST EPSS API docs
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N — remote content can trigger it, but only with user interaction, and the rated impact is confidentiality-low only.
Affected versionsChrome prior to 149.0.7827.53 is affected. Google early stable shipped 149.0.7827.53/.54 for Windows and Mac, and public advisories reference Linux fixed at 149.0.7827.53. Sources: Chrome Releases early stable, Canadian Centre advisory
Fixed versionsPatch to 149.0.7827.53 or later. On Windows/macOS, Google early stable references 149.0.7827.53/.54; on Linux advisories call out 149.0.7827.53.
Scanning and exposure realityThis is not internet-scannable like a server CVE. GreyNoise, Shodan, Censys, and FOFA are poor fit because the vulnerable asset is the user browser, not a listening service. Your real exposure population is every managed endpoint still pinned below 149.0.7827.53.
Disclosure datePublished/disclosed on 2026-06-04 per supplied intel; Chrome-related June 2026 advisory activity is corroborated by Vulnerability-Lookup Chrome entries.
Reporting / source pedigreeChrome-issued CVEs in this batch are assigned by Chrome / [email protected] in aggregated vulnerability records. Public bug details may remain restricted until broad patch adoption.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.0/10)

The single biggest downward pressure is that this is a user-driven client-side info leak, not a server-side pre-auth takeover. Chrome's ubiquity keeps it from dropping into backlog junk, but the absence of exploitation evidence and the low-impact confidentiality-only outcome keep it out of the urgent lane.

HIGH Version-based exposure and fixed build floor
MEDIUM Enterprise exploitability assessment without public bug mechanics
HIGH No evidence of KEV listing in reviewed sources

Why this verdict

  • Started from the vendor's 4.3 MEDIUM baseline because the stated impact is cross-origin data disclosure, not code execution or sandbox escape.
  • User interaction is mandatory: the supplied vector is UI:R, which means the attacker still needs delivery plus victim engagement with attacker-controlled content. That materially narrows reliable exploitation in enterprise fleets.
  • This is post-browse, not infrastructure-reachable: there is no exposed daemon, service port, or server workload to scan and mass-weaponize. The attacker only gets a shot when a vulnerable user browser hits their content.
  • No active exploitation signal: no KEV listing, no public exploitation evidence, and a supplied EPSS of 0.00012 all argue against emergency reprioritization upward.
  • Blast radius is per-user session context: even if exploited, the expected outcome is data leakage from browser context, not direct host takeover across the fleet.

Why not higher?

There is no evidence in the reviewed sources of active exploitation, no public PoC surfaced, and the impact is not RCE or sandbox escape. The prerequisite chain compounds downward pressure: remote delivery still depends on user interaction and useful data being present in the browser at the time.

Why not lower?

Chrome is one of the most exposed client applications in any enterprise, so even a confidentiality-only browser boundary bug deserves attention. Same-origin and cross-origin leaks can become real account and data exposure when they intersect with live SaaS sessions, internal portals, or privileged admin browsing.

05 · Compensating Control

What to do — in priority order.

  1. Verify Chrome auto-update health — Check for version pinning, disabled updates, stale relaunch debt, and broken update rings. For a MEDIUM verdict there is no mitigation SLA; use this as normal hygiene while you drive to the patch under the 365-day remediation window.
  2. Prioritize risky user groups — Move admins, finance, help desk, and users with broad SaaS access to the patched build first because browser-session exposure is where this bug pays off for attackers. Again, there is no mitigation SLA for MEDIUM, so do this as part of normal rollout acceleration rather than emergency change control.
  3. Tighten web egress and filtering — Keep Safe Browsing, secure web gateway policies, DNS filtering, and attachment detonation tuned to reduce the odds that users ever reach malicious lure pages. This lowers exploit reach while patch adoption completes within the remediation window.
  4. Watch identity and SaaS logs — Because the likely business impact is downstream session or data abuse, monitor impossible travel, token anomalies, new device enrollments, and sensitive data exports from key apps. This is more useful than waiting for endpoint security to name the CVE.
What doesn't work
  • A WAF does not meaningfully help because the vulnerable component is the client browser, not your server-side application path.
  • Network vulnerability scanning will not tell you whether the browser-side exploit path is reachable; at best it inventories version state on endpoints.
  • EDR alone is a weak primary control here because browser-internal policy failures often leave little or no host-level malicious artifact.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent. Invoke it as python3 check_chrome_cve_2026_11161.py on macOS/Linux or py check_chrome_cve_2026_11161.py on Windows; no admin rights are required if Chrome is installed in standard locations. The script checks common Chrome paths and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11161.py
# Determine whether installed Google Chrome is below 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from typing import Optional, Tuple

FIXED = (149, 0, 7827, 53)


def parse_version(text: str) -> Optional[Tuple[int, ...]]:
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return p.returncode, out.strip()
    except Exception:
        return 999, ''


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

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', r'C:\Users\Default\AppData\Local')
        pf = os.environ.get('PROGRAMFILES', r'C:\Program Files')
        pfx86 = os.environ.get('PROGRAMFILES(X86)', r'C:\Program Files (x86)')
        candidates = [
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pfx86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        for c in candidates:
            cmds.append([c, '--version'])
        cmds.append(['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'])
        cmds.append(['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'])

    elif system == 'darwin':
        candidates = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ]
        for c in candidates:
            cmds.append([c, '--version'])
        which = shutil.which('google-chrome')
        if which:
            cmds.append([which, '--version'])

    else:
        bins = [
            'google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser'
        ]
        for b in bins:
            which = shutil.which(b)
            if which:
                cmds.append([which, '--version'])
        candidates = [
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
        ]
        for c in candidates:
            cmds.append([c, '--version'])

    return cmds


def find_version() -> Optional[Tuple[int, ...]]:
    seen = set()
    for cmd in candidate_commands():
        key = tuple(cmd)
        if key in seen:
            continue
        seen.add(key)
        rc, out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            return ver
    return None


def cmp_ver(a, b):
    # Normalize length if needed
    maxlen = max(len(a), len(b))
    aa = a + (0,) * (maxlen - len(a))
    bb = b + (0,) * (maxlen - len(b))
    if aa < bb:
        return -1
    if aa > bb:
        return 1
    return 0


def main():
    ver = find_version()
    if not ver:
        print('UNKNOWN: Google Chrome version not found in standard locations')
        sys.exit(2)

    ver_str = '.'.join(str(x) for x in ver)
    fixed_str = '.'.join(str(x) for x in FIXED)

    if cmp_ver(ver, FIXED) < 0:
        print(f'VULNERABLE: installed Chrome version {ver_str} is older than fixed {fixed_str}')
        sys.exit(1)
    else:
        print(f'PATCHED: installed Chrome version {ver_str} is at or above fixed {fixed_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a browser fleet hygiene issue: verify Chrome auto-update is actually working, remove version pins, and push 149.0.7827.53+ through your normal endpoint rings with extra focus on privileged and high-risk users. This is a MEDIUM call, so there is no noisgate mitigation SLA — go straight to the 365-day remediation window; still, because Chrome is ubiquitous and updates are operationally cheap, you should finish broad rollout well before the noisgate remediation SLA ceiling rather than letting old pinned browsers linger all year.

Sources

  1. Chrome Releases: Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases homepage
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. Vulnerability-Lookup Chrome June 2026 entries
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. Chrome Enterprise auto-update policies
  8. Chrome Enterprise update management guidance
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.