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

Inappropriate implementation in GPU in Google Chrome on Mac prior to 149

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

This is less a front-door break-in than a peep-hole drilled through Chrome's same-origin wall

CVE-2026-11203 is a GPU-path policy bypass / cross-origin data leak in Google Chrome on macOS. Google’s CNA record says versions before 149.0.7827.53 are affected; the June 2, 2026 stable release moved Chrome 149 to 149.0.7827.53/54 on Windows/Mac. The attack is delivered through a crafted HTML page and the stated impact is cross-origin data disclosure, not code execution or sandbox escape.

The vendor’s MEDIUM 6.5 is directionally right, but still a little generous for enterprise prioritization. The attack requires user interaction, is Mac-only, yields confidentiality impact only, has no KEV listing, very low EPSS, and there is no public exploitation signal in the sources reviewed. Browser ubiquity keeps it from dropping into noise, but the real-world friction clearly pushes it below anything you would treat like a browser RCE.

"Real bug, but it needs a Mac Chrome user to browse into it and the payoff is data leakage, not code execution."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Host lure content

The attacker prepares a malicious page that exercises the vulnerable GPU code path and attempts to trigger a same-origin policy bypass. This is a classic browser-delivered attack: no shell, no auth, just web content rendered by Chrome.
Conditions required:
  • Attacker can get the victim to visit a URL or load attacker-controlled web content
  • Victim uses Google Chrome on macOS
  • Victim is running a version older than 149.0.7827.53
Where this breaks in practice:
  • Requires successful phishing, ad-tech placement, or compromised legitimate content
  • Windows/Linux fleets are out of scope for this CVE
  • Auto-updating browsers shrink the vulnerable population quickly
Detection/coverage: Web proxy, DNS, and secure web gateway telemetry may catch the lure domain, but endpoint scanners generally cannot prove exploitability from network logs alone.
STEP 02

Reach the GPU path

Chrome must process the crafted content through the affected GPU-related implementation on macOS. In practice that means the victim browser has to hit the specific rendering path the bug lives in, which is narrower than a generic page-load issue.
Conditions required:
  • The page reaches the relevant GPU-backed rendering path
  • Hardware acceleration / normal GPU functionality is available
Where this breaks in practice:
  • Temporary admin policy can disable hardware acceleration on managed Macs
  • Not every page view will necessarily touch the vulnerable path
  • Browser feature and hardware combinations reduce reliable exploit reach
Detection/coverage: Version scanners can identify vulnerable Chrome builds; exploit-path detection is weak because the vulnerable condition sits inside browser rendering behavior.
STEP 03

Bypass cross-origin boundary

If successful, the bug lets attacker-controlled content access data it should not be allowed to read from another origin. That is a browser trust-boundary failure with a confidentiality outcome; there is no stated ability to execute native code, escape the sandbox, or persist.
Conditions required:
  • The victim has useful authenticated or sensitive cross-origin browser state
  • The target web application exposes data that becomes reachable through the bypass
Where this breaks in practice:
  • Chrome Site Isolation and related browser-side cross-site defenses reduce the amount of sensitive data delivered across processes in many cases
  • Impact depends on what the victim is logged into at that moment
  • Some SaaS apps also layer application-side CSRF/CORS/response hardening that limits harvest value
Detection/coverage: This is hard for EDR to see cleanly; browser crash telemetry and anomalous browser network egress to attacker infrastructure are more realistic clues than signature detection.
STEP 04

Exfiltrate stolen data

Any data obtained through the bypass can be returned to attacker infrastructure over normal browser network channels. The practical blast radius is the victim’s browser session and whatever cross-origin data the specific exploit can expose.
Conditions required:
  • Attacker-controlled origin can receive exfiltrated data
  • Victim session contains valuable target data
Where this breaks in practice:
  • No direct host takeover from this CVE alone
  • Blast radius is typically user-session scoped, not fleet-wide
  • Content filtering and egress monitoring can still reveal suspicious follow-on traffic
Detection/coverage: SWG/CASB, DLP, and proxy logs may catch suspicious POSTs or beaconing to attacker domains; vulnerability scanners only tell you the version is old.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation found in reviewed sources. Google’s June 2, 2026 Chrome 149 release notes do not call out active exploitation for this CVE, unlike Chrome zero-days when Google usually says so explicitly.
Public PoC availabilityNo public PoC located in GitHub/advisory references reviewed. The Chromium issue exists as issue 505192638, but bug details are still restricted.
EPSSVery low: user-supplied EPSS was 0.00028; current advisory mirrors show roughly 0.00035 / 11th percentile. Either way, this sits in the *low-likelihood* bucket for near-term mass exploitation.
KEV statusNot KEV-listed as checked against the current CISA KEV catalog on 2026-06-05.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N = remote delivery, no privileges, but user interaction required and confidentiality-only impact. That aligns with a browser data-leak bug, not a takeover bug.
Affected versionsChrome on macOS before 149.0.7827.53 per the CNA text. This is a Mac-only condition, which materially cuts enterprise exposure versus a full desktop Chrome issue.
Fixed versionsChrome 149 stable shipped on 2026-06-02 as 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). For this CVE, treat 149.0.7827.53+ on Mac as the fixed floor and prefer current stable.
Scanning / exposure dataInternet census tools are mostly irrelevant here. This is a client-side browser bug, not a server listener; Shodan/Censys-style counts do not map cleanly to risk. *Inference:* your real exposure population is managed Mac endpoints with stale Chrome builds.
Disclosure timelineCVE record published 2026-06-04; Chrome 149 stable release containing the fix was announced 2026-06-02; GitHub advisory published 2026-06-05.
Reporter / classification nuanceGoogle credits the bug as reported by Google on 2026-04-22. Chrome’s own release notes classify it as "Policy bypass in GPU", while the supplied metadata maps the outcome to CWE-200 because the end effect is unauthorized data exposure.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (5.1/10)

The single biggest downward pressure is attack-chain friction: this requires a Mac user on stale Chrome to browse attacker content, and the stated impact is cross-origin data leakage only. That is real enterprise risk, especially against SaaS sessions, but it is not a browser RCE and it does not justify panic patching absent exploitation evidence.

HIGH Affected platform/version scope is Mac Chrome before 149.0.7827.53
MEDIUM Operational exploitability and practical blast radius without bug details

Why this verdict

  • Mac-only scope cuts the population: this is not a full Chrome desktop problem; Windows and Linux fleets are out of scope for this CVE, which materially reduces reachable enterprise exposure.
  • User interaction is mandatory: the attacker needs the victim to render a crafted page, which implies phishing, malicious ad traffic, or compromised content delivery rather than direct unauthenticated reach.
  • Impact is confidentiality-only: the published effect is cross-origin data leakage, not arbitrary code execution, sandbox escape, persistence, or host compromise.
  • No live-fire pressure: no KEV entry, no public exploitation signal in the reviewed sources, and EPSS is extremely low, so there is no evidence this is becoming a broad operational threat right now.
  • Chrome already has defense layers: Site Isolation and related cross-site data delivery protections on desktop Chrome reduce the chance that a same-origin bypass becomes a broad unrestricted data vacuum; that does not kill the bug, but it limits worst-case assumptions.

Why not higher?

To score this as HIGH, I would want either active exploitation, a public reliable PoC, or an impact profile that includes code execution / sandbox escape / account compromise at scale. We do not have that here. The chain is narrowed by platform, by required user action, and by the fact that the payoff is data disclosure inside browser trust boundaries rather than device takeover.

Why not lower?

It is still a remote browser bug against a massively deployed client, and the victim only has to browse to hostile content. For the right target, a same-origin bypass can expose sensitive SaaS or intranet session data, which is too consequential to dismiss as backlog lint. MEDIUM is the right landing zone: real, patch-worthy, but not an emergency.

05 · Compensating Control

What to do — in priority order.

  1. Force Chrome auto-update and relaunch — Use your browser management stack to verify that managed Macs are taking current stable Chrome and actually relaunching into the new build. For a MEDIUM verdict there is no mitigation SLA, so use normal change control, but complete the actual browser update within the 365-day remediation window.
  2. Disable hardware acceleration on exception Macs — If a subset of Macs cannot patch promptly, temporarily set HardwareAccelerationModeEnabled=false through Chrome Enterprise policy to reduce exposure to the affected GPU path. This is a containment move for exceptions only; there is no mitigation SLA for MEDIUM, so use it where patch lag is real and performance trade-offs are acceptable.
  3. Target high-risk browsing groups first — Prioritize security admins, executives, finance, deal teams, and users with broad SaaS access because the practical impact is session-bound data leakage. Even without a formal mitigation deadline, use this focus to shrink business blast radius while routine browser updating completes inside the 365-day remediation window.
  4. Keep web filtering and phishing controls tuned — Because exploitation starts with a crafted page, secure web gateways, DNS filtering, and browser isolation controls can reduce how often users ever reach weaponized content. For this MEDIUM item these are supporting measures, not a substitute for patching.
What doesn't work
  • EDR alone does not solve this well because browser-side same-origin/policy bypasses can exfiltrate data without obvious process-level malware behavior.
  • Network segmentation is mostly beside the point; the trigger is hostile web content rendered by the user’s browser, not lateral movement to an internal service.
  • WAF on your apps is not a complete answer because the broken trust boundary is inside the client browser. App-layer defenses may reduce exposed data, but they do not remove the vulnerable browser condition.
  • Ignoring non-Mac assets only is correct, but ignoring stale managed Macs because the vendor called it MEDIUM is not; your real exposure sits exactly there.
06 · Verification

Crowdsourced verification payload.

Run this on the target Mac endpoint or through your Mac management/remote shell tooling. Invoke it with bash check_cve_2026_11203_chrome_mac.sh; it needs no root privileges and returns exit code 0 for PATCHED, 1 for VULNERABLE, and 2 for UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# check_cve_2026_11203_chrome_mac.sh
# Verifies whether Google Chrome on macOS is vulnerable to CVE-2026-11203
# Affected: Google Chrome on macOS before 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

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

verlte() {
  [ "$1" = "$2" ] && return 0
  local first
  first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
  [ "$first" = "$1" ]
}

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

if [ ! -d "$CHROME_APP" ]; then
  echo "UNKNOWN: Google Chrome.app not found in /Applications."
  exit 2
fi

if [ ! -f "$PLIST" ]; then
  echo "UNKNOWN: Chrome Info.plist not found."
  exit 2
fi

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

if [ -z "$VERSION" ]; then
  VERSION=$(/usr/bin/defaults read "$PLIST" KSVersion 2>/dev/null || true)
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN: Unable to determine Chrome version."
  exit 2
fi

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

if [ "$VERSION" = "$FIXED_VERSION" ] || ! verlte "$VERSION" "$FIXED_VERSION"; then
  echo "PATCHED: Google Chrome version $VERSION is at or above fixed version $FIXED_VERSION."
  exit 0
fi

echo "UNKNOWN: Unable to compare version $VERSION to fixed version $FIXED_VERSION."
exit 2
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, scope this to managed Macs only and validate how many are still below 149.0.7827.53. Because this is a MEDIUM reassessment with no KEV or active exploitation evidence, there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, for a browser, you should use your next normal Chrome maintenance cycle to force update/relaunch and clean up pinned or exception devices. If some Macs cannot patch promptly, temporarily disable Chrome hardware acceleration on those exceptions while you finish rollout, then complete patching within the noisgate remediation SLA of ≤ 365 days.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
  2. GitHub Advisory Database: GHSA-793m-2h6c-59w8
  3. CIRCL Vulnerability Lookup: CVE-2026-11203
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and report
  6. Chromium Site Isolation overview
  7. Chrome Enterprise policy: HardwareAccelerationModeEnabled
  8. Chrome for Testing availability (149.0.7827.53 assets)
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.