This is a second lock behind a door the attacker already had to break open
Based on the vendor title, this flaw sits in WebShare on macOS builds of Google Chrome before 149.0.7827.53. The important missing half of the sentence is the real attack precondition implied by the supplied CVSS and by closely analogous 2026 Chrome records: the attacker must already have *compromised the renderer process* and then use a crafted HTML page to drive the vulnerable code path. In plain English, this is not a one-bug drive-by from the open internet; it is the privilege-boundary break that turns a renderer foothold into a broader browser escape on Mac.
Google's HIGH 8.3 label is technically defensible in CVSS terms because a successful sandbox escape inside a browser exploit chain has major impact. Operationally, though, that score overstates Monday-morning urgency for most enterprises: it is Mac-only, needs user interaction, has high attack complexity, depends on a prior renderer compromise, and there is no KEV listing or exploitation signal in the sources reviewed. That combination pushes this down from 'drop everything' to 'important chained browser hardening.'
4 steps from start to impact.
Gain renderer execution with a separate browser bug
CVE-2026-10920 does not appear to provide that initial foothold by itself; it is the follow-on boundary break. In practice this means a second exploit primitive, usually another memory corruption or logic flaw in web-exposed browser code, has to land first.- Victim is on macOS and using Chrome before
149.0.7827.53 - Victim browses attacker-controlled or attacker-influenced content
- Attacker has a separate renderer-compromise primitive
- This prerequisite implies a multi-bug chain, which dramatically shrinks the real attacker pool
- Modern browser hardening, exploit mitigations, and frequent Chrome updates burn many n-day chains quickly
- Mac-only target set narrows enterprise exposure versus all-platform Chrome bugs
Drive the vulnerable WebShare path from compromised content
WebShare implementation on macOS. The bug class is CWE-20 insufficient validation of untrusted input, so the exploit goal is to pass malformed or attacker-shaped data across a trust boundary that WebShare mishandles. This stage is where the bug stops being theoretical and becomes a sandbox-escape primitive.- Renderer already compromised
WebSharereachable in the victim browsing context- User interaction remains part of the chain per vendor CVSS (
UI:R)
- Feature reachability is narrower than generic navigation or JS engine bugs
- User interaction still matters, so completely silent exploitation is less likely
- Enterprise controls that reduce arbitrary browsing and risky content lower trigger opportunities
Break the browser boundary
- Precise exploitability of the validation flaw on the target build
- Compatible macOS and Chrome build behavior
- Exploit chain survives browser mitigations and race/complexity constraints
- Vendor CVSS marks attack complexity as
H, which is a real downward pressure here - Browser exploit reliability varies heavily by minor version and target hardware/software mix
- No public exploitation evidence reduces confidence that this is turnkey
Act in the user context on the endpoint
- Sandbox escape succeeds
- Post-exploitation tooling executes without being blocked
- User context has access worth stealing or abusing
- EDR, macOS controls, and application control may still stop post-escape actions
- User-context execution is weaker than admin/root compromise
- Enterprise browser isolation or VDI can contain impact where deployed
The supporting signals.
| In-the-wild status | No evidence found in reviewed primary sources, and not listed in CISA KEV. |
|---|---|
| Public exploit / PoC | No public PoC was surfaced in the reviewed vendor/NVD/CISA sources. Treat as chainable but not commoditized. |
| EPSS | 0.00061 — extremely low predicted exploitation probability, consistent with a multi-stage browser chain. |
| KEV status | No KEV listing as of 2026-06-05. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H means remote delivery is possible, but with high complexity, user interaction, and a scope change typical of sandbox escapes. |
| Affected versions | Google Chrome on macOS before 149.0.7827.53. |
| Fixed version | Upgrade macOS Chrome to 149.0.7827.53 or later. |
| Exposure reality | This is client-side endpoint exposure, not an internet-facing service. Shodan/Censys-style counts are mostly irrelevant; exposure maps to your managed Mac browser estate. |
| Disclosure | User-provided disclosure date: 2026-06-04. Google released the relevant desktop stable build on 2026-05-29 and the Canadian Cyber Centre referenced it on 2026-06-03. |
| Analogous Chrome bug pattern | Multiple 2026 Chrome CVEs use the same pattern: attacker has already compromised the renderer process and then uses a crafted page to perform a sandbox escape. See CVE-2026-7967 and CVE-2026-10000. |
noisgate verdict.
The decisive factor is the renderer-compromise prerequisite: this is a post-initial browser-exploit primitive, not a standalone internet-to-code-execution bug. That prerequisite compounds with Mac-only scope, AC:H, UI:R, and no active exploitation signal, which pulls the operational risk down a full bucket.
Why this verdict
- Renderer foothold required: the attack path implies the adversary already owns the renderer, which means this CVE is the *second bug in a chain* rather than the front door.
- Mac-only exposure: affected population is narrower than cross-platform Chrome bugs, especially in mixed Windows-heavy enterprises.
- High complexity plus user interaction:
AC:HandUI:Rare not theoretical here; they reflect real exploit reliability and delivery friction. - No KEV / no exploitation signal: without active exploitation evidence, the vendor CVSS remains a worst-case impact score, not a threat-priority score.
- Still not low: if chained successfully, sandbox escape meaningfully increases blast radius on a user endpoint and can turn a renderer hit into real post-exploitation.
Why not higher?
A higher rating would fit a bug that is directly reachable by an unauthenticated remote attacker with no prior foothold, or one with credible active exploitation. This CVE fails both tests: it appears to require a prior renderer compromise and there is no reviewed evidence of weaponization in the wild.
Why not lower?
This is still a browser sandbox escape class issue inside a massively deployed application, and Chrome exploit chains are exactly how high-end operators bridge from web content to endpoint control. Even with friction, the impact of a working chain on a managed Mac is too meaningful to dismiss as backlog-only hygiene.
What to do — in priority order.
- Enforce rapid Chrome auto-update on managed Macs — Use Chrome enterprise policy and your Mac management stack to minimize patch lag and keep desktop Chrome relaunching into current builds. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice browsers should not sit unpatched anywhere near that long.
- Reduce arbitrary browsing from privileged Mac users — Move admins, developers with production access, and high-value users to tighter browsing policies, separate profiles, or browser isolation where feasible. This shrinks the odds that a renderer bug can be paired with this follow-on escape; for MEDIUM, there is no mitigation SLA, so apply this where risk concentration is highest rather than as a fleet-wide emergency.
- Hunt for suspicious Chrome child-process behavior — Tune EDR detections for
Google Chromespawning shells, installers, script interpreters, or unusual persistence artifacts on macOS. This does not stop the bug itself, but it is the practical containment point after a successful escape; again, no mitigation SLA applies for this severity. - Inventory Mac Chrome versions from management telemetry — Use Google Admin, MDM, or EDR software inventory to identify Macs still below
149.0.7827.53. For a MEDIUM verdict, focus on verification and cleanup within the normal remediation program rather than emergency change windows.
- Perimeter blocking or WAF rules: this is a client-side browser issue, so your edge controls won't reliably stop a crafted page delivered through normal web traffic.
- Credential controls like MFA alone: MFA does nothing to prevent a browser sandbox escape once malicious content is rendered.
- Network scanning for exposure: Shodan/Censys-style external scanning will not tell you which endpoints are vulnerable because the asset is the browser on the Mac, not an exposed service.
Crowdsourced verification payload.
Run this on the target Mac endpoint or through your MDM/remote shell. Invoke it as bash chrome_cve_2026_10920_check.sh with standard user privileges; it reads the installed Chrome app version and compares it to the fixed build 149.0.7827.53.
#!/bin/bash
# chrome_cve_2026_10920_check.sh
# Checks whether Google Chrome on macOS is vulnerable to CVE-2026-10920
# Exit codes:
# 0 = PATCHED
# 1 = VULNERABLE
# 2 = UNKNOWN
set -u
APP_PATHS=(
"/Applications/Google Chrome.app"
"$HOME/Applications/Google Chrome.app"
)
FIXED_VERSION="149.0.7827.53"
FOUND_APP=""
INSTALLED_VERSION=""
version_to_list() {
local IFS=.
read -r -a parts <<< "$1"
for i in 0 1 2 3; do
echo -n "${parts[$i]:-0} "
done
}
version_ge() {
local a b i
read -r -a a <<< "$(version_to_list "$1")"
read -r -a b <<< "$(version_to_list "$2")"
for i in 0 1 2 3; do
if (( a[$i] > b[$i] )); then
return 0
elif (( a[$i] < b[$i] )); then
return 1
fi
done
return 0
}
for p in "${APP_PATHS[@]}"; do
if [[ -d "$p" ]]; then
FOUND_APP="$p"
break
fi
done
if [[ -z "$FOUND_APP" ]]; then
echo "UNKNOWN: Google Chrome.app not found in standard macOS application paths"
exit 2
fi
PLIST="$FOUND_APP/Contents/Info.plist"
if [[ ! -f "$PLIST" ]]; then
echo "UNKNOWN: Info.plist not found at $PLIST"
exit 2
fi
INSTALLED_VERSION=$(/usr/bin/defaults read "$PLIST" KSVersion 2>/dev/null || true)
if [[ -z "$INSTALLED_VERSION" ]]; then
INSTALLED_VERSION=$(/usr/bin/defaults read "$PLIST" CFBundleShortVersionString 2>/dev/null || true)
fi
if [[ -z "$INSTALLED_VERSION" ]]; then
echo "UNKNOWN: Could not determine installed Chrome version"
exit 2
fi
if version_ge "$INSTALLED_VERSION" "$FIXED_VERSION"; then
echo "PATCHED: Google Chrome $INSTALLED_VERSION (fixed version is $FIXED_VERSION)"
exit 0
else
echo "VULNERABLE: Google Chrome $INSTALLED_VERSION (fixed version is $FIXED_VERSION)"
exit 1
fi
If you remember one thing.
149.0.7827.53, make sure auto-update and relaunch behavior are actually working, and clean up any laggards through normal endpoint operations. Because this is MEDIUM, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; the noisgate remediation SLA is ≤ 365 days. In practice, for browsers, you should compress that heavily and clear stale versions on your next regular desktop patch cycle rather than letting them age in inventory.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.