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

Stack buffer overflow in GPU in Google Chrome prior to 149

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

This is a locked interior door, not the front gate

CVE-2026-10898 is a stack buffer overflow in Chrome's GPU component affecting versions before 149.0.7827.53. Per the official CVE record, exploitation requires an attacker to have already compromised the renderer process, then use a crafted HTML page to try to turn that foothold into a sandbox escape. In plain English: this is not the bug that gets the attacker into the browser; it is the bug that may let them climb out of the browser sandbox after they are already in.

The vendor-side severity story is inflated for fleet triage if you read it like an initial-access bug. Yes, the technical impact is ugly if chained successfully, but the gating condition is everything: renderer compromise is a prior stage, which means this CVE is mostly valuable to attackers who already have a separate browser bug or equivalent foothold. With no KEV listing, no public exploitation evidence, and a tiny EPSS, this lands as a downshift from vendor HIGH to operational MEDIUM for enterprise patch scheduling.

"Serious only as the second half of an exploit chain; alone, this is not a Monday-morning fire drill."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker needs a separate bug or exploit chain that gains control of Chrome's renderer process. Typical tooling here is a malicious site, exploit kit, or ad-tech delivery path weaponizing a distinct renderer-facing memory corruption bug. CVE-2026-10898 does not provide this step by itself; it assumes the renderer is already compromised.
Conditions required:
  • User browses attacker-controlled or attacker-influenced content
  • Attacker has a separate renderer compromise primitive
  • Chrome version is below 149.0.7827.53
Where this breaks in practice:
  • This is a post-initial-browser-compromise prerequisite
  • Modern site isolation, Safe Browsing, and exploit mitigations reduce reliable renderer compromise
  • No public exploit chain is available tying this CVE to a known renderer bug
Detection/coverage: Standard vulnerability scanners will flag version exposure, but they cannot validate the presence of the required first-stage renderer exploit. EDR/browser telemetry may catch the precursor crash or exploit behavior, not this CVE in isolation.
STEP 02

Pivot from renderer into GPU attack surface

With renderer execution established, the attacker drives crafted HTML and graphics-related operations toward the GPU process/component to trigger the stack overflow. The practical weapon here is the browser's own rendering pipeline, not an external service. This is the point where the bug becomes relevant as a sandbox-escape primitive.
Conditions required:
  • Renderer can reliably invoke the vulnerable GPU code path
  • Target build includes the vulnerable GPU implementation
  • Exploit reliability survives platform-specific graphics differences
Where this breaks in practice:
  • GPU paths are notoriously platform- and driver-sensitive
  • Attack complexity is rated High in the CVSS vector
  • Exploit developers must line up memory layout and process boundaries cleanly enough to escape
Detection/coverage: Crash telemetry, Chrome stability reports, and EDR detections for abnormal child-process/browser behavior are more realistic than network scanning. Bug details remain restricted, which also limits defender-specific detections.
STEP 03

Convert memory corruption into sandbox escape

If the overflow is controllable enough, the attacker attempts to move from compromised renderer context to a less-restricted process boundary, achieving a sandbox escape. Tooling at this stage is custom exploit logic; there is no public PoC. Successful exploitation changes the story from browser-contained compromise to host-level follow-on activity potential.
Conditions required:
  • Overflow is exploitable beyond crash-only behavior
  • Target endpoint lacks effective behavior-based detection on the post-escape actions
  • Attacker can maintain chain reliability across endpoint variants
Where this breaks in practice:
  • No public evidence yet that this bug is weaponized in the wild
  • Stack overflows can be less forgiving than simpler logic bugs for stable exploitation
  • Post-escape actions still face EDR, application control, and user-context limits
Detection/coverage: There is usually no direct scanner signature for successful sandbox escape. Detection shifts to EDR behavioral analytics, suspicious process spawning, token abuse, and abnormal browser child-process events.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found and not KEV-listed as of 2026-06-05. That matters more than the scary bug class.
PoC availabilityNo public PoC or exploit repo found. The Chromium issue remains restricted, which is normal for fresh browser memory-corruption bugs.
EPSS0.00062 from the user-supplied intel block — extremely low predicted exploitation probability relative to internet-priority bugs.
KEV statusNo. No CISA KEV entry located for this CVE, so there is no authoritative in-the-wild exploitation signal pushing this upward.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H — the killer caveat is AC:H + UI:R + prior renderer compromise implied by the advisory text.
Affected versionsGoogle Chrome before 149.0.7827.53. The official CVE JSON expresses this as versions < 149.0.7827.53.
Fixed versionsChrome 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows and Mac per Google's stable update post.
Exposure realityThis is a client-side browser bug, so Shodan/Censys-style internet exposure counts are basically irrelevant. Your real exposed population is every managed endpoint running vulnerable Chrome, not a listening service.
Disclosure and reportingCVE record published 2026-06-04; Google release post dated 2026-06-02; issue reported by Google on 2026-05-17.
Vendor severity mismatchGoogle's release notes label it Chromium security severity: Critical, while the CISA ADP CVSS in the CVE record is 8.3 / High. For defenders, both overstate urgency unless you ignore the renderer-compromise prerequisite.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

The decisive factor is that this bug requires a prior renderer compromise, which makes it a second-stage browser escape, not an initial-access vulnerability. That sharply reduces the reachable population of attackers and incidents where this CVE alone changes your enterprise risk on Monday morning.

HIGH Requirement for prior renderer compromise materially lowers operational severity
MEDIUM No public exploitation or PoC at time of assessment
MEDIUM Exploitability across heterogeneous GPU/driver stacks is likely inconsistent

Why this verdict

  • Downward adjustment: requires prior renderer compromise — that means the attacker is already partway through a browser exploit chain before this CVE matters.
  • Downward adjustment: client-side + UI required — exploitation still depends on victim interaction with crafted content, not a wormable exposed service.
  • Downward adjustment: AC:H and no live abuse signal — high complexity plus no KEV and no public weaponization keeps this out of top-tier patch panic.
  • Upward adjustment: Chrome is everywhere — even second-stage browser escapes matter because endpoint population is huge and successful impact is full sandbox break.

Why not higher?

This is not a clean unauthenticated remote initial-access bug. The advisory itself says the attacker must have already compromised the renderer process, which is a major chain dependency and a strong real-world severity brake. Add no KEV, no public exploit, and a very low EPSS, and there is no evidence-based case for HIGH or CRITICAL fleet urgency.

Why not lower?

A browser sandbox escape is still strategically important because it can turn a renderer foothold into meaningful host compromise. Chrome is ubiquitous in enterprise fleets, and if this bug gets paired with a renderer exploit later, the impact is serious enough that you should not bury it as backlog trivia.

05 · Compensating Control

What to do — in priority order.

  1. Force auto-update compliance — Use your browser management stack to verify Chrome channels are updating and pin stragglers for correction. For a MEDIUM verdict there is no mitigation SLA, but this is still the fastest risk reducer before the noisgate remediation SLA of ≤ 365 days.
  2. Shrink risky browsing surfaces — Apply stricter policy to unmanaged extensions, high-risk web categories, and unnecessary GPU-accelerated browser use cases on sensitive admin endpoints. This reduces the chance of the first-stage renderer compromise that this CVE depends on; with MEDIUM there is no mitigation SLA, so use this where operationally cheap while patching inside the 365-day window.
  3. Harden privileged workstations — Prioritize fast browser updates on administrator, developer, and help-desk endpoints where a sandbox escape has outsized blast radius. Even without a mitigation SLA, these systems deserve earlier attention because the post-escape payoff is higher.
  4. Watch for browser exploit precursors — Tune EDR and crash telemetry for repeated Chrome renderer/GPU crashes, suspicious browser child-process behavior, and anomalous post-browser execution. That will catch the chain around this CVE better than network scanners will, and can be deployed during the remediation window.
What doesn't work
  • A perimeter firewall does not meaningfully help; this is a client-side browser bug triggered by user web activity, not an exposed inbound service.
  • Credential controls like MFA do not stop exploitation of a browser memory-corruption chain; they matter after compromise, not at trigger time.
  • Vulnerability internet scanners are poor coverage here because Chrome on endpoints is not meaningfully measurable through Shodan-style exposure checks.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/remote shell on representative hosts. Invoke it as python3 check_chrome_cve_2026_10898.py on macOS/Linux or py check_chrome_cve_2026_10898.py on Windows; no admin rights are required unless your environment blocks access to program files.

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

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

THRESHOLD = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_version(a, b):
    return (a > b) - (a < b)


def run_version_command(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=5)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out.strip())
    except Exception:
        return None


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

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        prog = os.environ.get('PROGRAMFILES', '')
        progx86 = os.environ.get('PROGRAMFILES(X86)', '')
        candidates = [
            Path(local) / 'Google/Chrome/Application/chrome.exe',
            Path(prog) / 'Google/Chrome/Application/chrome.exe',
            Path(progx86) / 'Google/Chrome/Application/chrome.exe',
            Path(local) / 'Chromium/Application/chrome.exe',
            Path(prog) / 'Chromium/Application/chrome.exe',
            Path(progx86) / 'Chromium/Application/chrome.exe',
        ]
        for c in candidates:
            if str(c).strip() and c.exists():
                cmds.append([str(c), '--version'])
        cmds.extend([
            ['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'],
            ['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'],
            ['reg', 'query', r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon', '/v', 'version'],
        ])
    elif system == 'darwin':
        candidates = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
        ]
        for c in candidates:
            if os.path.exists(c):
                cmds.append([c, '--version'])
        cmds.extend([
            ['google-chrome', '--version'],
            ['chromium', '--version'],
            ['chromium-browser', '--version'],
        ])
    else:
        cmds.extend([
            ['google-chrome', '--version'],
            ['google-chrome-stable', '--version'],
            ['chromium', '--version'],
            ['chromium-browser', '--version'],
            ['/opt/google/chrome/chrome', '--version'],
            ['/usr/bin/google-chrome', '--version'],
            ['/usr/bin/chromium', '--version'],
            ['/usr/bin/chromium-browser', '--version'],
        ])

    return cmds


def main():
    found = []
    for cmd in candidate_commands():
        ver = run_version_command(cmd)
        if ver:
            found.append((cmd[0], ver))

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

    # Use the highest detected version if multiple installs exist.
    path, ver = sorted(found, key=lambda x: x[1], reverse=True)[0]
    ver_str = '.'.join(str(x) for x in ver)
    threshold_str = '.'.join(str(x) for x in THRESHOLD)

    if cmp_version(ver, THRESHOLD) < 0:
        print(f'VULNERABLE - detected {ver_str} at {path}; requires >= {threshold_str}')
        sys.exit(1)
    else:
        print(f'PATCHED - detected {ver_str} at {path}; threshold is {threshold_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet-wide browser hygiene item, not an emergency outage change. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for a MEDIUM verdict, but in practice you should validate Chrome auto-update health now, identify endpoints still below 149.0.7827.53, and close them through your normal browser update motion well before the noisgate remediation SLA of ≤ 365 days; prioritize privileged/admin workstations and any users with elevated browsing risk first.

Sources

  1. Official CVE JSON record for CVE-2026-10898
  2. Google Chrome stable channel update for Desktop (June 2, 2026)
  3. Chromium issue 513946753
  4. Chromium security page
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS model documentation
  7. Chrome early stable update for Desktop 149.0.7827.53/.54
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.