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

Inappropriate implementation in DOM in Google Chrome prior to 149

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

This is a bad ID check at the lobby door, not someone blowing the vault open

CVE-2026-11036 is a DOM-layer same-origin-policy bypass in Google Chrome before 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS. The attacker has to get a user onto a crafted HTML page, and the bug lives inside the browser’s handling of origin boundaries rather than delivering code execution or a sandbox escape.

Google tagged it MEDIUM with CVSS 6.5, and that is technically defensible in a vacuum because breaking origin boundaries can let an attacker drive actions inside a victim’s authenticated web sessions. But for enterprise patch triage, the real-world chain is narrower: it is *client-side*, needs *user interaction*, has *no known in-the-wild exploitation*, has *extremely low EPSS*, and does *not* turn into device takeover by itself. That pushes this down into backlog hygiene, not emergency response.

"This is a browser trust-boundary slip, not a mass-compromise patch fire."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land the victim on attacker-controlled content

The attacker needs the target to render a crafted HTML page in a vulnerable Chrome build. In practice this means phishing, malvertising, a compromised legitimate site, or some other content-delivery path. Weaponization is just web content, so there is no installer or binary to catch.
Conditions required:
  • Target is using Google Chrome prior to 149.0.7827.53
  • Attacker can get the user to open a malicious page
  • Browser has not yet auto-updated or been restarted into the fixed build
Where this breaks in practice:
  • Requires user interaction (UI:R), which immediately removes drive-by-at-scale certainty
  • Chrome auto-update reduces dwell time on unmanaged stale builds
  • Enterprise mail, DNS, SWG, and browser isolation stacks can block the delivery path before rendering
Detection/coverage: Good coverage on the *delivery* side from email security, web proxies, DNS filtering, and browser isolation. Weak signature-level detection for the HTML itself unless a public PoC appears.
STEP 02

Trigger the DOM origin-validation flaw

Once the page loads, attacker-controlled script must hit the specific DOM logic flaw that mishandles origin validation. The underlying Chromium bug reference is 497964917; public details were still restricted when Google published the fix, which is normal for Chrome releases. Without a public write-up, defenders should assume exploit reliability is not trivial but also not impossible.
Conditions required:
  • Specific vulnerable DOM code path is reachable from web content
  • Exploit logic works against the victim’s exact Chrome build and platform
  • No renderer-hardening or timing differences break the crafted sequence
Where this breaks in practice:
  • Bug details are restricted, so copy-paste exploitation is less likely right now
  • DOM/SOP bypasses often need precise browser-state assumptions and are less portable than simple memory-corruption bugs
  • No evidence this bug bypasses sandbox or OS boundaries
Detection/coverage: Traditional vulnerability scanners will mostly infer exposure from browser version, not active exploitability. Telemetry from EDR/browser logs may only show suspicious navigation or script-heavy pages, not a clean IOC.
STEP 03

Abuse the victim browser’s authenticated session

If the origin boundary is bypassed, the attacker can potentially act with the victim’s browser session against target web apps. The likely outcome is unauthorized state-changing actions or application tampering in the context of sites the user is already logged into, which matches the I:H and C:N CVSS profile more than full data theft or host compromise.
Conditions required:
  • Victim is simultaneously authenticated to a relevant target application
  • The target application performs meaningful actions through the reachable browser context
  • The app’s own anti-abuse controls do not stop the resulting requests
Where this breaks in practice:
  • Blast radius is user-session scoped, not enterprise-wide infrastructure takeover
  • Modern SaaS apps may require step-up auth, CSRF defenses, re-auth prompts, or confirmation flows for sensitive actions
  • No direct persistence or privilege escalation on the endpoint from this CVE alone
Detection/coverage: Best detection is in SaaS and IdP telemetry: anomalous user actions, impossible sequences, or actions coming from untrusted referrers/browser patterns. Endpoint scanners do not meaningfully observe the business impact here.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in consulted sources; not KEV-listed.
PoC availabilityNo public proof-of-concept located in primary or reputable secondary sources at assessment time; Chromium bug details appear restricted via issue 497964917.
EPSS0.00016 from the user-provided intel; that is extremely low predicted near-term exploitation probability. Percentile was not verified from consulted sources.
KEV statusNo entry for CVE-2026-11036 in the CISA KEV catalog.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N — remote and low-complexity, but gated by user interaction and limited to integrity impact rather than code execution.
Affected versionsGoogle Chrome prior to 149.0.7827.53; Chrome stable release notes specify 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows and macOS.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later on Linux, and 149.0.7827.53/.54 or later on Windows/macOS.
Exposure/scanning realityThis is not internet-enumerable in the usual Shodan/Censys sense because it is a client-side browser flaw, not a listening network service. Exposure measurement is an asset inventory / browser version problem, not an external attack-surface scan problem.
Disclosure timelineChrome stable update published 2026-06-02; NVD published the CVE on 2026-06-04 and CISA-ADP added CVSS/CWE on 2026-06-05.
ReporterReported by Google on 2026-03-30 per the Chrome stable channel advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

The decisive downgrade factor is that this bug is post-click client-side abuse, not unauthenticated remote compromise of a server or endpoint. It needs a victim on a stale Chrome build to visit attacker content, and even then the impact stays inside browser trust boundaries rather than becoming system takeover.

HIGH Affected-version and fix-version identification
MEDIUM Real-world exploitability assessment with restricted bug details
HIGH No known active exploitation / not KEV-listed

Why this verdict

  • Downward adjustment: requires user interaction — the attacker must get a user to open crafted web content, so this is not a blind unauthenticated internet smash-and-grab.
  • Downward adjustment: client-side only — there is no server exposure population to sweep with scanners; reach depends on stale browser versions on endpoints and a successful delivery channel.
  • Downward adjustment: blast radius is session-scoped — even if exploited, the likely impact is misuse of the victim’s web session, not endpoint code execution or domain-wide compromise from this CVE alone.
  • Downward adjustment: no exploitation signal — no KEV entry, no public campaign reporting, and the provided EPSS 0.00016 all argue against urgent attacker demand.
  • Downward adjustment: bug details restricted — with the Chromium issue still closed/restricted, opportunistic commodity exploitation is less likely in the short term.

Why not higher?

This does not present like a broad enterprise-compromise primitive. There is no evidence here of sandbox escape, code execution, credential dumping, or a network-reachable server foothold, and the attack chain starts with convincing a user to browse attacker content. That is too much friction for HIGH or CRITICAL patch priority in a 10,000-host environment.

Why not lower?

It still breaks a core browser trust boundary: same-origin policy. If a victim is logged into important internal or SaaS applications, a successful exploit could still tamper with business data or drive unauthorized actions in that user context. That is enough to keep it above IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure Chrome auto-update is enabled and that managed endpoints actually relaunch into the new build. For a LOW verdict there is no SLA deadline, but this is still the cleanest control because stale browser versions are the whole exposure condition.
  2. Block unsupported/stale Chrome builds — Use endpoint posture checks, MDM, or EDR inventory to flag Chrome versions below 149.0.7827.53 and push users to update. For LOW, treat this as backlog hygiene rather than an emergency change.
  3. Lean on browser isolation and secure web gateways — Remote browser isolation, DNS filtering, and SWG controls cut off the most likely initial condition: loading attacker-controlled HTML. They reduce exploit opportunity immediately even before every endpoint finishes normal update cadence.
  4. Harden sensitive apps with step-up auth — For high-value internal and SaaS workflows, require re-authentication or MFA for destructive actions so a browser-session abuse bug has less room to cause damage. This matters most for finance, admin, and identity consoles.
What doesn't work
  • Perimeter vulnerability scanning does not solve this well, because Chrome is a client application and not externally fingerprintable like a server daemon.
  • A WAF in front of your web apps is not a primary control here, because the vulnerable component is the victim browser rendering attacker content.
  • Network segmentation is mostly irrelevant to the initial exploit path; the attacker comes through normal web browsing, not lateral movement to a listening service.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tooling, not from an auditor workstation. Invoke it as python3 check_chrome_cve_2026_11036.py on macOS/Linux or py check_chrome_cve_2026_11036.py on Windows; standard user rights are usually enough, though locked-down Windows registry access may require local read access.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for CVE-2026-11036 exposure based on installed Google Chrome version.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import plistlib
import re
import shutil
import subprocess
import sys

FIXED_VERSION = "149.0.7827.53"


def parse_version(v):
    parts = re.findall(r"\d+", v or "")
    if not parts:
        return None
    return tuple(int(x) for x in parts)


def cmp_version(a, b):
    va = parse_version(a)
    vb = parse_version(b)
    if va is None or vb is None:
        return None
    max_len = max(len(va), len(vb))
    va = va + (0,) * (max_len - len(va))
    vb = vb + (0,) * (max_len - len(vb))
    if va < vb:
        return -1
    if va > vb:
        return 1
    return 0


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        if p.returncode == 0:
            return (p.stdout or p.stderr).strip()
    except Exception:
        pass
    return None


def extract_version(text):
    if not text:
        return None
    m = re.search(r"(\d+\.\d+\.\d+\.\d+)", text)
    return m.group(1) if m else None


def get_linux_version():
    candidates = [
        ["google-chrome", "--version"],
        ["google-chrome-stable", "--version"],
        ["/opt/google/chrome/chrome", "--version"],
        ["chromium-browser", "--version"],
        ["chromium", "--version"],
    ]
    for cmd in candidates:
        exe = cmd[0]
        if exe.startswith("/") or shutil.which(exe):
            out = run_cmd(cmd)
            ver = extract_version(out)
            if ver:
                return ver
    return None


def get_macos_version():
    plist_paths = [
        "/Applications/Google Chrome.app/Contents/Info.plist",
        os.path.expanduser("~/Applications/Google Chrome.app/Contents/Info.plist"),
    ]
    for path in plist_paths:
        if os.path.exists(path):
            try:
                with open(path, "rb") as f:
                    data = plistlib.load(f)
                ver = data.get("KSVersion") or data.get("CFBundleShortVersionString")
                if ver:
                    return ver
            except Exception:
                pass
    return None


def get_windows_version():
    reg_queries = [
        ["reg", "query", r"HKLM\SOFTWARE\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\SOFTWARE\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\SOFTWARE\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in reg_queries:
        out = run_cmd(cmd)
        ver = extract_version(out)
        if ver:
            return ver

    file_candidates = [
        os.path.join(os.environ.get("ProgramFiles", r"C:\Program Files"), r"Google\Chrome\Application\chrome.exe"),
        os.path.join(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"), r"Google\Chrome\Application\chrome.exe"),
        os.path.join(os.environ.get("LOCALAPPDATA", ""), r"Google\Chrome\Application\chrome.exe"),
    ]
    for path in file_candidates:
        if path and os.path.exists(path):
            out = run_cmd([path, "--version"])
            ver = extract_version(out)
            if ver:
                return ver
    return None


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

    if "windows" in system:
        version = get_windows_version()
    elif "darwin" in system:
        version = get_macos_version()
    elif "linux" in system:
        version = get_linux_version()
    else:
        print("UNKNOWN - unsupported platform: {}".format(platform.system()))
        sys.exit(2)

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

    cmp_result = cmp_version(version, FIXED_VERSION)
    if cmp_result is None:
        print("UNKNOWN - unable to parse installed version: {}".format(version))
        sys.exit(2)

    if cmp_result < 0:
        print("VULNERABLE - installed Chrome version {} is older than fixed {}".format(version, FIXED_VERSION))
        sys.exit(1)
    else:
        print("PATCHED - installed Chrome version {} is at or above fixed {}".format(version, FIXED_VERSION))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not let this jump the queue ahead of remotely reachable server-side bugs or Chrome RCE/sandbox-escape issues. For a LOW noisgate verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond normal backlog hygiene, so the practical move is to verify Chrome auto-update health, identify any endpoints still below 149.0.7827.53, and roll them into routine browser maintenance rather than an emergency campaign.

Sources

  1. NVD entry for CVE-2026-11036
  2. Google Chrome Stable Channel Update for Desktop (June 2, 2026)
  3. Google Chrome Early Stable Update for Desktop (May 29, 2026)
  4. Chromium issue reference 497964917
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. GovCERT.HK alert on Chrome 149 vulnerabilities
  8. SecurityWeek coverage of Chrome 149 patch release
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.