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

Inappropriate implementation in ImageCapture in Google Chrome prior to 149

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

This is not the burglar kicking in your front door, it is the stairwell they use only after getting inside

CVE-2026-11296 is an *ImageCapture* implementation flaw in Google Chrome that affects versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. The bug does not give an attacker initial code execution by itself; it only helps after the attacker has already compromised the Chrome renderer process, at which point a crafted HTML page can be used to escalate privileges and weaken the browser sandbox boundary.

The supplied vendor baseline of HIGH 7.5 overshoots real-world enterprise risk. The decisive fact is prerequisite friction: an attacker must first land renderer compromise with a separate bug, so this is a *second-stage chain component*, not a standalone internet-reachable foothold; that is why Google/Chromium’s own advisory trail tags this specific issue as Low severity even though the supplied CVSS string scores it higher.

"Chain-only Chrome sandbox escape: important to fix, but not a front-door emergency."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious page

The attacker needs a user to browse to attacker-controlled content, typically via phishing, malvertising, or a compromised site using a generic browser exploit kit. CVE-2026-11296 is not the initial trigger here; it rides behind the first-stage web content.
Conditions required:
  • Target user opens attacker-controlled or attacker-influenced web content
  • Chrome is in the affected version range
Where this breaks in practice:
  • User interaction is required
  • Secure web gateways, DNS filtering, and browser reputation controls cut a lot of this traffic off before exploitation starts
Detection/coverage: Network controls may catch delivery, but vulnerability scanners generally cannot prove this step from outside because Chrome is endpoint software.
STEP 02

Achieve renderer compromise with a separate bug

The attacker must first gain code execution or equivalent memory corruption inside Chrome’s renderer using some *other* renderer-reachable vulnerability, such as a V8, DOM, or media bug. In other words, this CVE presumes the attacker already beat Chrome’s first safety layer.
Conditions required:
  • A separate exploitable renderer bug exists and is successfully chained
  • Target environment permits execution of browser-side exploit primitives
Where this breaks in practice:
  • This is the biggest real-world brake: no renderer compromise means no path to use this CVE
  • Modern exploit chains against current Chrome builds are expensive and brittle
Detection/coverage: EDR, browser crash telemetry, and exploit-prevention signals may show abnormal renderer behavior, but signature coverage is inconsistent unless the initial exploit is already known.
STEP 03

Abuse ImageCapture to weaken the sandbox boundary

Once inside the renderer, a custom sandbox-escape primitive can target the flawed ImageCapture implementation to perform privilege escalation. This is the actual role of CVE-2026-11296: it is a post-compromise bridge from a low-privilege browser process toward a more valuable execution context.
Conditions required:
  • Renderer process is already compromised
  • Vulnerable Chrome build prior to 149.0.7827.53 is present
  • Exploit developer has a working primitive for this specific bug
Where this breaks in practice:
  • Google has restricted bug details while users update, which slows commodity weaponization
  • No public proof-of-concept or in-the-wild exploitation was found in this review
  • Sandbox-escape reliability tends to be OS- and build-sensitive
Detection/coverage: External scanners will miss this entirely. Detection is mostly behavioral: anomalous child processes from chrome, suspicious broker interactions, crashes, or EDR detections around browser sandbox escape techniques.
STEP 04

Run follow-on host actions

If the sandbox escape succeeds, the attacker can stage credential theft, persistence attempts, or lateral movement tooling under the user context or whatever privilege the escape reaches. The practical impact is turning a browser compromise into an endpoint compromise, which matters, but still usually on a single host at a time.
Conditions required:
  • Successful sandbox escape
  • Follow-on payload or living-off-the-land tooling
Where this breaks in practice:
  • EDR, application control, and user-context limitations often still contain the blast radius
  • This is not a wormable enterprise-wide failure mode
Detection/coverage: Strong EDR coverage should catch child-process spawns, token abuse, LOLBin execution, or suspicious file/registry/network activity sourced from a browser lineage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found during this review, and not listed in CISA KEV.
Proof-of-concept availabilityNo public GitHub PoC or turnkey exploit located for CVE-2026-11296; Chromium issue details remain restricted, which raises attacker cost.
EPSS0.00066 from the supplied intel — extremely low exploit-likelihood signal relative to the broader CVE population.
KEV statusAbsent from KEV as checked against CISA's catalog; no KEV add date because there is no listing.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H — this reads like a remote browser bug, but it obscures the most important operational fact: exploitation assumes prior renderer compromise.
Affected versionsGoogle Chrome prior to 149.0.7827.53 per NVD description; the June 2, 2026 stable release updated Linux to 149.0.7827.53 and Windows/macOS to 149.0.7827.53/54.
Fixed versionsPatch level is 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/macOS. Because Chrome ships frequent point updates, use the vendor build number, not generic major version 149, as your compliance key.
Scanner / exposure realityInternet exposure engines like Shodan/Censys/FOFA are not meaningful here because Chrome is client software. The real exposure source is your endpoint inventory, browser version telemetry, and VDI/golden-image drift.
Disclosure timelineStable fix shipped on June 2, 2026; NVD published the CVE on June 4, 2026; supplied disclosure date is 2026-06-05.
Reporter / severity mismatchChrome’s release post says this bug was reported by Google on April 14, 2026, and the NVD description explicitly notes Chromium security severity: Low — a strong signal that the supplied HIGH 7.5 baseline is overstated.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (4.9/10)

The single biggest driver is that this CVE requires prior renderer compromise, which means it is not a front-door vulnerability but a second-stage escape in an already-successful browser exploit chain. That prerequisite drastically narrows the reachable population and makes the vendor-style network CVSS a poor proxy for enterprise patch urgency.

HIGH Attack-path friction assessment
MEDIUM Public exploit availability and operational abuse potential

Why this verdict

  • Major downward adjustment for attacker position: exploitation starts from a *compromised renderer*, which implies the attacker already landed a separate browser exploit; this is post-initial-access within the browser security model, not unauthenticated remote compromise from scratch.
  • Vendor-native signal points lower: Google/Chromium’s own advisory trail marks this specific issue as *Low*, which fits the real attack path better than the supplied 7.5 CVSS baseline.
  • Low threat pressure: no KEV listing, no public PoC found, and supplied EPSS 0.00066 all argue against emergency prioritization despite Chrome’s ubiquity.

Why not higher?

This is not a one-bug, one-click endpoint takeover. The requirement for a separate renderer compromise is compounding friction: it assumes attacker sophistication, another exploitable bug, and a narrower set of successful chains than the base CVSS implies.

Why not lower?

A browser sandbox escape is still strategically valuable because it turns renderer footholds into meaningful host compromise. Chrome is everywhere in enterprise fleets, so even a chain-only bug deserves tracked remediation rather than backlog oblivion.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser version telemetry — Pull exact Chrome build numbers from your endpoint platform and alert on anything below 149.0.7827.53; for a MEDIUM verdict there is no mitigation SLA, so use this as inventory discipline while you drive patching inside the ≤365 day remediation window.
  2. Separate privileged work from daily browsing — Keep admins, helpdesk, and server operators off normal browsing sessions or move them to hardened admin workstations. This cuts the payoff of any sandbox-escape chain, and because there is no mitigation SLA for MEDIUM, treat it as a standing control rather than an emergency exception.
  3. Turn on strong EDR detections for browser lineage — Prioritize detections for child-process creation, LOLBin execution, token abuse, and suspicious file writes originating from chrome.exe or equivalent browser parents. That will not stop the bug, but it improves odds of catching the post-escape stage while you remediate within the ≤365 day window.
  4. Use browser isolation for high-risk user groups — Remote browser isolation or disposable browsing sessions meaningfully reduce the value of renderer-compromise-plus-escape chains for contractors, research users, and phishing-prone groups. There is no mitigation SLA here, so apply where the business risk justifies the operational cost.
What doesn't work
  • A WAF does not help; the exploit path lives inside the client browser after the user renders hostile content.
  • Perimeter internet scanning does not help you prioritize this; Chrome is endpoint software, so Shodan-style visibility is basically noise.
  • Relying on MFA does not block the exploit chain; it may reduce downstream account abuse, but it does nothing to stop renderer compromise or sandbox escape.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management agent, not from an auditor workstation. Invoke it with python3 check_cve_2026_11296.py; no admin rights are normally required, but elevated rights may help if Chrome is installed in a protected path. It checks installed Google Chrome versions across Windows, macOS, and Linux and prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11296.py
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

THRESHOLD = (149, 0, 7827, 53)


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


def cmp_version(a: Tuple[int, ...], b: Tuple[int, ...]) -> int:
    la = list(a)
    lb = list(b)
    while len(la) < len(lb):
        la.append(0)
    while len(lb) < len(la):
        lb.append(0)
    return (la > lb) - (la < lb)


def run_version(cmd: List[str]) -> Optional[str]:
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=10)
        out = (p.stdout or '').strip()
        return out if out else None
    except Exception:
        return None


def discover_candidates() -> List[List[str]]:
    system = platform.system().lower()
    cmds = []

    if 'windows' in system:
        local = os.environ.get('LOCALAPPDATA', r'C:\Users\Default\AppData\Local')
        program_files = os.environ.get('ProgramFiles', r'C:\Program Files')
        program_files_x86 = os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)')
        paths = [
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(program_files_x86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        for p in paths:
            if os.path.exists(p):
                cmds.append([p, '--version'])
        if shutil.which('chrome'):
            cmds.append(['chrome', '--version'])
    elif 'darwin' in system:
        mac_path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
        if os.path.exists(mac_path):
            cmds.append([mac_path, '--version'])
        if shutil.which('google-chrome'):
            cmds.append(['google-chrome', '--version'])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium-browser', 'chromium']:
            path = shutil.which(name)
            if path:
                cmds.append([path, '--version'])

    # De-duplicate commands while preserving order
    seen = set()
    uniq = []
    for c in cmds:
        key = tuple(c)
        if key not in seen:
            uniq.append(c)
            seen.add(key)
    return uniq


def main() -> int:
    candidates = discover_candidates()
    if not candidates:
        print('UNKNOWN - Google Chrome executable not found')
        return 2

    found_versions = []
    for cmd in candidates:
        out = run_version(cmd)
        if not out:
            continue
        ver = parse_version(out)
        if ver:
            found_versions.append((cmd[0], ver, out))

    if not found_versions:
        print('UNKNOWN - Could not determine Chrome version')
        return 2

    vulnerable = []
    patched = []
    for path, ver, raw in found_versions:
        if cmp_version(ver, THRESHOLD) < 0:
            vulnerable.append((path, raw))
        else:
            patched.append((path, raw))

    if vulnerable:
        details = '; '.join([f'{p} => {r}' for p, r in vulnerable])
        print(f'VULNERABLE - {details}')
        return 1

    details = '; '.join([f'{p} => {r}' for p, r in patched])
    print(f'PATCHED - {details}')
    return 0


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

If you remember one thing.

TL;DR
Monday morning, treat this as a tracked browser hygiene fix, not a fire drill: validate which endpoints are still below 149.0.7827.53, make sure Chrome auto-update is actually landing, and mop up laggards through your normal workstation patch flow. Under the noisgate mitigation SLA, there is no mitigation SLA — go straight to the 365-day remediation window; under the noisgate remediation SLA, the vendor patch must land within ≤365 days, though most enterprises should clear browser stragglers far sooner because chainable sandbox escapes age badly once adjacent renderer bugs appear.

Sources

  1. NVD CVE-2026-11296
  2. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue 502493950
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. FIRST EPSS overview
  7. Canadian Centre for Cyber Security advisory AV26-544
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.