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

Integer overflow in DevTools in Google Chrome prior to 149

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

This is a break-in that gets the attacker into the lobby, not the data center

CVE-2026-10965 is an integer overflow in Chrome's DevTools code that affects Google Chrome versions prior to 149.0.7827.53; Google's June 2, 2026 desktop release notes show fixes in 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and Mac. The public description says a remote attacker can trigger arbitrary code execution *inside a sandbox* via a crafted HTML page, which means the immediate win is code execution in a constrained browser process rather than direct operating-system compromise.

Google's HIGH 8.8 rating is technically fair if you score the memory corruption in isolation, but it overstates operational urgency for enterprise patch queues. The decisive friction is the sandbox boundary: without a second bug, the attacker does not get browser-level or host-level execution, and there is no current KEV listing, no public exploitation evidence, and only a very low reported EPSS signal.

"Real bug, real patch, but it lands code execution inside Chrome's sandbox, not on the host."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a malicious page

The attacker needs the target to render attacker-controlled HTML in vulnerable Chrome builds. In practice this is classic browser-bug delivery: phishing, malvertising, compromised sites, or a link dropped after initial access. The public advisory does not describe a zero-click trigger; user-driven browsing is implied by the CVSS UI:R vector.
Conditions required:
  • Victim is running Chrome older than 149.0.7827.53
  • Victim opens attacker-controlled or attacker-influenced web content
  • The vulnerable DevTools code path is reachable in that browsing context
Where this breaks in practice:
  • Email security, web filtering, Safe Browsing, and user behavior all cut into reachability
  • Public details do not confirm whether any extra DevTools-specific condition is needed, which adds uncertainty for weaponization
Detection/coverage: External vuln scanners will miss this; browser-version inventory from EDR, MDM, or enterprise browser management is the right coverage model.
STEP 02

Trigger the integer overflow

A crafted page hits the DevTools memory-corruption condition and yields code execution in the affected sandboxed process. Google has kept bug details restricted, so there is no public exploit chain or reliability data to show how brittle the primitive is across platforms. That matters because many Chrome memory bugs look scary on paper but are noisy or crash-prone in the field.
Conditions required:
  • A vulnerable build
  • A working trigger for the specific DevTools overflow
  • An exploitation path that survives allocator and compiler hardening
Where this breaks in practice:
  • No public PoC was found in primary sources
  • Restricted bug details slow copycat exploit development
  • Modern browser mitigations reduce exploit reliability
Detection/coverage: Behavioral detection is mostly crash telemetry and browser exploit detections in EDR; signature-based network detection is weak.
STEP 03

Gain execution inside Chrome's sandbox

Successful exploitation gets the attacker arbitrary code execution, but only inside Chrome's sandbox according to the CVE record. That can still matter for per-session data access, staging, or chaining, but it is not equivalent to workstation compromise. For most enterprise risk models, this is the main downgrade pressure.
Conditions required:
  • Step 2 succeeds
  • The sandbox remains the attacker's current execution boundary
Where this breaks in practice:
  • Chrome's sandbox meaningfully limits direct filesystem, device, and privileged OS access
  • Impact is closer to 'renderer/process compromise' than 'host takeover' absent a chain
Detection/coverage: EDR may see abnormal child-process, IPC, or crash patterns if the exploit is unstable; many successful in-sandbox actions remain quiet.
STEP 04

Chain a sandbox escape for real host impact

To turn this into the kind of enterprise incident that burns weekends, the attacker usually needs a second vulnerability or a separate post-exploitation path to escape the sandbox. That extra prerequisite compounds severity downward because it assumes either another fresh browser bug, a local privilege path, or a misconfigured endpoint control. The public CVE does not provide such a chain.
Conditions required:
  • A separate sandbox escape, broker abuse, or OS-level weakness
  • Ability to chain multiple exploit stages reliably on the victim platform
Where this breaks in practice:
  • Second-bug requirement sharply narrows real-world exploitability
  • EDR, ASR, and exploit protection are more likely to break the chain at this stage
Detection/coverage: This is where defenders usually get signal: process-spawn anomalies, injected code telemetry, exploit-protection events, or post-exploitation behavior.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence of active exploitation found in the reviewed sources as of 2026-06-05; not listed in CISA KEV.
Public PoC / exploit codeNo public PoC located in primary-source review. The Chromium issue exists but bug details are effectively restricted, which slows opportunistic weaponization.
EPSS0.0008 probability over 30 days from the user-provided intel, which is extremely low and consistent with a non-weaponized, non-KEV browser bug.
KEV statusNo; no CVE-2026-10965 entry was found in CISA's Known Exploited Vulnerabilities catalog search results.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — network-reachable and low-complexity on paper, but UI:R plus sandboxed impact are the real brakes.
Affected versionsChrome prior to 149.0.7827.53 per NVD. NVD's affected CPE analysis maps this to Chrome on Windows, macOS, and Linux.
Fixed versionsDesktop stable release on 2026-06-02: Linux 149.0.7827.53 and Windows/Mac 149.0.7827.53/54 according to Google's release post.
Disclosure / reportingVendor/NVD publication date: 2026-06-04. Google's release post says the issue was reported by Google on 2026-05-08.
Exposure / scanning realityInternet-wide sources like Shodan/Censys/FOFA are not useful here because this is a client browser issue, not a server-exposed service. Use endpoint inventory, EDR, MDM, or enterprise browser management to find exposure.
Root-cause contextMapped to CWE-472 External Control of Assumed-Immutable Web Parameter in the CVE record, but public technical detail is too sparse to validate exploit preconditions beyond the high-level description.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.6/10)

The single biggest severity reducer is that successful exploitation yields code execution inside Chrome's sandbox, not on the host. With no KEV listing, no public exploitation evidence, and no public chain to escape the sandbox, this is a browser memory bug you should patch through normal fleet hygiene rather than treat as an enterprise fire drill.

HIGH Affected/fixed version range and disclosure metadata
MEDIUM Exploitability reassessment under real-world conditions
LOW Whether any hidden DevTools-specific prerequisite materially narrows reachability further

Why this verdict

  • Vendor started at 8.8 HIGH; I cut it down because the published impact is sandboxed code execution, not host compromise
  • UI:R matters: this still needs the victim to hit attacker-controlled content, so it is not wormable or self-propagating inside the fleet
  • No active-exploitation signal: no KEV entry, no public PoC found, and the provided EPSS is extremely low
  • Second-stage requirement is the killer friction: meaningful workstation takeover usually needs a separate sandbox escape or local privilege path
  • Exposure population is broad but shallow: Chrome is everywhere, yet this is still a client-side browsing event, not an unauthenticated internet-facing server bug

Why not higher?

Because the public record explicitly stops at arbitrary code execution *inside a sandbox*. If you cannot cross the sandbox boundary with the same CVE, the blast radius is materially smaller than a browser-to-host RCE, and that matters more than the theoretical C:H/I:H/A:H values in the base vector.

Why not lower?

Because it is still a remote memory-corruption bug in the most widely deployed browser estate in most enterprises, and the trigger path is just web content. If an attacker later pairs it with a sandbox escape or if exploitation evidence appears, this would move up fast.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use enterprise browser policy, MDM, or software distribution to ensure Chrome moves to 149.0.7827.53+ on Linux and 149.0.7827.53/54+ on Windows/Mac. For a MEDIUM verdict there is no mitigation SLA, so keep this as normal fleet hygiene and complete actual patching within the 365-day remediation window.
  2. Block unmanaged Chrome versions from sensitive apps — Use conditional access, NAC posture checks, or app-proxy policy to deny risky browser builds access to high-value SaaS and admin portals. There is no mitigation SLA for MEDIUM, so this is optional risk reduction while patch rollout catches up rather than an emergency control.
  3. Tighten browser exploit guardrails — Verify Safe Browsing, site isolation defaults, exploit protection, ASR-style controls, and EDR browser hardening are enabled on managed endpoints. These do not fix the bug, but they raise attacker cost and buy resilience until patching is completed inside the 365-day remediation window.
  4. Inventory by version, not by installed-software name — Pull exact Chrome versions from EDR/MDM/browser management because traditional network vulnerability scanners have poor visibility into endpoint browser patch state. For this MEDIUM case, there is no mitigation SLA — go straight to the 365-day remediation window with accurate exposure data.
What doesn't work
  • A WAF does not help; this is not a server-side web app flaw and the exploit runs in the victim browser.
  • Perimeter scanning does not meaningfully surface exposure because Chrome is a client application, not an internet-facing service.
  • MFA is irrelevant to the exploit path; it may reduce downstream account abuse, but it does not stop memory corruption in the browser process.
  • Antivirus signatures alone are weak coverage when there is no public exploit sample and the trigger is a crafted webpage.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet agent/EDR remote shell. Invoke it with python3 chrome_cve_2026_10965_check.py; it needs only standard user rights and checks installed Chrome version across Windows, macOS, and Linux, then prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-10965 Chrome version check
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / Chrome not found / parse failure

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

TARGET = (149, 0, 7827, 53)
MAC_WIN_ALLOW_54 = (149, 0, 7827, 54)


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_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + '\n' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_windows_version():
    candidates = [
        os.path.expandvars(r'%ProgramFiles%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe'),
        os.path.expandvars(r'%LocalAppData%\Google\Chrome\Application\chrome.exe'),
    ]
    for path in candidates:
        if path and os.path.exists(path):
            out = run_cmd(['powershell', '-NoProfile', '-Command', f"(Get-Item '{path}').VersionInfo.ProductVersion"])
            v = parse_version(out)
            if v:
                return v, path
    return None, None


def get_macos_version():
    path = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
    if os.path.exists(path):
        out = run_cmd([path, '--version'])
        v = parse_version(out)
        if v:
            return v, path
    return None, None


def get_linux_version():
    candidates = ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']
    for name in candidates:
        exe = shutil.which(name)
        if exe:
            out = run_cmd([exe, '--version'])
            v = parse_version(out)
            if v:
                return v, exe
    return None, None


def compare(v1, v2):
    return (v1 > v2) - (v1 < v2)


def main():
    system = platform.system().lower()
    version = None
    path = None

    if 'windows' in system:
        version, path = get_windows_version()
    elif 'darwin' in system:
        version, path = get_macos_version()
    elif 'linux' in system:
        version, path = get_linux_version()
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

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

    # Public advisory states patched at 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows/Mac.
    # Treat any version >= 149.0.7827.53 as patched across platforms.
    if compare(version, TARGET) >= 0:
        print(f'PATCHED: {version[0]}.{version[1]}.{version[2]}.{version[3]} ({path})')
        sys.exit(0)
    else:
        print(f'VULNERABLE: {version[0]}.{version[1]}.{version[2]}.{version[3]} ({path})')
        sys.exit(1)


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

If you remember one thing.

TL;DR
Monday morning: pull a clean inventory of Chrome versions from EDR/MDM/browser management, confirm who is still below 149.0.7827.53, and roll them into your normal browser update motion. Because this reassessment lands at MEDIUM and there is no active exploitation evidence, there is noisgate mitigation SLA — go straight to the 365-day remediation window; under the noisgate remediation SLA, have the actual Chrome update applied within 365 days, though most enterprises should simply let standard browser auto-update rings absorb it well before then.

Sources

  1. NVD CVE-2026-10965
  2. Google Chrome Stable Channel Update for Desktop (June 2, 2026)
  3. Chromium issue 511290038
  4. FIRST EPSS overview
  5. CISA Known Exploited Vulnerabilities Catalog
  6. CWE-472 definition
  7. Chrome Releases stable-updates listing
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.