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

Insufficient validation of untrusted input in Loader in Google Chrome prior to 149

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

This is a cracked wall inside the vault, but the intruder still has to get through the front door first

CVE-2026-11240 is a Loader input-validation flaw in Google Chrome that affects versions before 149.0.7827.53. Per the CVE description, the attacker must already have compromised the renderer process and then use a crafted HTML page to bypass Site Isolation, Chrome's boundary meant to keep one site's data away from another even if the renderer is hostile.

Google's LOW / 3.1 label is basically right, and if anything a little generous for patch-priority purposes. The decisive friction is that this is not an initial-access bug and not even a standalone code-exec bug; it is a post-renderer-compromise boundary bypass that only matters when chained with another vulnerability, which sharply narrows the real exposed population despite Chrome's massive install base.

"Low priority: this only pays off after a separate renderer compromise, so it is chain-hardening, not initial access"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled content

The chain starts with the victim opening a malicious page or attacker-controlled web content in Chrome. This CVE does nothing by itself at this stage; the page is just the delivery vehicle for the later exploit chain.
Conditions required:
  • Victim uses Chrome before 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced web content
Where this breaks in practice:
  • User interaction is required
  • Web filtering, Safe Browsing, email gateways, and link isolation reduce reach
Detection/coverage: Standard vuln scanners can inventory browser version, but they cannot validate exploitability from this step alone.
STEP 02

Exploit a separate renderer-compromise bug

The attacker must first gain code execution or equivalent control inside Chrome's renderer process using some other vulnerability. That prerequisite is outside CVE-2026-11240 and is the main reason this issue is low operational priority on its own.
Conditions required:
  • A separate renderer exploit exists and works against the target build
  • The victim's browser mitigations do not stop the initial renderer compromise
Where this breaks in practice:
  • This assumes a prior compromise stage
  • Modern Chrome exploit mitigations, sandboxing, and exploit hardening raise the bar
  • Most opportunistic attackers stop here unless they need cross-origin access
Detection/coverage: EDR, browser exploit telemetry, crash analytics, and sandbox-escape hunting may catch the upstream exploit, not this Loader flaw specifically.
STEP 03

Use Loader to punch through Site Isolation

With a compromised renderer, the attacker abuses the Loader validation flaw to bypass Site Isolation using crafted HTML. In practice, this weakens the browser's internal trust boundary that is specifically designed to contain a malicious renderer.
Conditions required:
  • Renderer is already compromised
  • The crafted page state needed for the Loader path is reachable
Where this breaks in practice:
  • Attack complexity is high
  • Site Isolation exists precisely to defend this boundary, so bypassing it is non-trivial
  • Bug details are still restricted in Chromium issue tracking
Detection/coverage: There is no reliable network signature for this step. Version-based detection is the realistic control.
STEP 04

Read cross-site data and exfiltrate

If the bypass succeeds, the attacker may gain access to cross-origin data that should have remained isolated from the compromised renderer. The impact here is mainly confidentiality, not broad integrity or availability destruction.
Conditions required:
  • Victim has valuable authenticated browsing context open
  • Target data is present in reachable browser state
Where this breaks in practice:
  • Impact is limited to what the browser session exposes
  • This is still a browser-context problem, not direct host takeover
  • No evidence so far of public weaponization or KEV-level campaign use
Detection/coverage: DLP, browser telemetry, and anomaly detection might catch exfiltration behavior, but the vuln itself is not directly observable.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found in reviewed sources, and Google did not flag this release item as exploited in the wild.
KEV statusNot listed in CISA KEV as of 2026-06-06.
Public PoC availabilityNo public PoC located in reviewed sources. The Chromium issue for this bug is present but access-restricted, which is normal for fresh Chrome security fixes.
EPSS0.00026 from the supplied intel; percentile not independently confirmed from a primary FIRST source during review.
CVSS vector meaningCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N means remote but high complexity, requires user interaction, and yields only low confidentiality impact in the vendor model.
Affected versionsChrome before 149.0.7827.53; Google's desktop stable bulletin shipped 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS) on 2026-06-02.
Fixed versionsUpgrade to at least 149.0.7827.53. On Windows/macOS, Google's stable rollout includes 149.0.7827.53/54; both are post-fix builds per the Chrome release bulletin.
Boundary at riskThis is a Site Isolation bypass. Chromium describes Site Isolation as a protection meant to keep sites separated even in the presence of renderer vulnerabilities, which is why this bug is only meaningful after that earlier compromise happens.
Exposure / scanabilityNot internet-scannable in the normal Shodan/Censys/FOFA sense. This is client-side browser logic, not a server-side listening service; exposure is measured by endpoint version inventory, not open ports. *That is an inference from the product type and bug class.*
Disclosure / reporterUser-supplied disclosure date is 2026-06-05. Google's stable bulletin shows the bug was reported by Google on 2026-03-27.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to LOW (2.2/10)

The single biggest downward driver is that exploitation requires a prior renderer compromise, which means this is a post-initial-access browser-boundary bypass, not a standalone entry point. That prerequisite collapses the reachable population from 'every Chrome user' to 'only users already hit by another working Chrome exploit chain.'

HIGH Requirement for prior renderer compromise materially lowers real-world urgency
MEDIUM Assessment that there is no public weaponization or active exploitation evidence

Why this verdict

  • Major friction: requires a compromised renderer first — attacker position is no longer simple unauthenticated remote; it implies an earlier successful exploit stage and sharply narrows real deployments that can reach this bug.
  • High-complexity chain — the vendor vector already says AC:H and UI:R, and this sits behind both a user visit and a separate exploit, so each prerequisite compounds downward pressure on patch priority.
  • Blast radius is browser-session confidentiality, not host takeover — the practical outcome is cross-site data exposure inside the browser boundary, not broad code execution on the endpoint.

Why not higher?

There is no evidence this bug is being exploited on its own, and there is no sign of KEV-level campaign use. More importantly, an attacker must first clear the much harder hurdle of renderer compromise, which means this CVE is a chain enhancer rather than the thing that gets them in.

Why not lower?

It still weakens a meaningful Chrome security boundary: Site Isolation exists specifically to contain hostile renderer processes. In a real exploit chain, bypassing that boundary can turn a contained renderer bug into cross-origin data theft, so this is not pure noise.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure enterprise Chrome update policy is not pinned below the fixed build and that stalled channels are corrected. For a LOW verdict there is no mitigation SLA and no remediation SLA beyond backlog hygiene, so fold this into your normal browser maintenance cycle rather than interrupt work.
  2. Keep Site Isolation policy enabled — Verify admins have not weakened Chrome isolation settings for compatibility or memory-saving reasons. This does not fix the bug, but it preserves the broader architectural control and should remain enforced as standard baseline hygiene.
  3. Prioritize upstream renderer bugs higher — Because this CVE only pays off after renderer compromise, your real risk reducer is fast handling of renderer RCE / sandbox / V8 issues that can serve as the first stage. Treat this finding as chain-hardening and let the more dangerous first-stage Chrome bugs drive urgency.
What doesn't work
  • A WAF does not help; this is client-side browser logic, not a server request parser issue.
  • Network IDS signatures are weak here because the meaningful action is post-compromise behavior inside the browser process, not a clean wire-pattern exploit.
  • MFA is irrelevant to the vulnerability itself; it may reduce downstream account abuse, but it does not prevent the Site Isolation bypass.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management runner. Invoke it with python3 chrome_check.py or python chrome_check.py; no admin rights are usually needed as long as the Chrome binary is readable. It checks common Chrome install paths, runs --version, and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_check.py
# Check whether local Google Chrome is at or above the fixed version for CVE-2026-11240.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED_VERSION = (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 run_version_cmd(path):
    try:
        result = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=10)
        output = (result.stdout or '') + ' ' + (result.stderr or '')
        return parse_version(output.strip())
    except Exception:
        return None


def candidate_paths():
    system = platform.system()
    paths = []

    if system == 'Windows':
        env_paths = [
            os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(os.environ.get('LocalAppData', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        paths.extend(env_paths)
    elif system == 'Darwin':
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium-browser', 'chromium']:
            resolved = shutil.which(name)
            if resolved:
                paths.append(resolved)
        paths.extend([
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
        ])

    # Deduplicate while preserving order
    seen = set()
    uniq = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            uniq.append(p)
    return uniq


def main():
    found = []
    for path in candidate_paths():
        if os.path.exists(path) or shutil.which(path):
            version = run_version_cmd(path)
            if version:
                found.append((path, version))

    if not found:
        print('UNKNOWN - Google Chrome not found or version could not be determined')
        sys.exit(2)

    # Evaluate the highest version found
    found.sort(key=lambda x: x[1], reverse=True)
    path, version = found[0]
    version_str = '.'.join(str(x) for x in version)
    fixed_str = '.'.join(str(x) for x in FIXED_VERSION)

    if version >= FIXED_VERSION:
        print(f'PATCHED - {path} version {version_str} >= fixed {fixed_str}')
        sys.exit(0)
    else:
        print(f'VULNERABLE - {path} version {version_str} < fixed {fixed_str}')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency patch window on this one. This is a LOW reassessment because the chain requires a prior renderer compromise, so there is noisgate mitigation SLA: no SLA (treat as backlog hygiene) and noisgate remediation SLA: no SLA (treat as backlog hygiene); fold it into your next normal browser update wave, verify no Chrome rings are pinned below 149.0.7827.53, and spend your real urgency budget on any Chrome renderer/V8/sandbox bugs that could act as the first stage of the chain.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. Chromium Site Isolation overview
  5. Chromium Site Isolation design document
  6. CISA Known Exploited Vulnerabilities Catalog
  7. Chromium issue tracker entry 497030032
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.