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

Integer overflow in V8 in Google Chrome prior to 149

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

This is a burglar getting into the building lobby, not the server room

CVE-2026-10964 is an integer overflow in Chrome's V8 JavaScript engine affecting Google Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/54 on Windows and macOS. A victim must be lured to attacker-controlled web content, after which the attacker can achieve arbitrary code execution inside the browser sandbox via crafted HTML/JavaScript.

paragraph 2: Google's HIGH label is understandable if you score the memory corruption in isolation, but it overstates enterprise impact. The decisive real-world friction is that successful exploitation lands in a sandboxed renderer, not on the host, so meaningful workstation compromise usually still needs a second bug or a separate post-exploit path; combine that with required user interaction, no KEV entry, and a very low EPSS, and this grades down to a solid MEDIUM for patch-priority purposes.

"Remote bug, yes; enterprise emergency, no. The sandbox boundary is the whole story here."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver malicious web content

The attacker hosts or injects a crafted HTML/JavaScript payload and gets a user to load it in Chrome. The practical weapon here is just a malicious site or malvertising redirect; there is no evidence of a public turnkey exploit kit for this CVE in the sources reviewed.
Conditions required:
  • Victim runs Chrome older than 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced content
  • JavaScript execution is permitted
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Email filtering, DNS filtering, Safe Browsing, and ad-blocking reduce delivery success
  • Enterprise browser isolation or remote rendering can break the chain before exploit delivery
Detection/coverage: Network scanners will not see this; detection is mostly via web filtering, browser telemetry, and crash/EDR analytics. Vulnerability scanners can identify outdated Chrome versions, but not exploit attempts reliably.
STEP 02

Trigger V8 integer overflow

Once the page executes, the attacker abuses the V8 integer overflow to corrupt execution state in the renderer process. The likely weapon is a custom JavaScript exploit chain tuned to the exact Chrome/V8 build; browser memory corruption exploits are usually version-fragile and crash-prone until tuned.
Conditions required:
  • Exploit must match the vulnerable V8 build closely
  • Victim browser protections must not block the triggering script
Where this breaks in practice:
  • No public PoC or exploit repo surfaced in the sources reviewed
  • Modern mitigations in Chrome make reliable exploitation harder than the AC:L label suggests operationally
  • Exploit reliability usually drops across OS, patch, and hardware variations
Detection/coverage: You may see renderer crashes, unusual child-process behavior, or browser instability in EDR/Crashpad telemetry. Signature-based detection coverage is typically weak until a public exploit exists.
STEP 03

Gain code execution in the sandboxed renderer

The published impact is arbitrary code execution inside the sandbox, meaning code runs in a constrained renderer context rather than with normal user privileges on the host. At this stage the attacker can potentially interact with in-process data and origin-scoped web content, but not freely execute on the workstation.
Conditions required:
  • Successful memory corruption exploit in the renderer
  • Chrome sandbox remains the security boundary
Where this breaks in practice:
  • The sandbox sharply limits blast radius
  • Host-level persistence or broad lateral-movement actions are blocked without another weakness or user-assisted escape path
  • Enterprise EDR often catches unusual child process, file, or token behavior if the actor tries to leave the sandbox
Detection/coverage: Host scanners generally cannot prove renderer-level compromise after the fact. Browser sandboxing means many post-exploit actions simply fail, which is a form of built-in containment rather than visibility.
STEP 04

Attempt post-sandbox impact

To turn this into a true workstation compromise, the attacker normally needs a sandbox escape, browser-to-OS broker abuse, credential theft path, or some separate social-engineering step. That missing second leg is why this is not a patch-now emergency on the same level as an unauthenticated server RCE or a known-exploited browser sandbox escape.
Conditions required:
  • Attacker has a second exploit, misconfiguration, or alternate abuse path
  • Target environment lacks layered browser containment
Where this breaks in practice:
  • No active exploitation evidence in KEV or vendor advisory
  • No public second-stage chain tied to this CVE was found
  • Most enterprises can tolerate the residual risk briefly while normal browser updating catches up
Detection/coverage: If the actor gets beyond the sandbox, normal EDR, proxy, DLP, and identity detections re-enter the picture. Without that second stage, impact often remains local to the renderer process.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence of active exploitation was found in the reviewed sources. Not listed in CISA KEV, and Google's release post does not flag exploitation.
Public exploit / PoCNo public PoC, Metasploit module, or Exploit-DB entry surfaced for CVE-2026-10964 in the reviewed sources. Treat exploit availability as not publicly confirmed.
EPSSUser-supplied EPSS is 0.0008, which is very low and aligns with the current absence of exploitation reporting. Percentile was not authoritatively confirmed from accessible FIRST output during this assessment.
KEV statusNo KEV listing found on the CISA catalog page reviewed for this assessment; therefore no CISA due date applies.
CVSS vector meaningCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H translates to remote reachability with no prior auth, but the exploit still needs user interaction and the published description says code execution is inside the sandbox.
Affected versionsChrome prior to 149.0.7827.53. Vendor release notes specify 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later on Linux, and 149.0.7827.54 or later on Windows/macOS where that build is offered. For Chromium-derived browsers, consume the equivalent vendor backport/update once available.
Exposure realityThis is a client-side browser bug, not an internet-facing service. Shodan/Censys-style internet exposure counts are not meaningful; exposure maps to your installed browser fleet and how often users browse untrusted content.
Disclosure / patch dateChrome stable release published 2026-06-02; NVD published the CVE on 2026-06-04 and NVD shows last modification on 2026-06-05.
ReporterGoogle's release notes attribute this issue to Google, reported on 2026-05-08, not an external researcher.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The single biggest severity reducer is that the advertised code execution stays inside Chrome's sandbox, which sharply limits immediate host impact. This is a broad-exposure browser bug, but without a sandbox escape, KEV listing, or active exploitation evidence, it does not justify HIGH-priority treatment over server-side RCEs or browser escapes.

HIGH Affected version range and fixed builds
HIGH Sandboxed-impact interpretation from vendor/NVD wording
MEDIUM Absence of public exploit evidence in reviewed sources

Why this verdict

  • Down from vendor 8.8: the published impact is renderer code execution *inside the sandbox*, not direct workstation compromise.
  • User interaction required: the attacker needs the victim to load malicious content, which makes delivery materially less reliable in managed enterprise fleets.
  • No exploitation heat: no KEV entry, no reviewed source indicating in-the-wild abuse, and a very low user-supplied EPSS all push this below emergency patch status.
  • Wide product deployment is the main upward pressure: Chrome is everywhere, so even a sandboxed bug still deserves cleanup through standard browser update governance.

Why not higher?

If this were a demonstrated sandbox escape, a full browser-to-OS chain, or KEV-listed with live exploitation, it would jump fast. But the current public description stops at sandboxed execution, and that boundary matters more than the raw memory-corruption label.

Why not lower?

This is still remotely triggerable through everyday browsing with no authentication barrier, and Chrome's installed base is massive. Browser memory corruption bugs also have a history of being chained, so dismissing it as LOW would understate the residual risk.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure enterprise policy is not delaying Stable-channel uptake and that endpoints actually converge on 149.0.7827.53/54+. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browsers should be closed out in the next normal endpoint update cycle, not left to drift.
  2. Tighten risky web-content exposure — Use DNS/web filtering, Safe Browsing enforcement, ad/malvertising controls, and category blocks to cut off the easiest delivery path. This reduces exploit reach immediately while patch adoption completes; for MEDIUM, there is no separate mitigation SLA, so use this as a hygiene control rather than a crisis response.
  3. Prefer browser isolation for high-risk users — Put admins, finance, executives, and research users behind remote browser isolation or equivalent hardened browsing paths where available. That turns a renderer exploit into someone else's containment problem while your standard remediation cycle cleans up the fleet.
  4. Hunt for update laggards — Query EDR, software inventory, or MDM for Chrome versions below the fixed build and focus on non-persistent VDI, kiosk, lab, and off-VPN laptops that commonly miss browser updates. On a 10,000-host estate, the long tail is your real risk multiplier.
What doesn't work
  • Perimeter vulnerability scanning doesn't help much here because Chrome is a client application, not a listening network service.
  • Relying on MFA doesn't meaningfully reduce exploitability; this chain starts with web content execution, not account takeover.
  • Traditional WAF controls are irrelevant unless you happen to control the delivery site; the vulnerable surface is the browser engine on the endpoint.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR scripting channel. Invoke with python3 check_chrome_cve_2026_10964.py; no admin rights are usually needed, though Windows registry access to machine-wide installs works best in a normal user session with local read access.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_10964.py
# Determine whether local Google Chrome is vulnerable to CVE-2026-10964
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import subprocess
import sys
import re

TARGET = (149, 0, 7827, 53)


def parse_version(s):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s 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 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 check_linux():
    candidates = [
        ['google-chrome', '--product-version'],
        ['google-chrome-stable', '--product-version'],
        ['chromium', '--product-version'],
        ['chromium-browser', '--product-version'],
    ]
    for cmd in candidates:
        v = get_version_from_command(cmd)
        if v:
            return v, 'command:' + ' '.join(cmd)
    return None, None


def check_macos():
    plist = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist):
        v = get_version_from_command(['/usr/bin/defaults', 'read', plist.replace('/Contents/Info.plist', ''), 'KSVersion'])
        if not v:
            v = get_version_from_command(['/usr/bin/defaults', 'read', plist, 'CFBundleShortVersionString'])
        if v:
            return v, plist
    alt = os.path.expanduser('~/Applications/Google Chrome.app/Contents/Info.plist')
    if os.path.exists(alt):
        v = get_version_from_command(['/usr/bin/defaults', 'read', alt.replace('/Contents/Info.plist', ''), 'KSVersion'])
        if not v:
            v = get_version_from_command(['/usr/bin/defaults', 'read', alt, 'CFBundleShortVersionString'])
        if v:
            return v, alt
    return None, None


def check_windows():
    try:
        import winreg
    except Exception:
        return None, 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:
            with winreg.OpenKey(hive, path) as key:
                value, _ = winreg.QueryValueEx(key, name)
                v = parse_version(str(value))
                if v:
                    return v, 'registry:' + path
        except Exception:
            pass

    file_candidates = [
        os.path.join(os.environ.get('ProgramFiles', r'C:\Program Files'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('ProgramFiles(x86)', r'C:\Program Files (x86)'), 'Google', 'Chrome', 'Application', 'chrome.exe'),
        os.path.join(os.environ.get('LOCALAPPDATA', ''), 'Google', 'Chrome', 'Application', 'chrome.exe'),
    ]
    for exe in file_candidates:
        if os.path.exists(exe):
            v = get_version_from_command(['powershell', '-NoProfile', '-Command', f"(Get-Item '{exe}').VersionInfo.ProductVersion"])
            if v:
                return v, exe
    return None, None


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

    if 'linux' in system:
        version, source = check_linux()
    elif 'darwin' in system:
        version, source = check_macos()
    elif 'windows' in system:
        version, source = check_windows()
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

    if not version:
        print('UNKNOWN: could not determine Chrome version')
        sys.exit(2)

    if cmp_version(version, TARGET) < 0:
        print(f'VULNERABLE: detected Chrome version {".".join(map(str, version))} from {source}; fixed version is {".".join(map(str, TARGET))} or later')
        sys.exit(1)
    else:
        print(f'PATCHED: detected Chrome version {".".join(map(str, version))} from {source}; meets or exceeds {".".join(map(str, TARGET))}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a fleet hygiene browser update, not an incident-response fire drill. Because the reassessed rating is MEDIUM and there is no KEV or active exploitation evidence in the reviewed sources, there is noisgate mitigation SLA here — no mitigation SLA — go straight to the 365-day remediation window — but don't let that become complacency: verify auto-update is working, identify endpoints below 149.0.7827.53/54, and close the long tail through your normal browser servicing motion well before the noisgate remediation SLA deadline of 365 days.

Sources

  1. NVD record for CVE-2026-10964
  2. Chrome Releases: Stable Channel Update for Desktop (2026-06-02)
  3. Chromium issue tracker entry 511228272
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS model documentation
  6. FIRST EPSS API documentation
  7. Chromium Security page
  8. CVE.org record
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.