CVE-2026-10895 · Google Chrome Ozone use-after-free remote code execution via crafted…

01 · The Real Story

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.

"Dangerous browser memory corruption, but not a drop-everything fire because it still needs a victim click and likely benefits from chaining."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker HTML

The weaponized tool is usually just a malicious page or ad frame with custom JavaScript heap grooming. The attacker needs the browser to parse and render content that reaches the vulnerable Ozone code path, so this is classic one-click browser exploitation rather than service-side RCE.

Conditions required:

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

Where this breaks in practice:

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

Detection/coverage: Web proxies, Secure Web Gateway logs, and browser telemetry can sometimes catch delivery infrastructure, but vulnerability scanners do not reliably prove exploitability for a client-side browser bug.

STEP 02

Trigger Ozone use-after-free

The exploit then tries to force a stale object reference inside the Ozone/UI path and convert crashy memory corruption into controlled execution. A comparable public Chromium Ozone bug history shows this class has often been tied to Linux/Wayland-facing code, which matters because narrower platform assumptions reduce mass exploit reliability.

Conditions required:

Rendered content reaches the vulnerable Ozone path
Target platform/configuration aligns with the buggy code path
Attacker achieves stable heap state

Where this breaks in practice:

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

Detection/coverage: Crash telemetry, browser stability spikes, and EDR child-process anomalies may provide weak signals; signature-based network scanners generally do not.

STEP 03

Break out of the useful sandbox boundary

Even if the attacker gets code execution, Chromium's security model isolates renderer-style content handling into sandboxed, separate processes. In practice, high-value post-exploitation often requires either a browser-process pivot, a second sandbox escape, or abuse of data the compromised process can already reach.

Conditions required:

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

Where this breaks in practice:

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

Detection/coverage: EDR should see suspicious process trees, token abuse, filesystem access, or follow-on payload execution if the attacker pushes beyond the browser boundary.

STEP 04

Monetize browser-resident access

The realistic enterprise impact without a clean escape is session theft, same-user data access, local browser secrets, or staging for a second exploit. That is still serious at scale because Chrome is everywhere, but it is meaningfully different from a turnkey unauthenticated server RCE with direct internet reachability.

Conditions required:

Attacker retains stable execution long enough to act
Useful cookies, tokens, or accessible data exist in the victim context

Where this breaks in practice:

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

Detection/coverage: Look for unusual browser process access to credential stores, suspicious outbound beacons after a browser crash, and identity anomalies from stolen sessions.

03 · Compensating Control

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.

What doesn't work

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

04 · Intelligence Metadata

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.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to HIGH (7.3/10)

Why this verdict

Vendor starts at 8.8 because unauthenticated remote delivery of a browser memory bug is dangerous and Chrome is everywhere
UI:R is 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.

06 · Verification

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.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/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()