This is a spring-loaded trap behind a screen door, not an open vault
CVE-2026-10902 is a CWE-416 use-after-free in Chromium's Ozone layer. Google fixed it in the Chrome 149 stable release published on 2026-06-02, with patched versions 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac; versions before those builds are affected. A remote attacker would deliver a crafted HTML page and rely on the victim to render attacker-controlled content in a vulnerable browser.
On paper this looks like classic browser RCE, but the vendor score overstates patch urgency for enterprise triage. The decisive downgrade is real-world friction: user interaction is required, the first-stage win lands inside Chrome's sandboxed multi-process architecture, and Ozone is documented as an Ozone-targeted platform layer for Linux/ChromeOS/Fuchsia. That makes this a serious, chainable client bug, not an automatic workstation-owning emergency.
4 steps from start to impact.
Deliver the lure page
- Target is running Chrome prior to
149.0.7827.53on an affected code path - Victim browses to attacker-controlled content
- Attacker can shape renderer heap state through HTML/JS
- Requires user interaction (
UI:R) - Email gateway, secure web gateway, browser reputation, and user training all reduce delivery success
- No internet-exposed service to hit directly
Trigger the Ozone use-after-free
- The vulnerable Ozone code path is present and reachable on that host
- The page can induce the object lifetime error reliably enough to corrupt memory
- Ozone meaningfully narrows the affected population versus 'all Chrome everywhere'
- Memory corruption reliability varies by platform, allocator state, and hardening
chrome_debug.log, or crash telemetry spikes.Convert memory corruption into code execution
- Attacker can turn the corrupted state into controlled instruction flow or a meaningful primitive
- Modern mitigations do not break exploit reliability
- Chrome's sandbox, process isolation, and exploit mitigations raise the bar
- A crash-only outcome is common for immature browser exploits
- No public PoC was found during review
Escape the sandbox for host impact
- Attacker has a working first-stage browser exploit
- A second bug or privilege boundary bypass exists in the environment
- This is a compounding prerequisite that sharply reduces real-world impact
- EDR, OS mitigations, and Chrome broker checks should disrupt many chains
- No active exploitation signal suggests a mature exploit chain is circulating
- A perimeter vulnerability scan will not save you here; this is a client-side browser flaw, not a listening service.
- A generic WAF is mostly irrelevant because the exploit lands in the victim's browser after content is delivered, often from otherwise legitimate sites or redirects.
- Relying on CVSS alone overstates urgency because it ignores the user-interaction, platform-scope, and sandbox-escape friction that dominate the real attack chain.
The supporting signals.
| Vendor publication | Google's stable release notes list the fix on 2026-06-02. Your intel says 2026-06-04; that likely reflects downstream feed timing, not the vendor's first public fix date. |
|---|---|
| Severity mismatch | Google's Chrome release notes label CVE-2026-10902 as Critical, while your upstream intel block says HIGH 8.8. For patch triage, both labels overshoot the operational reality because they do not price in the sandbox + platform-friction chain. |
| Affected versions | Google Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/Mac, per the Chrome 149 stable release post. |
| Fixed versions | Upstream fix shipped in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/Mac). For distro-packaged Chromium, trust the distro advisory/changelog if it backports the patch under a lower marketing version. |
| Component reach | Chromium's current Ozone documentation says IS_OZONE targets Linux, ChromeOS, and Fuchsia. *Inference:* that makes this materially narrower than a generic 'all Chrome desktop users' browser bug. |
| In-the-wild status | No KEV listing and no vendor statement located saying Google is aware of exploitation. *Inference:* there is no public exploitation signal as of this review, but absence of evidence is not evidence of absence. |
| Public PoC | No public PoC repository or write-up surfaced in a GitHub search for CVE-2026-10902 during review. |
| EPSS | EPSS in your intel block is 0.0008, which is extremely low and consistent with a bug that is technically dangerous but not yet showing broad exploitation likelihood. |
| CVSS interpretation | Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H captures easy remote delivery but does not capture the need for a user click, exploit reliability work, or the likely need for a sandbox escape to turn first-stage code exec into host compromise. |
| Scanning/exposure reality | Internet-wide scanners like Shodan/Censys/FOFA are poor signal here because this is a client-side browser flaw, not a listening service. Exposure should be measured from fleet inventory, package telemetry, and browser management data instead. |
Sources.
Why this verdict
- Downgrade 1 — Ozone narrows the target pool: Chromium's Ozone docs indicate
IS_OZONEtargets Linux/ChromeOS/Fuchsia, which is materially smaller than the full Chrome desktop population implied by a generic browser CVSS. - Downgrade 2 — user-driven delivery: The attacker still needs a victim to render a crafted page. That means web filtering, reputation controls, and user behavior all add real-world friction before the bug is ever touched.
- Downgrade 3 — sandboxed first-stage impact: Chrome's renderer/process isolation means the first successful memory-corruption stage is likely contained. Host-level compromise usually requires a second bug or boundary bypass.
- Downgrade 4 — weak threat signal: KEV is negative, EPSS is extremely low, and no public PoC surfaced. That does not make the bug harmless, but it argues strongly against emergency-tier prioritization.
Why not higher?
There is no credible public signal of active exploitation, and the path to meaningful enterprise damage is not one-step. The combination of UI:R, likely platform narrowing, and Chrome sandbox containment makes this a bad bug to patch in routine browser cadence—not a lights-on-fire fleet emergency.
Why not lower?
This is still a remote, no-auth, memory-corruption browser vulnerability delivered over ordinary web content. If you have a meaningful Linux/ChromeOS population, a determined attacker can target it at scale, and browser bugs remain valuable as first-stage footholds in multi-bug chains.
Crowdsourced verification payload.
Run this on the target Linux or ChromeOS host whose browser you want to assess. Invoke it as bash check_cve_2026_10902.sh /usr/bin/google-chrome or just bash check_cve_2026_10902.sh; it needs only normal user rights as long as the browser binary is executable.
#!/usr/bin/env bash
# check_cve_2026_10902.sh
# Determine likely exposure to CVE-2026-10902 on Linux/ChromeOS Chrome-family browsers.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED_VERSION="149.0.7827.53"
TARGET="${1:-}"
candidates=(
"$TARGET"
"/usr/bin/google-chrome"
"/usr/bin/google-chrome-stable"
"/usr/bin/chromium"
"/usr/bin/chromium-browser"
"/opt/google/chrome/chrome"
)
find_browser() {
local c
for c in "${candidates[@]}"; do
[ -n "$c" ] || continue
if [ -x "$c" ]; then
echo "$c"
return 0
fi
done
return 1
}
normalize_version() {
# Keep only first numeric dotted quad-like string.
echo "$1" | grep -Eo '[0-9]+(\.[0-9]+){2,3}' | head -n1
}
ver_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}
BROWSER="$(find_browser)" || {
echo "UNKNOWN - no Chrome/Chromium binary found in expected paths"
exit 2
}
RAW_OUT="$($BROWSER --version 2>/dev/null || true)"
VERSION="$(normalize_version "$RAW_OUT")"
if [ -z "$VERSION" ]; then
echo "UNKNOWN - could not parse browser version from: $RAW_OUT"
exit 2
fi
case "$(uname -s 2>/dev/null || echo unknown)" in
Linux) : ;;
*)
echo "UNKNOWN - script logic is intended for Linux/ChromeOS style targets; detected $(uname -s 2>/dev/null || echo unknown)"
exit 2
;;
esac
if ver_lt "$VERSION" "$FIXED_VERSION"; then
echo "VULNERABLE - $BROWSER version $VERSION is older than fixed $FIXED_VERSION"
exit 1
else
echo "PATCHED - $BROWSER version $VERSION is at or above fixed $FIXED_VERSION"
exit 0
fi