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.
4 steps from start to impact.
Deliver weaponized web content
- Victim is running vulnerable Chrome
- Victim browses attacker-controlled or attacker-influenced content
- Graphics path used by the page reaches ANGLE
- 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
Trigger the ANGLE heap corruption
- The exact vulnerable code path is reachable on that OS/build
- The page can induce the right graphics state and memory layout
- 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
chrome crashes, GPU-process instability, or anomalous renderer terminations; signature-based detection is weak.Convert corruption into code execution in-browser
- Attacker has a reliable exploit chain for this exact primitive
- Target protections do not stop the control-flow pivot
- 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
Escape the browser blast radius
- A second-stage technique or additional vulnerability is available
- Valuable browser-resident data or reachable enterprise sessions exist
- 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
The supporting signals.
| In-the-wild status | No public exploitation evidence was located as of 2026-06-05, and the bug is not listed in CISA KEV. |
|---|---|
| Public PoC | No public GitHub or researcher PoC for CVE-2026-10907 was found in the retrieved sources. |
| EPSS | Provided EPSS is 0.00068 (~0.068% 30-day probability). That's very low and argues against emergency-tier panic. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog as checked on 2026-06-05. |
| CVSS vector readout | CVSS: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 versions | Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS. |
| Fixed versions | Google 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 model | This 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 timeline | Reported by sweetchip on 2026-03-02; fix shipped in the stable release on 2026-06-02; CVE metadata published on 2026-06-04. |
| Research visibility | Chromium notes that bug details may stay restricted until most users are patched, which limits independent exploitability analysis immediately after release. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- 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.
- 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.
- 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.
- 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.
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.
#!/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()
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.