CVE-2026-10925 · Google Chrome Skia out-of-bounds write on macOS requiring prior…

01 · The Real Story

This is a second lock on the vault, not the front door

CVE-2026-10925 is an out-of-bounds write in Chrome's Skia graphics stack on macOS. Affected builds are Google Chrome on Mac prior to 149.0.7827.53 per the CVE text, with Google's stable release shipping 149.0.7827.53/54 for Windows and Mac on June 2, 2026. The important nuance is the attacker is not starting from the open web alone; they already need code execution or equivalent control in the Chrome renderer process and then use a crafted HTML page to drive the bug.

Google's HIGH 8.3 is defensible as a raw technical score for memory corruption in a ubiquitous browser, but it overstates operational urgency for enterprise patch triage. The renderer-compromise prerequisite is a massive real-world friction point, macOS-only scope cuts the population again, and there is no KEV listing, no public exploit chain, and a very low provided EPSS score.

"High on paper, but this is a chain component: Mac-only and only useful after renderer compromise."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land code execution in the renderer first

Weaponized tool: a separate renderer exploit, not public for this CVE and not included in Google's disclosure. The attacker must already have compromised Chrome's sandboxed renderer process through another browser bug, a malicious extension, or a separate chain component. Without that foothold, CVE-2026-10925 does nothing for the attacker.

Conditions required:

Victim is running Chrome on macOS
Attacker has already achieved renderer-process compromise
Victim reaches attacker-controlled web content or equivalent trigger surface

Where this breaks in practice:

This is a post-initial-browser-compromise step, not initial access
Modern browser exploit chains that reliably gain renderer control are rare and expensive
Many enterprises block unsigned extensions and shrink the renderer-compromise paths

Detection/coverage: EASM and internet scanners will not see this. Detection coverage lives in browser exploit telemetry, extension controls, crash analytics, and EDR child-process or unusual browser behavior correlation.

STEP 02

Hit the Skia memory corruption path

Weaponized tool: custom HTML or graphics content that exercises the vulnerable Skia code path, as referenced by the Chrome release note and CVE description. Once the renderer is compromised, the attacker uses crafted content to trigger the out-of-bounds write inside Skia on macOS. This is a memory corruption primitive, not a turnkey business-app exploit.

Conditions required:

Vulnerable Chrome version prior to 149.0.7827.53 on Mac
Reachable Skia code path from attacker-controlled content
Exploit reliability against the target's macOS and Chrome build

Where this breaks in practice:

Attack complexity is high in the vendor vector
Bug details are restricted by Chromium during rollout, reducing copy-paste exploitation
macOS build differences and exploit mitigations reduce reliability

Detection/coverage: Crash signatures may surface in Chrome or OS telemetry, but scanner coverage is basically version-based. You will mostly detect exposure by software inventory, not by network IDS.

STEP 03

Convert corruption into a useful primitive

Weaponized tool: bespoke exploit logic; no public PoC repo was identified in the sources reviewed. An out-of-bounds write only matters if the attacker can shape it into controlled memory corruption that survives modern mitigations and yields code execution or a security-boundary bypass from the compromised renderer context. In practice, this is the hard engineering step.

Conditions required:

Precise target-specific exploit development
Ability to bypass allocator hardening and relevant mitigations
Stable primitive under the victim's exact browser and OS version

Where this breaks in practice:

Memory-corruption exploitation on modern Chrome is nontrivial
Reliability drops fast across minor build and OS changes
No evidence of commoditized exploit tooling for this CVE

Detection/coverage: Look for repeated Chrome crashes, renderer instability, exploit-protection alerts, or abnormal browser-assisted process behavior. Preventive controls are stronger than detective controls here.

STEP 04

Chain to impact beyond the renderer

Weaponized tool: a full exploit chain, potentially adding sandbox-escape or data-access logic. Chromium's own security model assumes renderer compromise is not enough; Site Isolation and the sandbox exist specifically to make the next step harder. So the business risk comes from chaining CVE-2026-10925 with something else, not from CVE-2026-10925 standing alone.

Conditions required:

A successful memory-corruption exploit from Step 3
A path to escape sandbox restrictions or abuse renderer-held data
Victim workflows that keep valuable sessions or data in the browser

Where this breaks in practice:

Chrome sandbox and Site Isolation reduce blast radius from a single renderer bug
Impact is narrower than a direct unauthenticated RCE
Mac-only affected population further limits enterprise-wide exposure

Detection/coverage: EDR, browser hardening telemetry, and session-theft detections are more useful than perimeter tools. Vulnerability scanners will only confirm version exposure.

03 · Compensating Control

Enforce rapid Chrome auto-update on managed Macs — Use MDM or enterprise browser policy to keep Chrome current and prevent long-lived vulnerable builds. For a MEDIUM verdict there is no noisgate mitigation SLA; use this as standard hardening while you work toward patch completion within the 365-day remediation window.

Harden extension install paths — Restrict extension sources, require allowlisting, and block developer-mode or unsigned installs where policy allows. That matters because a malicious or compromised extension is one plausible way to satisfy the renderer-compromise prerequisite; again, there is no mitigation SLA here, but this is worth rolling into normal browser hardening.

Keep Site Isolation and default sandbox protections enabled — Do not weaken Chrome security settings or deploy flags that reduce process isolation. These controls directly increase exploit-chain friction and are especially valuable against vulnerabilities that are only useful *after* renderer compromise.

Use version-based exposure reporting from MDM or EDR — Track Google Chrome.app version on macOS endpoints and alert on anything below 149.0.7827.53. This is the practical way to measure exposure because internet scanners cannot see local browser versions.

What doesn't work

Perimeter IDS / IPS signatures do not solve this because the vulnerable target is a local browser rendering path, not a server-side protocol parser you can reliably filter.
MFA does not materially reduce exploitability of this CVE; it helps with account abuse after compromise, but it does not stop a browser memory-corruption chain.
External attack-surface tools like Shodan or Censys will not tell you which Macs are vulnerable, because Chrome clients are not internet-facing services.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No public evidence of active exploitation found in the reviewed sources, and not KEV-listed.
Proof-of-concept availability	No public PoC or weaponized repo was identified in the reviewed sources. Chromium bug details are commonly restricted during rollout, which slows immediate copycat development.
EPSS	Provided intel says 0.00068 (~0.068% 30-day exploitation probability). Percentile was not verified from an authoritative EPSS response during this assessment.
KEV status	No. CISA KEV catalog did not show this CVE in the reviewed material.
CVSS vector	`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H` = remote delivery and high impact on paper, but with high attack complexity and user interaction required.
Affected versions	Chrome on macOS prior to `149.0.7827.53` per the CVE text supplied. Google's desktop stable release on June 2, 2026 shipped `149.0.7827.53/54` for Windows/Mac.
Fixed versions	Upgrade managed Macs to Chrome `149.0.7827.53` or later. Google distributed `149.0.7827.53/54` on Windows/Mac; there are no distro backports to track because this is a desktop browser release, not an OS package stream.
Exposure / scanning reality	Shodan, Censys, and FOFA are not meaningful here because the vulnerable asset is a local browser binary, not an internet-facing service. Exposure has to be measured from endpoint inventory / MDM / EDR software versioning.
Disclosure timeline	Google stable-channel release published June 2, 2026; user-supplied disclosure date is 2026-06-04.
Reporter	Chrome release notes credit Google as the reporter on 2026-04-06.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to MEDIUM (6.1/10)

Why this verdict

Start from 8.3, then subtract hard for the prerequisite: the attacker must already control the renderer process, which makes this post-compromise chain material rather than initial access.
Mac-only scope narrows the blast radius: this is not a fleet-wide Chrome emergency unless your browser estate is heavily macOS-weighted.
Threat intel is quiet: no KEV listing, no public PoC identified, and the provided EPSS (0.00068) is extremely low for a browser issue.

Why not higher?

If this were a one-click or zero-click remote path from a malicious page directly to browser compromise, it would stay in HIGH and potentially push higher with active exploitation. But the renderer-compromise dependency is not a footnote; it is the whole story, because it means the attacker already needs a separate serious bug or foothold first.

Why not lower?

This is still memory corruption in a massively deployed browser component, and successful chaining could materially raise attacker capability on managed Macs. Browsers also sit on sessions, tokens, and sensitive data, so even second-stage browser bugs deserve real patch ownership rather than backlog neglect.

06 · Verification

Crowdsourced verification payload.

Run this on the target Mac endpoint locally or through MDM remote shell. Invoke it as bash check_chrome_cve_2026_10925.sh with standard user rights; root is not required because it only reads Chrome app metadata from /Applications.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/bin/bash
# check_chrome_cve_2026_10925.sh
# Detects exposure to CVE-2026-10925 on macOS by checking installed Google Chrome version.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

set -u

APP="/Applications/Google Chrome.app"
PLIST="$APP/Contents/Info.plist"
FIXED_VERSION="149.0.7827.53"

verlte() {
  [ "$1" = "$2" ] && return 0
  local IFS=.
  local i
  local -a va=($1) vb=($2)
  local len=${#va[@]}
  if [ ${#vb[@]} -gt $len ]; then
    len=${#vb[@]}
  fi
  for ((i=0; i<len; i++)); do
    local a=${va[i]:-0}
    local b=${vb[i]:-0}
    if ((10#$a < 10#$b)); then
      return 0
    fi
    if ((10#$a > 10#$b)); then
      return 1
    fi
  done
  return 0
}

if [ "$(uname -s)" != "Darwin" ]; then
  echo "UNKNOWN: This check is intended for macOS targets only."
  exit 2
fi

if [ ! -d "$APP" ] || [ ! -f "$PLIST" ]; then
  echo "UNKNOWN: Google Chrome not found at $APP"
  exit 2
fi

INSTALLED_VERSION=$(/usr/bin/defaults read "$PLIST" CFBundleShortVersionString 2>/dev/null || true)

if [ -z "$INSTALLED_VERSION" ]; then
  echo "UNKNOWN: Could not read Chrome version from $PLIST"
  exit 2
fi

if verlte "$INSTALLED_VERSION" "$FIXED_VERSION" && [ "$INSTALLED_VERSION" != "$FIXED_VERSION" ]; then
  echo "VULNERABLE: Google Chrome $INSTALLED_VERSION is older than fixed version $FIXED_VERSION"
  exit 1
fi

if [ "$INSTALLED_VERSION" = "$FIXED_VERSION" ]; then
  echo "PATCHED: Google Chrome $INSTALLED_VERSION matches fixed version $FIXED_VERSION"
  exit 0
fi

# Installed version is newer than the fixed version.
echo "PATCHED: Google Chrome $INSTALLED_VERSION is newer than fixed version $FIXED_VERSION"
exit 0