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.
4 steps from start to impact.
Host lure content
- 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
- 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
Reach the GPU path
- The page reaches the relevant GPU-backed rendering path
- Hardware acceleration / normal GPU functionality is available
- 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
Bypass cross-origin boundary
- The victim has useful authenticated or sensitive cross-origin browser state
- The target web application exposes data that becomes reachable through the bypass
- 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
Exfiltrate stolen data
- Attacker-controlled origin can receive exfiltrated data
- Victim session contains valuable target data
- 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
The supporting signals.
| In-the-wild status | No 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 availability | No public PoC located in GitHub/advisory references reviewed. The Chromium issue exists as issue 505192638, but bug details are still restricted. |
| EPSS | Very 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 status | Not KEV-listed as checked against the current CISA KEV catalog on 2026-06-05. |
| CVSS vector | CVSS: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 versions | Chrome 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 versions | Chrome 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 data | Internet 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 timeline | CVE 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 nuance | Google 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. |
noisgate verdict.
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.
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.
What to do — in priority order.
- 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.
- Disable hardware acceleration on exception Macs — If a subset of Macs cannot patch promptly, temporarily set
HardwareAccelerationModeEnabled=falsethrough 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. - 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.
- 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.
EDR alonedoes not solve this well because browser-side same-origin/policy bypasses can exfiltrate data without obvious process-level malware behavior.Network segmentationis 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 appsis 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 onlyis correct, but ignoring stale managed Macs because the vendor called it MEDIUM is not; your real exposure sits exactly there.
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.
#!/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
If you remember one thing.
Sources
- Chrome Releases: Stable Channel Update for Desktop (Chrome 149)
- GitHub Advisory Database: GHSA-793m-2h6c-59w8
- CIRCL Vulnerability Lookup: CVE-2026-11203
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS data and report
- Chromium Site Isolation overview
- Chrome Enterprise policy: HardwareAccelerationModeEnabled
- Chrome for Testing availability (149.0.7827.53 assets)
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.