This is a peephole in a side room, not a front door into the building
CVE-2026-11033 is an uninitialized-use bug in Chrome's WebML component on macOS. The public description says Chrome on Mac prior to 149.0.7827.53 could let a remote attacker read potentially sensitive data after a user loads crafted web content. Practically, this is a browser-process information disclosure issue, not code execution, and the impacted slice is already narrow because the vendor record is Mac-specific.
Google scored it MEDIUM 6.5, which is defensible in a vacuum for a remote client-side info leak with user interaction. In enterprise reality, that score is still a bit generous: the affected surface appears tied to Chrome's machine-learning web feature set, and Chromium exposes WebNN/WebML functionality behind flags/experimental features, which sharply reduces real-world reach. Mac-only plus user interaction plus likely feature-gating is compounding friction, so this lands as LOW for most fleets.
4 steps from start to impact.
Land the victim on crafted content
- Victim uses Google Chrome on macOS
- Chrome version is older than 149.0.7827.53
- Victim opens attacker-controlled web content
- Requires user interaction (
UI:R) - Enterprise web filtering, Safe Browsing, email security, and user behavior all suppress this stage
Reach the WebML/WebNN code path
- The relevant WebML/WebNN capability is enabled and reachable on the target Mac
- The malicious page successfully exercises that API path
- Feature-gated or experimental surfaces are rarely enabled across managed enterprise fleets
- If admins restrict flags or users never enable experimental features, the chain dies here
Trigger uninitialized memory use
- Browser reaches the vulnerable code path without crashing first
- Memory layout is favorable enough to leak useful bytes
- Uninitialized-use bugs are often noisy, brittle, and less deterministic than straight read primitives
- Even successful leakage may return low-value or non-reusable data
Extract useful data
- Leaked bytes contain sensitive information
- Exfiltration channel is not blocked
- Sandboxing and same-site isolation limit what a single leak directly buys
- Without a companion bug, this is usually not a one-click full-host compromise
The supporting signals.
| In-the-wild status | No authoritative evidence of active exploitation found in reviewed sources, and not listed in CISA KEV. |
|---|---|
| PoC availability | No public PoC for CVE-2026-11033 was located in reviewed sources. Google commonly withholds bug details during rollout, which reduces immediate copy-paste exploitation. |
| EPSS | 0.00032 per the user-supplied intel sourced from FIRST upstream; that is very low threat probability. I could not verify an authoritative percentile in the reviewed sources. |
| KEV status | Not KEV-listed as of the reviewed CISA catalog. No KEV add date because there is no entry. |
| CVSS vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — remote and low complexity, but user interaction is mandatory and the impact is limited to confidentiality. |
| Affected versions | Google Chrome on macOS prior to 149.0.7827.53. |
| Fixed version | Patch level is 149.0.7827.53 for the affected Mac build; Google's early stable post announced 149.0.7827.53/.54 for Windows and Mac rollout. |
| Exposure reality | This is a client-side browser flaw, so Shodan/Censys/FOFA-style internet census data is largely irrelevant. Exposure must be measured from fleet inventory: macOS hosts, Chrome version, and whether experimental ML-related browser features are enabled. |
| Feature-gating signal | Chromium documents WebNN API as a browser flag, with extra capabilities behind experimental WebNN features. That is strong downward pressure on enterprise-wide reachable population. |
| Disclosure timeline | User-supplied disclosure date is 2026-06-04. Google posted the early stable desktop update on 2026-05-29, noting rollout to a small percentage of users first. |
noisgate verdict.
The decisive factor is reachable population: this appears tied to a machine-learning browser surface that Chromium exposes through flags and experimental feature controls, not a universal always-on parser path. Once you combine that with Mac-only scope and mandatory user interaction, the real enterprise blast radius collapses fast.
Why this verdict
- Flag-gated surface cuts the population: Chromium exposes WebNN via browser flags and additional experimental features, so this is not the same as an always-on browser parser bug hitting every seat.
- Mac-only narrows your fleet: Windows and Linux are out of scope for this CVE description, which immediately removes a large chunk of most enterprises.
- User interaction is mandatory: the attacker still needs a victim to open crafted content, which means secure email, Safe Browsing, proxies, and user behavior all get a chance to break the chain.
- Confidentiality-only impact: the published vector is info disclosure, not code execution or sandbox escape, so the blast radius per successful hit is lower than the scary 'remote browser bug' label suggests.
- Threat intel is cold: not KEV-listed and the provided EPSS is extremely low, which argues against emergency handling.
Why not higher?
This is not a broad unauthenticated server-side exposure and not a one-shot RCE. The attack needs a user to browse to hostile content, only affects macOS, and appears to depend on a ML-related browser surface that is likely disabled in the vast majority of managed fleets.
Why not lower?
It is still a remotely triggerable browser vulnerability with no attacker privileges required before delivery. If you do have Mac developer populations or labs that enable experimental browser features, the reachable subset is small but not imaginary.
What to do — in priority order.
- Inventory Mac Chrome versions — Use your endpoint inventory or browser management stack to identify macOS Chrome < 149.0.7827.53. Because this is a LOW verdict, there is no SLA (treat as backlog hygiene); fold the check into your normal browser hygiene cycle and prioritize only if the host also enables experimental ML/browser flags.
- Block experimental browser features — Use managed browser policy to prevent users from enabling experimental features and ad-hoc flags where your fleet management supports it. This is the best risk reducer because the main downward pressure here is likely feature reachability; for LOW, there is no SLA (treat as backlog hygiene).
- Keep Safe Browsing and web filtering enforced — This bug still needs hostile content delivery, so URL filtering, phishing controls, and DNS/web proxy enforcement remain relevant. They do not fix the bug, but they reduce the only realistic entry path; for LOW, maintain through normal control operations with no separate SLA.
- Watch high-risk Mac user groups — If you have developers, researchers, or power users on managed Macs who routinely enable beta/experimental browser features, tag them as the only subgroup worth elevated attention. For LOW, there is no SLA (treat as backlog hygiene), but this subgroup should be rolled into the next standard browser update wave.
- A perimeter vulnerability scanner will not tell you who is truly exposed, because this is a client-side browser bug and the key precondition is local browser configuration, not an open port.
- A WAF is mostly irrelevant; there is no enterprise-owned web app to shield here, and the attack arrives as ordinary web content to the client.
- Network segmentation does little because the initial path is user browsing, not lateral movement into a server service.
Crowdsourced verification payload.
Run this on the target Mac host where Chrome is installed, not on an auditor workstation. Invoke it as bash check_chrome_cve_2026_11033.sh or save and run directly; no admin rights are required. It checks whether the host is macOS, locates Google Chrome, reads the installed version, and compares it to the fixed build 149.0.7827.53.
#!/bin/bash
# check_chrome_cve_2026_11033.sh
# Detects likely exposure to CVE-2026-11033 on macOS based on installed Google Chrome version.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED_VERSION="149.0.7827.53"
CHROME_BIN="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
verlte() {
[ "$1" = "$2" ] && return 0
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}
vergte() {
[ "$1" = "$2" ] && return 0
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}
if [ "$(uname -s)" != "Darwin" ]; then
echo "UNKNOWN: CVE-2026-11033 is described as macOS-specific; this host is not macOS."
exit 2
fi
if [ ! -x "$CHROME_BIN" ]; then
echo "UNKNOWN: Google Chrome not found at $CHROME_BIN"
exit 2
fi
RAW_VERSION="$($CHROME_BIN --version 2>/dev/null)"
INSTALLED_VERSION="$(echo "$RAW_VERSION" | sed -E 's/.* ([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+).*/\1/')"
if [ -z "$INSTALLED_VERSION" ] || ! echo "$INSTALLED_VERSION" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$'; then
echo "UNKNOWN: Unable to parse Chrome version from: $RAW_VERSION"
exit 2
fi
if verlte "$INSTALLED_VERSION" "$FIXED_VERSION" && [ "$INSTALLED_VERSION" != "$FIXED_VERSION" ]; then
echo "VULNERABLE: Google Chrome $INSTALLED_VERSION on macOS is older than fixed version $FIXED_VERSION"
exit 1
fi
if vergte "$INSTALLED_VERSION" "$FIXED_VERSION"; then
echo "PATCHED: Google Chrome $INSTALLED_VERSION on macOS is at or above fixed version $FIXED_VERSION"
exit 0
fi
echo "UNKNOWN: Version comparison failed for installed version $INSTALLED_VERSION"
exit 2
If you remember one thing.
Sources
- Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Chrome for Developers - What are Chrome flags?
- Chromium source - flag_descriptions.cc (WebNN API and experimental WebNN features)
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS API documentation
- Quanteta CVE Tracker entry for CVE-2026-11033
- VulDB CVE listing for CVE-2026-11033
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.