This is a booby-trapped web page aimed at a side door of the browser, not a worm punching through the front gate
CVE-2026-10895 is a use-after-free in Chrome's Ozone layer that affects Chrome releases prior to 149.0.7827.53 on Linux and the corresponding 149.0.7827.53/.54 desktop release train called out by Google. The attacker path is straightforward on paper: deliver crafted HTML/JS, get the target to render it, and trigger memory corruption that can yield code execution in a Chrome process.
Google's HIGH 8.8 baseline is technically fair for browser memory corruption with remote delivery, but it overstates real-world enterprise impact if you read it as guaranteed endpoint takeover. The big reality checks are user interaction, Chromium's multi-process sandboxing, the absence of KEV or exploitation evidence, and the fact that Ozone bugs are usually a narrower reliability target than a generic V8 or Blink bug.
4 steps from start to impact.
Land the victim on attacker HTML
- Target is running Chrome older than
149.0.7827.53 - Victim browses to attacker-controlled content or malvertising
- Enterprise controls do not block the destination first
- Requires user interaction (
UI:R), so it is not wormable - URL filtering, isolation, or ad-blocking can prevent initial delivery
- A crafted page still has to hit the specific vulnerable execution path
Trigger Ozone use-after-free
- Rendered content reaches the vulnerable Ozone path
- Target platform/configuration aligns with the buggy code path
- Attacker achieves stable heap state
- Ozone is not as universally attacker-friendly as a plain renderer bug in V8/Blink
- Platform and display-stack differences can make reliable exploitation brittle
- Many attempts will crash the tab or process instead of yielding usable execution
Break out of the useful sandbox boundary
- Successful code execution in a Chrome process
- Sandbox not materially weakened by local policy or launch flags
- Attacker has a follow-on technique for data theft or escape
- Chrome's multi-process architecture and sandbox materially constrain blast radius
- Reliable full host compromise frequently needs an additional bug or local weakness
- EDR is much more likely to catch post-exploitation than the initial page load
Monetize browser-resident access
- Attacker retains stable execution long enough to act
- Useful cookies, tokens, or accessible data exist in the victim context
- Short-lived browser processes and site isolation reduce persistence
- MFA-resistant session theft still depends on where the victim is logged in
- Host controls can kill the chain after the first suspicious action
The supporting signals.
| In-the-wild status | No authoritative exploitation signal found in primary-source review as of 2026-06-04; user-provided intel says not KEV-listed. |
|---|---|
| Public PoC status | No trustworthy public PoC or Metasploit-style weaponization surfaced in primary-source search. Treat that as *absence of evidence*, not safety. |
| EPSS | 0.0008 from the intake intel, which is extremely low and argues against urgent mass exploitation pressure. |
| KEV status | Not listed in CISA KEV based on the intake intel and spot-check against the KEV catalog on 2026-06-04. |
| CVSS meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H means remote delivery with no auth, but it still explicitly requires user interaction and assumes worst-case impact after exploitation. |
| Affected versions | Chrome prior to 149.0.7827.53; Google's release posts show the early stable desktop train moved to 149.0.7827.53/.54 on 2026-05-29. |
| Fixed versions | Minimum safe floor is 149.0.7827.53 for Linux and the corresponding 149.0.7827.53/.54 desktop release train for Windows/macOS. Use the vendor channel package number actually shipped to your OS. |
| Exposure telemetry | Shodan/Censys/GreyNoise-style internet exposure counts are not meaningful here because this is a client-side browser flaw, not an internet-exposed listening service. |
| Disclosure date | 2026-06-04 per the intake intel. |
| Researcher / reporting | Specific reporter credit was not identified in the sources reviewed. Historical public Chromium Ozone reports show this bug class often lands in Linux/Wayland-facing code paths. |
noisgate verdict.
The decisive factor is that this is still a ubiquitous, one-click browser memory-corruption bug in software installed on nearly every endpoint. It stays out of CRITICAL because the chain still depends on victim interaction and Chrome's sandboxed multi-process architecture meaningfully reduces the odds that a single bug becomes clean, durable host compromise.
Why this verdict
- Vendor starts at 8.8 because unauthenticated remote delivery of a browser memory bug is dangerous and Chrome is everywhere
UI:Ris real downward pressure because the attacker needs the victim to render a crafted page or ad, which implies phishing, malvertising, or prior browsing influence rather than direct reachability- Sandboxing knocks it down again because Chromium's multi-process model and locked-down renderer-style processes mean reliable endpoint compromise often needs a second bug or a strong post-exploitation technique
- Ozone is a narrower component than V8/Blink so the reachable population and exploit reliability are likely less universal than the CVSS headline suggests
- No KEV and very low EPSS remove urgency pressure; there is no current signal that operators are burning this broadly in the wild
Why not higher?
There is no KEV listing, no verified active exploitation, and no public high-confidence PoC in the reviewed sources. More importantly, Chrome's sandbox architecture means the vendor's worst-case C/I/A impact is not the same thing as reliable full-host compromise in a modern enterprise fleet.
Why not lower?
This is still a remotely delivered browser memory-corruption flaw in a massively deployed client application, so you cannot treat it like backlog dust. A single user visit to hostile content is enough to start the chain, and many enterprises have enough unmanaged browsing surface that this remains operationally important.
What to do — in priority order.
- Enforce rapid browser auto-update — Use enterprise Chrome policies or your software deployment stack to keep Stable pinned to current vendor builds and eliminate version lag. For a HIGH verdict, deploy this control within 30 days if it is not already enforced, because stale browser channels are what turn client bugs into long-tail exposure.
- Tighten web filtering for high-risk categories — Block newly registered domains, obvious malvertising routes, and uncategorized destinations at the Secure Web Gateway to cut off the delivery step. For a HIGH verdict, have the policy tightened within 30 days while the patch rollout finishes.
- Watch for browser crash and post-browser execution anomalies — Create detections for repeated Chrome crashes followed by child-process launches, LOLBin execution, or suspicious outbound network activity from the same host. For a HIGH verdict, push those detection updates within 30 days because EDR is most likely to catch the chain after exploitation begins.
- Reduce unnecessary risky browser features and flags — Audit for
--no-sandbox, relaxed developer flags, unsupported channel builds, and local exceptions that weaken browser isolation. For a HIGH verdict, remove those deviations within 30 days because they erase the exact friction that keeps this from being CRITICAL.
- A perimeter vulnerability scan does not materially measure exposure here, because the vulnerable surface is the endpoint browser runtime, not a listening network service
- MFA does not stop exploit delivery; it only helps after session theft scenarios, and even then not against every token-abuse path
- Relying on user awareness training alone is weak here because malvertising and drive-by delivery can satisfy the required user interaction without an obviously suspicious attachment or prompt
Crowdsourced verification payload.
Run this on the target endpoint itself or through your RMM/EDR script runner. Invoke it with python3 check_cve_2026_10895.py for auto-detection, or python3 check_cve_2026_10895.py --version "149.0.7827.52" to test a known version string; no admin rights are usually required, though managed install paths may need normal local read access.
#!/usr/bin/env python3
# check_cve_2026_10895.py
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
import os
import platform
import re
import shutil
import subprocess
import sys
PATCHED_MIN = (149, 0, 7827, 53)
VERSION_RE = re.compile(r'(\d+)\.(\d+)\.(\d+)\.(\d+)')
def parse_version(text):
if not text:
return None
m = VERSION_RE.search(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 '') + ' ' + (p.stderr or '')
return out.strip()
except Exception:
return ''
def detect_from_commands():
candidates = [
['google-chrome', '--version'],
['google-chrome-stable', '--version'],
['chromium', '--version'],
['chromium-browser', '--version'],
['/Applications/Google Chrome.app/Contents/MacOS/Google Chrome', '--version'],
['/Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary', '--version'],
]
for cmd in candidates:
exe = cmd[0]
if os.path.isabs(exe) or shutil.which(exe):
out = run_cmd(cmd)
ver = parse_version(out)
if ver:
return ver, ' '.join(cmd)
return None, None
def detect_from_windows_registry():
if platform.system().lower() != 'windows':
return None, None
reg_paths = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon',
]
for path in reg_paths:
out = run_cmd(['reg', 'query', path, '/v', 'version'])
ver = parse_version(out)
if ver:
return ver, f'reg query {path} /v version'
return None, None
def get_version_from_arg():
if '--version' in sys.argv:
idx = sys.argv.index('--version')
if idx + 1 < len(sys.argv):
return parse_version(sys.argv[idx + 1]), '--version argument'
return None, None
def main():
ver, source = get_version_from_arg()
if ver is None:
ver, source = detect_from_commands()
if ver is None:
ver, source = detect_from_windows_registry()
if ver is None:
print('UNKNOWN: could not determine installed Chrome/Chromium version')
sys.exit(2)
ver_str = '.'.join(str(x) for x in ver)
fixed_str = '.'.join(str(x) for x in PATCHED_MIN)
if ver < PATCHED_MIN:
print(f'VULNERABLE: detected version {ver_str} from {source}; fixed floor is {fixed_str} or later')
sys.exit(1)
else:
print(f'PATCHED: detected version {ver_str} from {source}; fixed floor is {fixed_str} or later')
sys.exit(0)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53 and push this through your normal browser ring deployment, starting with internet-facing user populations and Linux/ChromeOS-heavy cohorts first. For a HIGH verdict, the noisgate mitigation SLA is within 30 days for compensating controls like enforced auto-update, web-filter tightening, and detection tuning, and the noisgate remediation SLA is within 180 days for the actual vendor patch — but for a browser bug this common, finishing the upgrade in your next standard browser cycle is the right operational move, not waiting for the outer bound.Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Google Chrome Releases homepage
- Chromium multi-process architecture
- Chromium sandbox diagnostics / sandbox overview
- Rapid7 reference for prior Ozone UAF (CVE-2022-1487)
- Public Chromium issue for prior Ozone UAF on Linux/Wayland
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS model documentation
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.