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

Heap buffer overflow in TabStrip in Google Chrome prior to 149

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

This is a bad lock on an interior door, not an open front gate

CVE-2026-10995 is a heap buffer overflow in Chrome's TabStrip UI component affecting Google Chrome versions earlier than 149.0.7827.53. The bug is triggered from a crafted HTML page, but the attacker also has to get the victim to perform *specific UI gestures* while interacting with the browser. That is materially different from the classic no-click renderer bug: this sits in a UI path, not a broadly reachable network service, and its preconditions narrow the real-world hit rate.

The supplied 8.8/HIGH baseline overstates operational risk for enterprise patch triage. Google's own June 2, 2026 stable release groups CVE-2026-10995 as Medium, and that tracks reality better: there is no KEV listing, EPSS is extremely low, no public exploit chain is visible, and the attack needs both page delivery and human choreography. Still, it is a memory corruption bug in the most widely deployed browser on most fleets, so this is not backlog trash.

"Memory corruption is real, but the exact-gesture requirement keeps this out of the urgent queue"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a lure page

The attacker needs a crafted HTML page that exercises the vulnerable TabStrip code path. In practice this means a phishing link, malvertising redirect, or compromised site rather than a blind network probe. There is no internet-exposed daemon here; reachability is entirely mediated by user browsing.
Conditions required:
  • Target is running Google Chrome earlier than 149.0.7827.53
  • Victim can be induced to open attacker-controlled web content
  • Chrome is allowed for general web access on the endpoint
Where this breaks in practice:
  • Email security, SWG, DNS filtering, and Safe Browsing can block the lure before the browser ever sees it
  • This is a client-side browser flaw, so mass scanner discovery is not practical
Detection/coverage: Traditional vuln scanners can usually detect version exposure, but not exploitability. Network scanners like Shodan/Censys/GreyNoise have little value here because the asset is a browser, not an exposed service.
STEP 02

Force exact UI interaction

The published description says the victim must be convinced to engage in *specific UI gestures*. That usually means the exploit needs more than a page load: tab movement, drag/drop, hover timing, clicks in a narrow sequence, or similar choreography against browser chrome. This is the biggest severity suppressor in the chain because it pushes the bug from 'drive-by' toward 'socially engineered, low-reliability execution path.'
Conditions required:
  • Victim performs the required UI gestures in the attacker-chosen sequence
  • The browser window and tab state line up with the exploit assumptions
Where this breaks in practice:
  • Users do not naturally reproduce precise gesture chains at scale
  • Security awareness, browser isolation, and user friction reduce completion rates
  • UI-path bugs are often timing-sensitive and brittle across platforms and window states
Detection/coverage: EDR is unlikely to flag the trigger itself unless it progresses to a crash or suspicious child behavior. Browser crash telemetry and SOC correlation on unusual Chrome fault spikes are more realistic than signature-based exploit detection.
STEP 03

Corrupt heap state in the browser

If the choreography works, the attacker gets heap corruption inside the browser process via the TabStrip overflow. That can yield a crash, info leak, or controlled memory primitive depending on allocator state and exploit quality. No public weaponized exploit is visible, so assume reliability is non-trivial rather than turnkey.
Conditions required:
  • Memory layout is favorable on the target platform
  • The crafted content successfully grooms heap state
Where this breaks in practice:
  • Modern Chrome mitigations, allocator randomness, and exploit hardening reduce reliability
  • A memory corruption primitive in a UI component is usually harder to stabilize than a simple logic flaw
Detection/coverage: Crash dumps, Windows Event Logs, macOS crash reports, Linux coredumps, and browser telemetry may show failures. Endpoint tools can also surface repeated chrome crashes around the same URL or campaign.
STEP 04

Convert browser corruption into useful impact

The best-case attacker outcome is code execution or meaningful browser-process control, but that is still not equivalent to full host compromise. Chrome sandboxing, integrity boundaries, and the absence of a paired sandbox escape sharply cap blast radius from this CVE alone. In enterprise terms, this bug is one stage in a chain, not the whole intrusion.
Conditions required:
  • Attacker turns corruption into a stable primitive
  • Any desired post-browser objective is reachable without an additional escape
Where this breaks in practice:
  • Sandbox boundaries may limit direct host impact
  • Most serious host takeover outcomes would require a second vulnerability or weak local controls
Detection/coverage: If exploitation progresses, EDR may catch abnormal chrome process behavior, shellcode-like memory patterns, or unexpected child process/network activity. Absent that, defenders mainly see crashes or nothing.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo current exploitation evidence located. Not in CISA KEV and no public campaign reporting found in the reviewed sources. See CISA KEV catalog and OpenCVE.
Proof-of-concept availabilityNo public PoC seen. The Chromium issue exists at 505371980 but is restricted, and no public exploit references appeared in the vendor release or reviewed sources.
EPSS0.00032 per the CVE metadata surfaced by OpenCVE, which is effectively noise-floor threat probability.
KEV statusNot listed in CISA's Known Exploited Vulnerabilities Catalog as of the CVE's June 2026 disclosure.
CVSS / severity mismatchImportant mismatch: your supplied baseline is 8.8/HIGH, but Google's June 2, 2026 release note lists CVE-2026-10995 as Medium in the 149 stable train: Chrome stable 149 release.
Affected versionsGoogle Chrome < 149.0.7827.53 on desktop platforms. OpenCVE shows the affected range as 0,149.0.7827.53): [OpenCVE record.
Fixed versionPatched in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac per the Chrome 149 stable release.
Exposure realityHuge installed base, poor external measurability. Chrome still dominates browser usage globally, around 70.25% overall in StatCounter's May 2026 data, but internet scanners cannot directly enumerate vulnerable browser clients: StatCounter.
Disclosure / reportingDisclosed 2026-06-04; reported by Sven Dysthe (@svn-dys) on 2026-04-22 per OpenCVE and the Chrome stable release note.
Why it is not higherTwo compounding brakes: UI:R is already a reduction, and '*specific UI gestures*' is a second, stronger reduction because it implies a brittle, socially engineered exploit path instead of simple page-load reachability.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.9/10)

The decisive factor is the specific UI gesture requirement. That prerequisite turns a theoretically nasty memory corruption bug into a far narrower, low-reliability, post-click attack path with no observed exploitation signal behind it today.

HIGH Affected version and fix version mapping
MEDIUM Operational exploitability assessment
MEDIUM Public exploit availability assessment

Why this verdict

  • Down from 8.8 because this is not a no-click browser bug — the victim must browse attacker content *and* perform specific UI gestures, which is more restrictive than ordinary UI:R web exploitation.
  • Down again because the attacker position is still pre-compromise internet delivery, but the reachable population for the vulnerable code path is narrower than Chrome's raw install base; many users will see the page, few will reproduce the exact gesture chain.
  • Down again because there is no exploitation signal — no KEV listing, very low EPSS (0.00032), and no public PoC or campaign reporting in the reviewed sources.
  • Kept at MEDIUM instead of LOW because Chrome is everywhere and heap corruption bugs can still become valuable when paired with social engineering or a second-stage escape.

Why not higher?

A higher rating would fit a renderer bug with page-load-only reachability, a public exploit, or active exploitation. We do not have any of those here. The required UI choreography and likely exploit brittleness are real-world friction points that sharply reduce both attacker success rate and enterprise-wide urgency.

Why not lower?

This is still memory corruption in the dominant browser on enterprise endpoints, not a cosmetic UI issue. If the gesture chain is met, the bug plausibly enables meaningful browser-process compromise, so dismissing it as hygiene would be too optimistic. Chrome's prevalence keeps the population size large even when exploitability is constrained.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser version compliance — Use MDM, EDR, or software inventory to flag any host running Chrome < 149.0.7827.53 and block drift from auto-update rings. Because this is MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window, but mature shops should close browser lag much sooner as normal endpoint hygiene.
  2. Keep Safe Browsing and web filtering on — This bug still needs malicious content delivery, so URL filtering, DNS controls, SWG, and Chrome Safe Browsing reduce attacker access to the trigger page. For this verdict there is no mitigation SLA, so treat this as standing control hardening while you complete remediation inside the 365-day window.
  3. Isolate high-risk browsing roles — Apply browser isolation or hardened browsing profiles for executives, admins, help desk, finance, and users who live in webmail or unknown links. That does not eliminate the bug, but it materially lowers the chance that precise gesture-based exploitation succeeds before remediation.
  4. Watch for Chrome crash clusters — Pull browser crash telemetry and EDR fault events for repeated chrome crashes after 2026-06-04, especially around phishing campaigns or uncommon domains. Repeated tab/UI crashes can be your only early hint that someone is trying to exercise this path.
What doesn't work
  • A perimeter vulnerability scan won't tell you much beyond browser version presence; this is a client-side flaw, not an exposed TCP service.
  • Firewall rules do not meaningfully mitigate a browser bug delivered over ordinary web traffic users already need.
  • MFA is good security, but it does not stop the memory corruption step; it only helps if the attacker later pivots into account abuse.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet-management agent. Invoke it with python3 chrome_cve_2026_10995_check.py on macOS/Linux or py chrome_cve_2026_10995_check.py on Windows; no admin rights are required if the script can read the Chrome executable version metadata from standard install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-10995 Google Chrome version check
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from shutil import which

TARGET = (149, 0, 7827, 53)


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


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


def get_version_from_command(cmd):
    try:
        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True, timeout=10)
        return parse_version(out.strip())
    except Exception:
        return None


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


def get_macos_version():
    candidates = [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),
    ]
    for app in candidates:
        if os.path.exists(app):
            v = get_version_from_command([app, "--version"])
            if v:
                return v, app
    return None, None


def get_windows_version():
    try:
        import winreg
    except Exception:
        winreg = None

    # Try registry first
    if winreg is not None:
        reg_paths = [
            (winreg.HKEY_CURRENT_USER, r"Software\Google\Chrome\BLBeacon", "version"),
            (winreg.HKEY_LOCAL_MACHINE, r"Software\Google\Chrome\BLBeacon", "version"),
            (winreg.HKEY_LOCAL_MACHINE, r"Software\WOW6432Node\Google\Chrome\BLBeacon", "version"),
        ]
        for hive, path, name in reg_paths:
            try:
                key = winreg.OpenKey(hive, path)
                value, _ = winreg.QueryValueEx(key, name)
                v = parse_version(str(value))
                if v:
                    return v, f"registry:{path}"
            except Exception:
                pass

    # Fallback to executable version via PowerShell
    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 exe in candidates:
        if exe and os.path.exists(exe):
            ps = [
                "powershell",
                "-NoProfile",
                "-Command",
                f"(Get-Item '{exe}').VersionInfo.ProductVersion"
            ]
            v = get_version_from_command(ps)
            if v:
                return v, exe
    return None, None


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

    if system == "windows":
        version, source = get_windows_version()
    elif system == "darwin":
        version, source = get_macos_version()
    else:
        version, source = get_linux_version()

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

    if cmp_ver(version, TARGET) < 0:
        print(f"VULNERABLE - found {'.'.join(map(str, version))} via {source}; need >= {'.'.join(map(str, TARGET))}")
        sys.exit(1)
    else:
        print(f"PATCHED - found {'.'.join(map(str, version))} via {source}; fixed version is >= {'.'.join(map(str, TARGET))}")
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a zero-day fire drill. Validate where Chrome auto-update is lagging, use standard endpoint tooling to identify any Chrome < 149.0.7827.53, and keep your normal web controls in place; for a MEDIUM finding there is noisgate mitigation SLAno mitigation SLA — go straight to the 365-day remediation window. Your noisgate remediation SLA is ≤365 days, but because this is a browser and the patch already exists, most enterprises should simply let normal browser update rings clear it well before that outer limit and confirm stragglers in unmanaged or kiosk populations.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (Chrome 149)
  2. OpenCVE record for CVE-2026-10995
  3. Chromium issue 505371980
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. StatCounter browser market share worldwide
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.