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

Uninitialized Use in WebML in Google Chrome on Mac prior to 149

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

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.

"Remote browser bug, but the real exposure is tiny: Mac-only, user-driven, and likely flag-gated"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on crafted content

The attacker uses a phishing link, malvertising, or compromised site to get a Mac user onto a page that drives the vulnerable browser code path. The weaponized content is just browser-delivered HTML/JavaScript; no foothold on the endpoint is needed before the click.
Conditions required:
  • Victim uses Google Chrome on macOS
  • Chrome version is older than 149.0.7827.53
  • Victim opens attacker-controlled web content
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Enterprise web filtering, Safe Browsing, email security, and user behavior all suppress this stage
Detection/coverage: Broadly detectable only at the delivery layer: proxy, DNS, email, browser telemetry. Vulnerability scanners can inventory version, but they will not see exploit intent from version alone.
STEP 02

Reach the WebML/WebNN code path

The exploit page must invoke the machine-learning web feature set associated with the vulnerable component. In Chromium, WebNN is explicitly exposed as a browser flag and additional functionality is behind experimental feature toggles, which suggests the reachable population is much smaller than 'all Chrome users.'
Conditions required:
  • The relevant WebML/WebNN capability is enabled and reachable on the target Mac
  • The malicious page successfully exercises that API path
Where this breaks in practice:
  • 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
Detection/coverage: Most enterprise vuln tooling will miss this precondition unless you also collect browser policy, command-line flag, or profile-state telemetry.
STEP 03

Trigger uninitialized memory use

A crafted sequence of API calls causes Chrome to use uninitialized data in the vulnerable WebML path. The likely result is disclosure of nearby browser-process memory rather than direct integrity or availability impact.
Conditions required:
  • Browser reaches the vulnerable code path without crashing first
  • Memory layout is favorable enough to leak useful bytes
Where this breaks in practice:
  • 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
Detection/coverage: Behavioral detection is weak. Browser crash telemetry, renderer anomalies, or unusual API usage may be visible, but signature-grade network detection is poor.
STEP 04

Extract useful data

The attacker attempts to exfiltrate leaked process memory to recover tokens, page data, or other sensitive material. As disclosed, the bug is an information disclosure primitive; meaningful impact depends on what data is present and whether the attacker can operationalize it.
Conditions required:
  • Leaked bytes contain sensitive information
  • Exfiltration channel is not blocked
Where this breaks in practice:
  • 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
Detection/coverage: Network egress controls may catch outbound beacons; DLP may catch some content classes. Endpoint security is unlikely to label the root cause as this CVE.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo authoritative evidence of active exploitation found in reviewed sources, and not listed in CISA KEV.
PoC availabilityNo public PoC for CVE-2026-11033 was located in reviewed sources. Google commonly withholds bug details during rollout, which reduces immediate copy-paste exploitation.
EPSS0.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 statusNot KEV-listed as of the reviewed CISA catalog. No KEV add date because there is no entry.
CVSS vectorCVSS: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 versionsGoogle Chrome on macOS prior to 149.0.7827.53.
Fixed versionPatch 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 realityThis 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 signalChromium 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 timelineUser-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.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

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.

HIGH No KEV listing / no active exploitation evidence in reviewed sources
MEDIUM Feature-gating materially reduces exposed population
HIGH Mac-only affected version range

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.

05 · Compensating Control

What to do — in priority order.

  1. 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.
  2. 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).
  3. 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.
  4. 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.
What doesn't work
  • 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.
06 · Verification

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.

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

If you remember one thing.

TL;DR
Monday morning, do not treat this like a fleet-wide fire drill. Pull a quick inventory of macOS Chrome installs below 149.0.7827.53, then narrow further to any group allowed to run experimental browser features or custom Chrome flags. Because this is a LOW reassessment with no KEV or active exploitation evidence, there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene; document the rationale, remove experimental browser exposure where feasible, and absorb the actual browser update into the next standard maintenance cycle.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome for Developers - What are Chrome flags?
  3. Chromium source - flag_descriptions.cc (WebNN API and experimental WebNN features)
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. Quanteta CVE Tracker entry for CVE-2026-11033
  7. VulDB CVE listing for CVE-2026-11033
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.