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

Insufficient validation of untrusted input in WebShare in Google Chrome on Mac prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

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.'

"This is a chain-only Chrome sandbox escape on Mac, not a standalone internet-to-endpoint compromise."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Gain renderer execution with a separate browser bug

The attacker first needs code execution or equivalent control inside Chrome's renderer process. 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.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: Most vuln scanners do not validate this prerequisite. Detection depends on browser crash telemetry, EDR exploit signals, and incident evidence of renderer compromise.
STEP 02

Drive the vulnerable WebShare path from compromised content

With renderer control, the attacker uses a crafted HTML page to reach the 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.
Conditions required:
  • Renderer already compromised
  • WebShare reachable in the victim browsing context
  • User interaction remains part of the chain per vendor CVSS (UI:R)
Where this breaks in practice:
  • 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
Detection/coverage: No reliable network signature. Browser instrumentation or exploit-detection telemetry is more useful than perimeter scanning.
STEP 03

Break the browser boundary

Successful exploitation lets the attacker move from the compromised renderer into a more privileged browser context, i.e. a sandbox escape. That is the core value of this CVE: not initial access, but privilege expansion within the browser architecture. Once that boundary is crossed, attacker options widen materially.
Conditions required:
  • 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
Where this breaks in practice:
  • 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
Detection/coverage: EDR may catch child-process anomalies or post-escape payload behavior, but often misses the browser-internal transition itself.
STEP 04

Act in the user context on the endpoint

After escape, the attacker can typically run follow-on actions with the user's privileges, pivot into credential theft, or stage persistence through separate techniques. The blast radius is endpoint-level, but only after the attacker has already assembled and delivered a functioning browser chain. That is serious, just not the same as a single-step unauthenticated remote compromise.
Conditions required:
  • Sandbox escape succeeds
  • Post-exploitation tooling executes without being blocked
  • User context has access worth stealing or abusing
Where this breaks in practice:
  • 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
Detection/coverage: Good EDR coverage resumes here: suspicious child processes from Chrome, unusual file writes, credential access, and persistence attempts are the practical hunting points.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence found in reviewed primary sources, and not listed in CISA KEV.
Public exploit / PoCNo public PoC was surfaced in the reviewed vendor/NVD/CISA sources. Treat as chainable but not commoditized.
EPSS0.00061 — extremely low predicted exploitation probability, consistent with a multi-stage browser chain.
KEV statusNo KEV listing as of 2026-06-05.
CVSS vector meaningCVSS: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 versionsGoogle Chrome on macOS before 149.0.7827.53.
Fixed versionUpgrade macOS Chrome to 149.0.7827.53 or later.
Exposure realityThis 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.
DisclosureUser-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 patternMultiple 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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.1/10)

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.

MEDIUM Severity downgrade from vendor HIGH to noisgate MEDIUM
HIGH Assessment that this is a chained browser sandbox-escape pattern, not a one-click standalone compromise

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:H and UI:R are 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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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.
  3. Hunt for suspicious Chrome child-process behavior — Tune EDR detections for Google Chrome spawning 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as browser fleet hygiene with chain-aware priority, not as an all-hands zero-day event. Verify which managed Macs still run Chrome below 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

  1. Chrome Releases - Early Stable Update for Desktop
  2. Canadian Centre for Cyber Security AV26-544
  3. NVD - CVE-2026-7967
  4. NVD - CVE-2026-10000
  5. NVD - CVE-2026-8517
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS API
  8. Google Chrome Help - Update Google Chrome
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.