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

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

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

This is a peephole in the browser wall, not a kicked-in front door

CVE-2026-11153 is a side-channel information leak in Chrome Forms handling that affects Google Chrome versions earlier than 149.0.7827.53. A malicious page can abuse browser behavior to infer cross-origin data that should stay behind same-origin boundaries. The affected range is broad in the usual browser sense—any desktop Chrome build below the fixed release—with corresponding Android security fixes shipped in Chrome 149.0.7827.59.

The vendor-supplied 9.1/CRITICAL framing overstates the operational risk for enterprise patch triage. This is still a browser bug and Chrome is everywhere, but the real-world path is *user-driven web content to data leakage*, not *unauthenticated server-side compromise* and not *remote code execution on the endpoint*. Google’s own CNA text embeds Chromium security severity: Medium, which fits reality much better than the CVSS label.

"Internet-reachable, yes; internet-wormable, no. This is a browser SOP leak, not a host takeover."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker-controlled web content

The attacker needs the target browser to render a crafted HTML page, likely delivered through phishing, malvertising, a compromised site, or an embedded third-party ad slot. The weaponized tooling here is just custom HTML/JavaScript; no public exploit kit or Metasploit module was found in the sources reviewed.
Conditions required:
  • Victim runs Chrome below 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced web content
  • Browser-side script execution is allowed
Where this breaks in practice:
  • This is not a passive internet scan problem; the attacker needs browser execution on a real user session
  • Secure web gateways, ad filtering, and phishing-resistant browsing workflows reduce reachable population
  • Many enterprise Chrome fleets auto-update quickly, shrinking the vulnerable window
Detection/coverage: Traditional network scanners will miss this entirely; coverage comes from software inventory, browser version telemetry, EDR live response, and managed browser admin consoles.
STEP 02

Abuse Forms side-channel behavior to probe cross-origin state

Once running in the browser, the page abuses the Forms flaw to measure observable differences and infer cross-origin data that should be protected by the browser isolation model. The reference path is Chromium issue 501779840, but the ticket is restricted, so exact primitives are not publicly documented.
Conditions required:
  • The vulnerable browser behavior must still be present
  • The target cross-origin application must expose measurable behavior differences
  • Browser mitigations must not fully suppress the side channel
Where this breaks in practice:
  • Side-channel leaks are usually narrower and noisier than direct DOM read access
  • Practical exploitation often depends on the victim also being logged into a target site of interest
  • Data obtained may be inferential rather than raw, increasing attacker effort
Detection/coverage: No reliable signature-based network detection is expected. Browser exploit prevention, suspicious script telemetry, and sandboxed/isolated browsing for high-risk users are more realistic controls.
STEP 03

Extract useful cross-origin information

The attacker converts measurements into account state, token-adjacent secrets, or other sensitive application data. The likely tooling remains bespoke JavaScript running in-page, not a commodity framework.
Conditions required:
  • Victim is authenticated to a valuable cross-origin target
  • The target data can be inferred with enough precision to matter
  • The attacker can exfiltrate the inferred results
Where this breaks in practice:
  • Not every target site will expose a useful signal
  • Leak impact is bounded by what the side channel can actually reveal
  • This is materially less reliable than a clean same-origin bypass or renderer RCE
Detection/coverage: DLP and egress analytics may catch large or repeated exfiltration, but one-off browser-side leakage is hard to see directly.
STEP 04

Operationalize the stolen browser-session data

If the leak yields actionable information, the attacker can pivot into account abuse, targeted phishing, or session-specific follow-on attacks. This is where business impact appears, but it is downstream of several prerequisites that sharply narrow the effective threat population.
Conditions required:
  • Leaked data is high-value enough to use
  • The attacker has a follow-on path against the affected web application or user
Where this breaks in practice:
  • The bug does not itself deliver code execution or persistence on the endpoint
  • Blast radius is usually limited to the victim browser session and whatever sites the user is signed into
Detection/coverage: Downstream account telemetry—impossible travel, anomalous session use, suspicious transactions—may reveal abuse after the browser leak succeeds.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo active exploitation evidence in the reviewed sources. CISA ADP metadata for this CVE says Exploitation: none.
Public PoC statusNo public PoC or exploit repo found. The linked Chromium issue 501779840 is restricted, which also limits defender visibility into exact exploit mechanics.
EPSSUser-supplied EPSS is 0.00035 (0.035%), which is *very low* and consistent with low observed exploitation pressure. Percentile was not available in the supplied intel.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
CVSS vector reality checkCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N treats this like a no-interaction network bug. In practice, this is *browser content-driven* and effectively depends on a victim rendering attacker HTML, which makes the UI:N posture too generous.
Affected versionsChrome before 149.0.7827.53 is affected per the CNA record. The flaw is described as being in Forms and enabling cross-origin data leakage from a crafted HTML page.
Fixed versionsDesktop stable shipped fixes in Chrome 149.0.7827.53/54 for Windows/Mac and 149.0.7827.53 for Linux. Android 149.0.7827.59 carries the same corresponding security fixes.
Vendor severity mismatchYour intel says CRITICAL 9.1, but the Chrome CNA description itself appends Chromium security severity: Medium. For patch triage, that internal Chrome assessment is the more credible operational signal.
Exposure / scanning realityThis is *not* a server exposure problem, so Shodan/Censys-style census data is not meaningful. The exposure question is fleet version distribution across managed browsers, not internet-facing sockets.
Disclosure / attributionPublished by the Chrome CNA on 2026-06-04. The public record references the Chrome release advisory and Chromium issue 501779840; no external researcher credit was exposed in the reviewed public sources.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The single biggest downward pressure is that this bug lives behind a *victim browsing event* and yields *cross-origin data leakage*, not endpoint compromise. Even in a ubiquitous target like Chrome, that attacker-position requirement and the absence of exploitation evidence keep this out of the urgent patch-now bucket.

HIGH Downgrade from vendor `CRITICAL` to practitioner `MEDIUM`
MEDIUM Exact exploit reliability and breadth of data that can be leaked

Why this verdict

  • Start from the browser ubiquity baseline: Chrome is massively deployed and attacker-reachable through ordinary web traffic, so the vendor baseline is not crazy *in abstract*.
  • First explicit downgrade — attacker position is really browser-content execution: the CVSS says UI:N, but the practical prerequisite is getting a user to render a malicious page or ad. That is weaker than a passive network-reachable service bug and narrows real exposure immediately.
  • Second explicit downgrade — post-render, not post-host: successful exploitation leaks cross-origin browser data; it does not directly give shell, persistence, or sandbox escape on the endpoint. The blast radius is usually bounded to the victim session and the sites the victim is signed into.
  • Third explicit downgrade — exploit economics are poor right now: no KEV entry, no public PoC found, and EPSS 0.00035 all point to low observed attacker pressure.
  • Why it stays at MEDIUM instead of LOW: browsers are one of the few clients attackers can hit at scale, and same-origin boundary erosion can still matter for SSO-heavy enterprises and admin workflows.

Why not higher?

There is no evidence here of renderer compromise, sandbox escape, or host-level code execution. The chain also depends on user browsing plus a valuable authenticated browser context, which is materially more constrained than a true unauthenticated remote service exploit.

Why not lower?

Chrome is everywhere, and getting victims to render malicious web content is not hard. A same-origin boundary leak against users already logged into sensitive SaaS or internal web apps can still produce real business impact even without code execution.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update — Make sure enterprise policy is not pinning outdated Chrome builds and that update deferrals are short. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browsers should normally move much faster than that through standard endpoint management.
  2. Prioritize high-risk user rings — Push fixed Chrome builds first to admins, finance, help desk, and users with access to sensitive SaaS consoles, since browser-session leakage hurts most when the victim is already authenticated. For MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window; use that window to clean up stragglers while fast-tracking high-value populations operationally.
  3. Use remote browser isolation for risky browsing paths — If you already have RBI or equivalent web isolation, route untrusted links, email-click traffic, and unknown domains through it. This is a sensible exposure reducer while you patch, but for MEDIUM there is no mitigation SLA — go straight to the 365-day remediation window.
  4. Inventory browser versions continuously — Treat this as an endpoint software inventory problem, not a perimeter scan problem. Query EDR, MDM, or browser management to find devices below 149.0.7827.53; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
What doesn't work
  • A WAF does not meaningfully help because the exploit executes in the client browser against browser behavior, not your web server.
  • MFA does not stop leakage from an already authenticated browser session; it helps before login, not after a malicious page is running in the victim tab.
  • Perimeter vulnerability scanners will not find this reliably because there is no internet-facing service banner to fingerprint; you need endpoint/browser inventory instead.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through EDR live response, not from an auditor workstation. Invoke it as python3 check_chrome_cve_2026_11153.py on macOS/Linux or py check_chrome_cve_2026_11153.py on Windows; no admin rights are normally required. It checks locally installed Chrome versions and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11153.py
# Detects whether locally installed Google Chrome is below 149.0.7827.53
# 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)
    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 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 path in candidates:
        if path and os.path.exists(path):
            try:
                cmd = [
                    'powershell', '-NoProfile', '-Command',
                    f"(Get-Item '{path}').VersionInfo.ProductVersion"
                ]
                out = subprocess.check_output(cmd, stderr=subprocess.DEVNULL, text=True, timeout=10).strip()
                ver = parse_version(out)
                if ver:
                    return path, ver
            except Exception:
                continue
    return None, None


def get_macos_version():
    candidates = [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
    ]
    for path in candidates:
        if os.path.exists(path):
            try:
                out = subprocess.check_output([path, '--version'], stderr=subprocess.DEVNULL, text=True, timeout=10).strip()
                ver = parse_version(out)
                if ver:
                    return path, ver
            except Exception:
                continue
    return None, None


def get_linux_version():
    candidates = [
        which('google-chrome'),
        which('google-chrome-stable'),
        '/opt/google/chrome/chrome',
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
    ]
    seen = set()
    for path in candidates:
        if not path or path in seen:
            continue
        seen.add(path)
        if os.path.exists(path):
            try:
                out = subprocess.check_output([path, '--version'], stderr=subprocess.DEVNULL, text=True, timeout=10).strip()
                ver = parse_version(out)
                if ver:
                    return path, ver
            except Exception:
                continue
    return None, None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        path, ver = get_windows_version()
    elif 'darwin' in system:
        path, ver = get_macos_version()
    elif 'linux' in system:
        path, ver = get_linux_version()
    else:
        print('UNKNOWN: unsupported OS for this checker')
        sys.exit(2)

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

    installed = '.'.join(map(str, ver))
    fixed = '.'.join(map(str, THRESHOLD))

    if cmp_ver(ver, THRESHOLD) < 0:
        print(f'VULNERABLE: Chrome {installed} found at {path}; fixed version is {fixed} or later')
        sys.exit(1)
    else:
        print(f'PATCHED: Chrome {installed} found at {path}; meets fixed version {fixed} or later')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: pull a browser version report from EDR/MDM/browser management, identify endpoints still below 149.0.7827.53, and make sure Chrome auto-update policy is not being artificially delayed. For this MEDIUM reassessment there is noisgate mitigation SLA to hit here—no mitigation SLA — go straight to the 365-day remediation window—but because this is Chrome, you should still clean up laggards through your normal browser update rings rather than treating it as backlog forever; the noisgate remediation SLA is <= 365 days.

Sources

  1. Chrome CNA / CVE record mirror with references and metadata
  2. Chrome Stable Channel Update for Desktop
  3. Chrome Early Stable Update for Desktop
  4. Chrome for Android Update
  5. Chromium issue reference 501779840
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS model documentation
  8. FIRST EPSS API documentation
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.