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

Use after free in Ozone in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
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 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative exploitation signal found in primary-source review as of 2026-06-04; user-provided intel says not KEV-listed.
Public PoC statusNo trustworthy public PoC or Metasploit-style weaponization surfaced in primary-source search. Treat that as *absence of evidence*, not safety.
EPSS0.0008 from the intake intel, which is extremely low and argues against urgent mass exploitation pressure.
KEV statusNot listed in CISA KEV based on the intake intel and spot-check against the KEV catalog on 2026-06-04.
CVSS meaningCVSS: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 versionsChrome 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 versionsMinimum 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 telemetryShodan/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 date2026-06-04 per the intake intel.
Researcher / reportingSpecific 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.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.3/10)

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.

HIGH Downgrade from the vendor's 8.8 baseline due to user interaction plus sandbox friction
MEDIUM Inference that Ozone narrows exploit reliability versus a generic V8/Blink bug
HIGH Assessment that lack of KEV/exploitation evidence keeps this below fire-drill priority

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. 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.
  4. 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
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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: inventory every Chrome channel lagging below 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

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Google Chrome Releases homepage
  3. Chromium multi-process architecture
  4. Chromium sandbox diagnostics / sandbox overview
  5. Rapid7 reference for prior Ozone UAF (CVE-2022-1487)
  6. Public Chromium issue for prior Ozone UAF on Linux/Wayland
  7. CISA Known Exploited Vulnerabilities Catalog
  8. FIRST EPSS model documentation
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.