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

Out of bounds write in ANGLE in Google Chrome prior to 149

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

This is a cracked windshield on every company car, not an engine fire in the parking garage

CVE-2026-10907 is an out-of-bounds write in ANGLE, Chrome's graphics translation layer used by WebGL and other rendering paths. In practical terms, a malicious site can feed crafted graphics content into vulnerable Chrome builds and corrupt heap memory. Affected builds are Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS.

Google's HIGH / 8.8 label is technically defensible, but for enterprise patch triage it's a little hot. This is still a client-side, user-interaction-required browser bug with no KEV listing, no public in-the-wild evidence located, and no public PoC found as of 2026-06-05. The key reality check: browser memory corruption is dangerous, but the path from webpage to durable host compromise usually needs exploit reliability plus, often, a second stage beyond the initial browser process.

"Remote, real, and fleet-wide—but still a click-driven browser memory bug with no KEV or public exploit evidence yet."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver weaponized web content

The attacker hosts or injects a malicious page, ad, or embedded content that exercises Chrome's graphics stack and reaches ANGLE. This is classic drive-by delivery: email link, chat link, malvertising, or a compromised site is enough to put the payload in front of users.
Conditions required:
  • Victim is running vulnerable Chrome
  • Victim browses attacker-controlled or attacker-influenced content
  • Graphics path used by the page reaches ANGLE
Where this breaks in practice:
  • Still requires UI:R: somebody must render the content
  • Web filtering, Safe Browsing, DNS filtering, or ad blocking can break the first touch
  • Some enterprise app patterns do not heavily exercise risky WebGL paths
Detection/coverage: Exposure scanners can identify outdated Chrome versions, but they cannot tell whether a given user will hit the vulnerable rendering path.
STEP 02

Trigger the ANGLE heap corruption

The crafted page manipulates rendering inputs until ANGLE performs an out-of-bounds write. At that point the attacker gets memory corruption primitive(s), which may yield a crash, limited corruption, or a controllable execution path depending on build, platform, and exploit quality.
Conditions required:
  • The exact vulnerable code path is reachable on that OS/build
  • The page can induce the right graphics state and memory layout
Where this breaks in practice:
  • Browser exploit reliability is hard across diverse hardware, drivers, and allocators
  • Modern mitigations such as sandboxing, CFG/PAC, heap hardening, and process isolation raise exploit cost
  • Many attempts will just crash the tab or browser
Detection/coverage: EDR and browser telemetry may show repeated chrome crashes, GPU-process instability, or anomalous renderer terminations; signature-based detection is weak.
STEP 03

Convert corruption into code execution in-browser

A working exploit would need to turn the OOB write into controlled code execution inside the reachable browser process, likely renderer- or GPU-adjacent depending on the path. That is the dangerous part, but it is also the part that separates a bug from a weaponized exploit.
Conditions required:
  • Attacker has a reliable exploit chain for this exact primitive
  • Target protections do not stop the control-flow pivot
Where this breaks in practice:
  • No public PoC or exploit chain was located
  • Exploit development for modern Chrome memory bugs is expensive and brittle
  • Different Chrome channels and enterprise controls reduce uniformity
Detection/coverage: There is usually no dependable network IOC here; version inventory and crash analytics are better signals than IDS signatures.
STEP 04

Escape the browser blast radius

To move from browser compromise to broader endpoint impact, the attacker typically needs either a sandbox escape, token/session abuse, or data theft confined to browser context. This CVE by itself does not prove a full machine takeover path in a real enterprise without additional exploit work or another bug.
Conditions required:
  • A second-stage technique or additional vulnerability is available
  • Valuable browser-resident data or reachable enterprise sessions exist
Where this breaks in practice:
  • Chrome sandboxing limits straightforward host impact
  • MFA, conditional access, and EDR can blunt post-browser follow-on actions
  • Session value varies widely by user role
Detection/coverage: Post-exploitation is where EDR, identity telemetry, unusual child-process execution, and suspicious browser credential/session access become useful.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence was located as of 2026-06-05, and the bug is not listed in CISA KEV.
Public PoCNo public GitHub or researcher PoC for CVE-2026-10907 was found in the retrieved sources.
EPSSProvided EPSS is 0.00068 (~0.068% 30-day probability). That's very low and argues against emergency-tier panic.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog as checked on 2026-06-05.
CVSS vector readoutCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means easy remote delivery and no auth, but user interaction is mandatory.
Affected versionsChrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS.
Fixed versionsGoogle shipped fixes in Chrome 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS) on 2026-06-02. Downstream Chromium-based browsers backport on their own cadence.
Exposure modelThis is not an internet-enumerable server flaw; Shodan/Censys/FOFA won't tell you much. Exposure is your installed Chrome fleet + user browsing behavior, which is why browser inventory quality matters more than perimeter scanning.
Disclosure timelineReported by sweetchip on 2026-03-02; fix shipped in the stable release on 2026-06-02; CVE metadata published on 2026-06-04.
Research visibilityChromium notes that bug details may stay restricted until most users are patched, which limits independent exploitability analysis immediately after release.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.4/10)

The deciding factor is that this is a user-driven client-side browser bug, not an unauthenticated server-side foothold, and there is no active exploitation evidence to justify crisis handling. It stays HIGH because Chrome is everywhere, delivery is easy, and memory-corruption bugs can become weaponized quickly once somebody invests in exploit development.

HIGH Affected version range and patch floor
MEDIUM Real-world exploitability and likely blast radius beyond browser context

Why this verdict

  • Downgrade for UI:R: the vendor baseline treats this like a broadly reachable remote bug, but every real attack still needs a user to render attacker content.
  • Downgrade for chain friction: an ANGLE OOB write is dangerous, but turning browser heap corruption into stable endpoint impact usually needs a reliable exploit and often a second stage beyond the initial browser process.
  • Downgrade for missing threat evidence: no KEV entry, no public campaign reporting, no public PoC, and a very low EPSS all push against emergency severity.
  • Hold at HIGH for population size: Chrome is common across enterprise fleets, so even a click-driven client bug can have meaningful aggregate exposure if version hygiene is weak.

Why not higher?

There is no verified active exploitation, no public weaponization evidence, and the attack begins with a user opening malicious content. That is materially different from an externally reachable appliance flaw or a server RCE with immediate tenant-wide blast radius.

Why not lower?

This still lands through everyday browsing, requires no credentials, and targets one of the most ubiquitous applications in enterprise. Memory corruption in a browser is never housekeeping-grade risk, especially when privileged users and long browser session lifetimes are in play.

05 · Compensating Control

What to do — in priority order.

  1. Force managed browser updates — Verify update channels, unpin stale versions, and use your browser management stack to push Chrome at or above the fixed build. For a HIGH verdict, do this under the mitigation intent within 30 days, even if the real fix is just the vendor update.
  2. Isolate risky browsing tiers — Put admins, finance, executives, and help desk into remote browser isolation, disposable VDI, or hardened browsing profiles until coverage is complete. This is the best compensating control when you need a within-30-days risk reduction but cannot patch every endpoint immediately.
  3. Disable WebGL where business-tolerable — If a user group does not need advanced browser graphics, restrict or disable WebGL/related GPU features through policy for that cohort. Use it as a temporary compensating control within 30 days, not as a permanent substitute for updating.
  4. Watch version drift and crash telemetry — Alert on Chrome versions below the fixed floor and on spikes in browser/GPU-process crashes. This won't prevent exploitation, but it helps you find lagging rings and potential exploit testing during the 30-day mitigation window.
What doesn't work
  • A WAF does not meaningfully help; the target is the user's browser parsing/rendering attacker content, not your web app.
  • Perimeter internet scanning does not help much; this is not a service you can reliably find with Shodan/Censys/FOFA.
  • Generic antivirus signatures are weak here; memory-corruption exploit delivery through normal web content usually does not present a stable file hash to block.
06 · Verification

Crowdsourced verification payload.

Run this on the target host or through your EDR/live-response tool. Invoke it as python3 check_cve_2026_10907.py on macOS/Linux or py check_cve_2026_10907.py on Windows; no admin rights are required. The script checks common Chrome/Chromium install locations and prints VULNERABLE, PATCHED, or UNKNOWN.

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

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

FIXED = (149, 0, 7827, 53)

CANDIDATES = {
    'Windows': [
        r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files\\Chromium\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Chromium\\Application\\chrome.exe',
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
    ],
    'Linux': [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
    ]
}


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    return tuple(map(int, m.groups())) if m else None


def version_str(v):
    return '.'.join(map(str, v))


def get_version_from_binary(path):
    try:
        out = subprocess.check_output([path, '--version'], stderr=subprocess.STDOUT, text=True, timeout=10)
        return parse_version(out)
    except Exception:
        return None


def discover_binaries():
    system = platform.system()
    found = []

    for p in CANDIDATES.get(system, []):
        if os.path.exists(p):
            found.append(p)

    for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome']:
        p = which(name)
        if p and p not in found:
            found.append(p)

    return found


def main():
    binaries = discover_binaries()
    if not binaries:
        print('UNKNOWN: no Chrome/Chromium binary found in common locations')
        sys.exit(2)

    results = []
    for b in binaries:
        v = get_version_from_binary(b)
        if v:
            results.append((b, v))

    if not results:
        print('UNKNOWN: Chrome/Chromium found, but version could not be determined')
        sys.exit(2)

    vulnerable = []
    patched = []
    for path, ver in results:
        if ver < FIXED:
            vulnerable.append((path, ver))
        else:
            patched.append((path, ver))

    if vulnerable:
        worst = min(v[1] for v in vulnerable)
        paths = ', '.join([f'{p} ({version_str(v)})' for p, v in vulnerable])
        print(f'VULNERABLE: found build(s) below {version_str(FIXED)} -> {paths}')
        sys.exit(1)

    best = max(v[1] for v in patched)
    paths = ', '.join([f'{p} ({version_str(v)})' for p, v in patched])
    print(f'PATCHED: all discovered build(s) are >= {version_str(FIXED)} -> {paths}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
By Monday morning, pull an inventory of every endpoint running Chrome < 149.0.7827.53, then focus first on privileged users, executives, and high-browse populations. Because this is a HIGH noisgate call, apply compensating controls such as browser isolation or WebGL restriction for lagging cohorts within the noisgate mitigation SLA of 30 days, and complete the actual browser update within the noisgate remediation SLA of 180 days. In practice, this is a browser patch with low operational friction, so do not let it age anywhere near the outer limit just because the formal SLA allows it.

Sources

  1. Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Chrome 149 Release Notes
  3. Canadian Centre for Cyber Security - Google Chrome Security Advisory AV26-544
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS Data Statistics
  6. Chromium Security
  7. Chromium Issue Tracker Entry 489071023
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.