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

Use after free in V8 in Google Chrome prior to 149

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

This is a loaded trapdoor on a public sidewalk, but the victim still has to step on the marked tile

This Chrome bug is described as a use-after-free in V8 affecting Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows and macOS. In plain English: a malicious page can try to corrupt memory in the JavaScript engine, but the attacker reportedly needs the user to perform a specific UI gesture, not just passively render a page.

The vendor's 8.8/HIGH baseline is directionally fair for a browser memory-corruption issue in a massively deployed product, but it slightly overstates real enterprise risk. The attack is still remote and pre-auth, which matters, yet the chain has two big brakes: user interaction beyond a normal click/view and Chrome's renderer sandbox, which usually turns a single browser bug into code execution in a constrained process rather than instant host takeover.

"Broad client-side reach, but the required UI gesture and browser sandbox keep this below panic level."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious web page

The attacker hosts exploit content that targets a V8 lifetime bug and gets a user to browse to it through phishing, malvertising, chat, or a compromised site. Weaponization is straightforward in principle because V8 bugs are a well-studied exploit class, but no public working exploit was found in the sourced material for this CVE.
Conditions required:
  • Target uses Chrome in the affected version range
  • Attacker can get the victim to a malicious or attacker-controlled page
  • JavaScript is allowed to run
Where this breaks in practice:
  • Enterprise email/web filtering regularly strips or blocks commodity delivery paths
  • Adversary still needs a user-targeting channel; this is not internet-scan-and-pop
Detection/coverage: Network scanners will miss this entirely. Detection comes from browser version inventory, web proxy telemetry, EDR browser-child-process anomalies, and crash spikes tied to Chrome.
STEP 02

Induce the required UI gesture

Per the published description, exploitation requires the victim to perform a specific UI gesture. That is materially different from a pure drive-by: the page alone is not enough, so the attacker must script social engineering around a click, drag, permission flow, or comparable action.
Conditions required:
  • Victim completes the needed gesture
  • The site can present believable lure content long enough to trigger it
Where this breaks in practice:
  • This requirement sharply reduces opportunistic exploitation volume
  • Modern browser warnings, user training, and page-isolation tooling break many lure flows
Detection/coverage: There is no reliable signature for 'specific UI gesture required.' Focus on suspicious referrers, user-reported crashes, and exploit-protection events from EDR/browser hardening tools.
STEP 03

Trigger V8 memory corruption

After the gesture, crafted JavaScript attempts to hit the use-after-free condition and gain instruction control inside the renderer. Public details are limited, which is normal for fresh Chrome fixes because Google often restricts bug specifics until users are updated.
Conditions required:
  • Exploit primitives line up on the target build
  • The target platform's mitigations do not stop reliability
Where this breaks in practice:
  • Chrome exploit reliability varies by OS build, allocator behavior, and mitigation state
  • No confirmed in-the-wild exploitation or KEV entry reduces urgency versus a proven zero-day
Detection/coverage: Memory-corruption exploitation may surface as renderer crashes, exploit guard events, or unusual browser process terminations. Traditional vuln scanners have poor direct coverage.
STEP 04

Operate within the browser sandbox

A successful V8 exploit usually lands code execution in a sandboxed renderer context first. That can still steal session data, abuse the logged-in browser, and stage follow-on actions, but it is not the same thing as clean host-level compromise unless paired with a sandbox escape or local privilege chain.
Conditions required:
  • Exploit succeeds in the renderer
  • Desired objective is achievable from browser context or attacker has a second-stage escape
Where this breaks in practice:
  • Chrome's sandbox limits direct blast radius from a single bug
  • A second vulnerability is often required for durable OS-level compromise
Detection/coverage: EDR can sometimes catch suspicious browser child processes, token abuse, or post-exploitation staging. If the exploit stays inside renderer space, visibility is much weaker.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in the sourced material, and not listed in CISA KEV.
Proof-of-concept availabilityNo public working PoC located in the sources. That lowers immediate copycat risk, though V8 memory bugs are a familiar exploit target for capable actors.
EPSS0.0008 from the user-provided intel, which is very low and consistent with a fresh browser client bug that lacks public exploitation evidence.
KEV statusNot KEV-listed as of this assessment; no CISA date-added entry found.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — remote and no privileges required, but user interaction is mandatory, which is the key real-world brake.
Affected versionsGoogle Chrome prior to 149.0.7827.53; desktop release notes indicate 149.0.7827.53 (Linux) and 149.0.7827.53/.54 (Windows/Mac) as the fixed train.
Fixed versionsPatch to 149.0.7827.53 or later on Linux and 149.0.7827.54 or later on Windows/macOS where that build is the shipped stable release. Chrome's rapid channel cadence means later 149+ builds also contain the fix.
Exposure realityThis is not internet-scannable like a VPN or appliance bug; Shodan/Censys-style exposure counts are mostly irrelevant. The exposure population is your installed Chrome estate, which is usually enormous in enterprise.
Disclosure date2026-06-04 per the user-provided intel; the Chrome stable desktop security release was published 2026-06-02 and national advisory follow-on appeared 2026-06-03.
Researcher / reportingThe exact researcher attribution for CVE-2026-10991 was not clearly exposed in the public official release excerpt reviewed. Google commonly withholds detailed bug metadata until patch adoption improves.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.1/10)

The decisive factor is the required specific UI gesture, which pushes this out of pure drive-by territory and cuts down the population that can be exploited at scale. It stays HIGH because Chrome is ubiquitous, the bug is still pre-auth remote against end users, and a renderer compromise is still a serious foothold for session theft and follow-on tradecraft.

HIGH Affected version range and fixed train
MEDIUM Exploitability reassessment under real-world user-interaction requirements
MEDIUM Impact interpretation given sparse public technical detail

Why this verdict

  • Down from 8.8 because UI:R is not cosmetic here — the description says a *specific UI gesture* is needed, which adds social-engineering and reliability friction beyond 'visit page, get popped.'
  • Still HIGH because attacker position is only remote web access — no authentication, no internal foothold, no prior compromise, and the target population is basically every Chrome user in your fleet.
  • Down again because blast radius starts in the browser sandbox — absent evidence of a paired sandbox escape or zero-day chaining, this is usually a constrained renderer win first, not instant domain compromise.

Why not higher?

There is no KEV listing, no sourced active exploitation evidence, and no public PoC in the material reviewed. More importantly, the chain requires victim interaction and likely yields a sandboxed browser foothold first, which is serious but not the same as a one-packet perimeter RCE.

Why not lower?

This is still a remote memory-corruption flaw in Chrome's JavaScript engine, not a niche admin-only bug. Chrome's deployment scale means even moderate exploit friction can still translate into meaningful enterprise exposure, especially for high-value users who browse untrusted content.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update compliance — Use Chrome enterprise policy or your endpoint management stack to verify the fleet is moving to 149.0.7827.53/54+. For a HIGH verdict, deploy and validate this within 30 days, because the fastest risk reduction here is simply shrinking the affected browser population.
  2. Tighten risky site access — Use secure web gateway controls, category blocks, and link isolation for unknown domains, newly registered sites, and ad-heavy destinations. This helps break step 1 of the chain and should be in place or tuned within 30 days.
  3. Isolate high-risk browsing roles — Put executives, finance, admins, developers, and help desk into browser isolation or hardened browsing profiles first. That limits impact if an exploit lands and should be prioritized within 30 days for the highest-value users.
  4. Watch for Chrome crash and spawn anomalies — Alert on spikes in chrome/google-chrome crashes, browser child-process launches, and suspicious downloads immediately after browsing events. This will not prevent exploitation, but it improves containment of successful attempts and should be tuned within 30 days.
What doesn't work
  • MFA does not stop initial browser exploitation; it only helps after credential theft or session abuse.
  • Perimeter vulnerability scanning will not find this reliably because it is an endpoint client-version problem, not an exposed listening service.
  • WAF rules are mostly irrelevant unless you fully control the malicious site, which you do not in the normal phishing or malvertising case.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/EDR remote execution feature. Invoke it as python3 check_chrome_cve_2026_10991.py on macOS/Linux or py check_chrome_cve_2026_10991.py on Windows; it needs standard user rights only and reports VULNERABLE, PATCHED, or UNKNOWN based on the locally installed Chrome version.

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

import os
import platform
import re
import subprocess
import sys

FIXED = (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_windows():
    try:
        import winreg
    except Exception:
        return 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
        except OSError:
            pass
    return None


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 parse_version(out)
    except Exception:
        return None


def get_version_macos():
    plist_path = '/Applications/Google Chrome.app/Contents/Info.plist'
    if os.path.exists(plist_path):
        v = run_cmd(['/usr/bin/defaults', 'read', plist_path, 'CFBundleShortVersionString'])
        if v:
            return v
    return run_cmd(['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'])


def get_version_linux():
    candidates = [
        ['google-chrome', '--version'],
        ['google-chrome-stable', '--version'],
        ['chromium-browser', '--version'],
        ['chromium', '--version'],
    ]
    for cmd in candidates:
        v = run_cmd(cmd)
        if v:
            return v
    return None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        version = get_version_windows()
    elif 'darwin' in system:
        version = get_version_macos()
    elif 'linux' in system:
        version = get_version_linux()
    else:
        print('UNKNOWN: unsupported platform')
        sys.exit(2)

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

    print('Detected Chrome version: %s' % '.'.join(map(str, version)))
    if cmp_ver(version, FIXED) < 0:
        print('VULNERABLE')
        sys.exit(1)
    else:
        print('PATCHED')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a fleet browser hygiene problem with meaningful user-targeting risk, not an all-hands perimeter emergency. Because the reassessed verdict is HIGH, your noisgate mitigation SLA is within 30 days: enforce browser auto-update, isolate high-risk browsing cohorts, and tighten web filtering for unknown destinations; your noisgate remediation SLA is within 180 days, but in practice Chrome should be patched far sooner by driving all endpoints to 149.0.7827.53/54 or later and closing the inventory exceptions list.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop (Chrome 149.0.7827.53/.54)
  2. Chrome Releases main feed showing Chrome 149 stable rollout
  3. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. MITRE CWE-416 Use After Free
  7. VulDB aggregated listing for CVE-2026-10991
  8. InfoProtección aggregated Chrome CVE listing including CVE-2026-10991
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.