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

Integer overflow in GPU in Google Chrome prior to 149

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

This bug is the getaway car, not the bank robbery

CVE-2026-11256 is a Chrome GPU-process memory-safety bug described by Google/NVD as an integer overflow or out-of-bounds read in GPU, fixed in Chrome 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS. The important part is the prerequisite buried in the description: the attacker must have already compromised the renderer process and then use a crafted HTML page to try to turn that foothold into a sandbox escape.

The vendor/CISA-ADP 8.3 HIGH score overstates the standalone enterprise patch priority. In practice this is a post-initial-code-execution browser escape primitive, not a first-hop internet-facing compromise path. Google itself tagged the underlying Chromium issue as Low severity, there is no KEV listing, the supplied EPSS is tiny, and there is no public exploitation evidence in the source set reviewed here. The reach is broad because Chrome is everywhere; the exploit chain is narrow because this bug is only useful after step one already succeeded.

"This is a second-stage Chrome escape, not a clean one-click RCE—patch it, but don't drop everything."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker needs a separate browser exploit that yields renderer-process compromise, typically via a malicious web page and a distinct memory-corruption or logic bug. CVE-2026-11256 does not provide that first foothold; it only becomes relevant after the renderer is already hostile. In real operations this means the bug is a chain component, not a complete intrusion path.
Conditions required:
  • Target is running Chrome before 149.0.7827.53/.54
  • Victim loads attacker-controlled content
  • Attacker has a separate stage-1 exploit that compromises the renderer
Where this breaks in practice:
  • A working renderer exploit is a hard prerequisite and dramatically shrinks the attacker pool
  • Modern browser hardening, site isolation, and exploit mitigations raise the bar on reliable renderer compromise
  • No public stage-1 chain tied to this CVE was found in the reviewed sources
Detection/coverage: Most vuln scanners will only flag vulnerable versioning; they will not prove exploitability. EDR/browser telemetry may catch crashes or exploit chains, but static scanning cannot validate the stage-1 prerequisite.
STEP 02

Trigger the GPU bug from hostile renderer content

Once inside the renderer, the attacker drives a crafted HTML/Web content path into the GPU process and attempts to exercise the vulnerable code path. The intended weaponization is a sandbox-escape transition, using the GPU bug as the boundary-crossing primitive. This is the high-value step, but it depends on reliable inter-process reachability and precise memory corruption behavior.
Conditions required:
  • Renderer can reach the affected GPU code path
  • GPU process is enabled and the vulnerable path is actually used on that platform
  • Exploit reliability across Windows/macOS/Linux build differences
Where this breaks in practice:
  • GPU exploitability is often platform- and driver-sensitive
  • Headless, policy-constrained, or GPU-disabled contexts may reduce reachability
  • Chrome bug details remain restricted until most users are updated, limiting commodity weaponization
Detection/coverage: Version scanners can detect exposure; exploit-specific network signatures are unlikely. Crash telemetry, browser event logs, and EDR child-process/memory anomaly detection are more realistic than signature-based IDS here.
STEP 03

Convert sandbox escape into host impact

If the GPU bug successfully breaks the sandbox boundary, the attacker moves from renderer confinement into a more privileged browser process context and can then pursue data theft, persistence staging, or follow-on local privilege escalation. The technical impact can be severe, but only after two prior wins: renderer compromise and successful escape.
Conditions required:
  • Successful sandbox escape primitive
  • Target data or follow-on execution path available on the host
  • No upstream containment by EDR, application control, or user-profile isolation
Where this breaks in practice:
  • A browser sandbox escape is still not kernel/admin compromise
  • EDR and browser isolation controls can still contain post-escape behavior
  • Blast radius is usually the current user/session unless chained again
Detection/coverage: Post-escape activity is where defenders have the best chance: EDR process trees, browser child-process anomalies, unusual file access from Chrome, and follow-on LOLBin usage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the reviewed source set; not listed in CISA KEV.
KEV statusNot KEV-listed as of this review. CISA's KEV mirror/repo is the authoritative public tracking path for additions.
Public PoC availabilityNo public PoC located in primary-source review. Google notes bug details may stay restricted until most users are updated, which slows commodity weaponization.
EPSS0.00068 from the user-supplied intel, which is very low modeled near-term exploitation probability. Percentile was not independently verified from a primary source during this review.
CVSS vector reality checkAV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H scores the *full theoretical chain impact*, but the buried prerequisite is the real story: requires prior renderer compromise, which is major downward pressure in enterprise prioritization.
Affected versionsGoogle/NVD indicate Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS.
Fixed versionsPatch level is 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). This is a browser self-update / enterprise rollout problem, not an OS package backport issue in the advisory reviewed.
Vendor vs Chromium severityUser-supplied vendor/CISA-ADP baseline is HIGH 8.3, but the Chrome release page classifies this specific bug as Low and names it Out of bounds read in GPU.
Exposure/scanning realityShodan/Censys/FOFA exposure data are not meaningful here because Chrome desktop is a client-side browser, not an internet-exposed server service. Asset inventory and endpoint version telemetry matter more than perimeter scanning.
Disclosure / reportingDisclosed around 2026-06-04/2026-06-05 depending on source timestamping. Google credits the issue as reported by Google on 2026-04-02 in the Chrome stable release notes.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The decisive factor is the attacker position requirement: this bug needs the renderer to be compromised first, so it is a second-stage exploit-chain component rather than a standalone internet-to-host compromise. That sharply reduces the number of real adversaries who can use it and the number of enterprise incidents where this CVE is the first thing that matters.

HIGH Affected-version and fixed-version identification
HIGH Assessment that prior renderer compromise is the dominant friction
MEDIUM Public PoC absence based on open-source review rather than exhaustive closed-source intel

Why this verdict

  • Major downward adjustment: requires prior renderer compromise. That implies a separate exploit or earlier stage has already succeeded, making this post-initial-access within the browser trust boundary rather than a direct one-bug intrusion path.
  • Population narrowing. Chrome is ubiquitous, but only the subset on vulnerable builds *and* reachable with a working renderer exploit chain can be hit; that is far smaller than the raw install base suggests.
  • No active exploitation amplifier. Not KEV-listed, no confirmed in-the-wild use found, and user-supplied EPSS is extremely low, so there is no current threat-intel reason to keep the vendor HIGH intact.
  • Modern controls still have interception points. Safe Browsing, browser auto-update, EDR, exploit mitigations, and process-behavior monitoring all have chances to break the full chain before host-level impact.
  • Google's own bug taxonomy is a tell. The Chrome release notes classify this issue as Low, which aligns better with a limited, chained escape primitive than with a broadly weaponizable first-hop browser RCE.

Why not higher?

There is no evidence here of active exploitation, no public PoC in the reviewed sources, and no direct unauthenticated one-bug code-execution path from web content to host escape. The need for a pre-existing renderer compromise is compounded friction, and compounded friction is exactly what should drag enterprise priority down.

Why not lower?

It still lives in Chrome, one of the highest-value and most broadly deployed user attack surfaces in the enterprise. If paired with a renderer bug, the impact can become serious quickly, so this is not backlog-trash; it belongs in normal browser patch hygiene, not in ignore-land.

05 · Compensating Control

What to do — in priority order.

  1. Enforce rapid Chrome auto-update — Make sure enterprise policy is not delaying browser self-updates and that devices converge on 149.0.7827.53/54 through the normal browser channel. For a MEDIUM noisgate verdict there is no mitigation SLA; use this as routine exposure reduction while working inside the <=365 day remediation window.
  2. Watch for renderer-to-GPU crash clusters — Correlate browser crash telemetry, GPU-process instability, and suspicious browsing events on vulnerable versions. This will not prevent exploitation, but it can surface exploit development or failed chains while you complete remediation; again, no mitigation SLA applies for MEDIUM.
  3. Keep EDR tuned on browser child-process and file-access anomalies — If a sandbox escape succeeds, defenders usually win on the *post-escape behavior*, not on the memory bug itself. Validate detections for unusual Chrome process ancestry, LOLBin launches, credential store access, and writes outside normal profile paths; this is compensating coverage until patched.
  4. Reduce unmanaged browser variance — Collapse straggler channels, unmanaged portable installs, and frozen VDI images into your standard browser lifecycle. The biggest practical risk with Chrome flaws is usually not exploit sophistication but fleet drift.
What doesn't work
  • A perimeter scanner won't help much because this is a client-side desktop browser issue, not a network-exposed server vulnerability.
  • Blocking one domain or URL is not a durable control; the prerequisite is hostile web content plus a separate renderer exploit, and delivery can move anywhere.
  • Relying on CVSS alone doesn't work here because the raw 8.3 hides the crucial real-world friction: renderer compromise first.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent, not from an external auditor box. Invoke it with python3 check_chrome_cve_2026_11256.py on the host; no admin rights are usually needed, though wider path access helps on shared systems. The script checks local Chrome/Chromium version(s) and reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11256.py
# Determine local exposure to CVE-2026-11256 based on installed Chrome/Chromium version.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

TARGET_CVE = 'CVE-2026-11256'
FIX_LINUX = (149, 0, 7827, 53)
FIX_WIN_MAC = (149, 0, 7827, 53)  # advisory says Windows/Mac 149.0.7827.53/54; .53 is sufficient baseline


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 version_lt(a, b):
    return a < b


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


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

    if 'windows' in system:
        env = os.environ
        possible = [
            Path(env.get('ProgramFiles', 'C:\\Program Files')) / 'Google/Chrome/Application/chrome.exe',
            Path(env.get('ProgramFiles(x86)', 'C:\\Program Files (x86)')) / 'Google/Chrome/Application/chrome.exe',
            Path(env.get('LocalAppData', '')) / 'Google/Chrome/Application/chrome.exe',
            Path(env.get('ProgramFiles', 'C:\\Program Files')) / 'Chromium/Application/chrome.exe',
        ]
        for p in possible:
            if str(p) and p.exists():
                cmds.append([str(p), '--version'])
        for exe in ['chrome', 'chrome.exe']:
            path = shutil.which(exe)
            if path:
                cmds.append([path, '--version'])
    elif 'darwin' in system:
        possible = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ]
        for p in possible:
            if os.path.exists(p):
                cmds.append([p, '--version'])
        for exe in ['google-chrome', 'chromium', 'chromium-browser', 'chrome']:
            path = shutil.which(exe)
            if path:
                cmds.append([path, '--version'])
    else:
        for exe in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
            path = shutil.which(exe)
            if path:
                cmds.append([path, '--version'])
        possible = [
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ]
        for p in possible:
            if os.path.exists(p):
                cmds.append([p, '--version'])

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


def main():
    system = platform.system().lower()
    fix_version = FIX_WIN_MAC if ('windows' in system or 'darwin' in system) else FIX_LINUX

    found = []
    for cmd in candidate_commands():
        out = run_cmd(cmd)
        ver = parse_version(out)
        if ver:
            found.append((cmd[0], ver, out))

    if not found:
        print(f'UNKNOWN: {TARGET_CVE} - Chrome/Chromium not found or version unreadable')
        sys.exit(2)

    vulnerable = []
    patched = []
    for path, ver, raw in found:
        if version_lt(ver, fix_version):
            vulnerable.append((path, ver, raw))
        else:
            patched.append((path, ver, raw))

    # If any installed instance is vulnerable, call host vulnerable.
    if vulnerable:
        for path, ver, raw in vulnerable:
            print(f'VULNERABLE: {path} -> {raw}')
        if patched:
            for path, ver, raw in patched:
                print(f'PATCHED: {path} -> {raw}')
        sys.exit(1)

    for path, ver, raw in patched:
        print(f'PATCHED: {path} -> {raw}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a normal-but-real browser patch rather than an all-hands fire drill. Because the reassessed severity is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, that means confirm browser auto-update is working, identify version-drifted endpoints, and fold Chrome 149.0.7827.53/54 into your next routine browser rollout rather than emergency change control. Do not ignore it: complete patching well inside the noisgate remediation SLA of <=365 days, with unmanaged endpoints and frozen images prioritized first because they are where Chrome risk quietly lingers.

Sources

  1. NVD CVE-2026-11256
  2. Chrome Releases: Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue reference 498856565
  4. Canadian Centre for Cyber Security advisory AV26-544
  5. FIRST EPSS API documentation
  6. CISA KEV data mirror repository
  7. CISA official KEV catalog
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.