This is the second lock on the door failing after the intruder is already inside the hallway
CVE-2026-11028 is a use-after-free in Chrome Media affecting Google Chrome on Linux and ChromeOS before 149.0.7827.53. The key phrase in the description matters more than the generic CVSS: the attacker must have already compromised the renderer process and then use a crafted page or media path to turn that foothold into a sandbox escape on the affected platforms.
paragraphs_vendor_note_placeholder
3 steps from start to impact.
Land code execution in the renderer with a separate bug
- User visits attacker-controlled content
- A separate renderer compromise exists and works against the target build
- Target is running Linux or ChromeOS
- This prerequisite alone means the attacker is already partway through a full browser-exploit chain
- Modern Chrome hardening, site isolation, and renderer mitigations reduce reliable first-stage compromise
- Enterprise browser auto-update shrinks dwell time on workable chains
Trigger the Media use-after-free from inside the compromised renderer
- Renderer compromise is stable enough to drive follow-on primitives
- Vulnerable Media code path is reachable on the target platform/build
- Chrome version is older than 149.0.7827.53
- Exploit reliability for UAF-based sandbox escapes is highly build- and heap-shape-dependent
- Linux and ChromeOS only: this excludes Windows and macOS desktop populations
- Per-release allocator and sandbox changes can break exploit portability
Escape sandbox containment
- Successful memory corruption with controlled post-free behavior
- A viable escape path against the active Linux/ChromeOS sandbox profile
- Even successful renderer exploitation does not guarantee a reliable sandbox escape
- ChromeOS in particular layers browser sandboxing with an OS model that narrows easy post-exploitation options
- Privileged follow-on actions still depend on local posture and user context
The supporting signals.
| In-the-wild status | No confirmed active exploitation in the supplied intel, and not listed in CISA KEV as of the catalog state reviewed. |
|---|---|
| Proof-of-concept availability | No public PoC located for this exact CVE during review. That matters because sandbox-escape reliability usually lags advisory publication. |
| EPSS | 0.0008 (~0.08%) from the supplied intel — effectively background noise, which fits a chain-only browser bug better than a mass-exploitable edge flaw. |
| KEV status | Not KEV-listed. No emergency override triggered. |
| CVSS vector reality check | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H overstates the operational story because it scores the browser issue as if it were a direct remote compromise. The description's renderer-compromised prerequisite adds major real-world friction. |
| Affected versions | Chrome on Linux and ChromeOS prior to 149.0.7827.53. |
| Fixed version | 149.0.7827.53 or later. For ChromeOS, the browser fix lands via the corresponding OS/browser channel update rather than a standalone browser package. |
| Exposure population | This is a client-side browser flaw, so Shodan/Censys/FOFA-style internet exposure data is not meaningful. Reachability depends on users browsing hostile content, not on a listening service. |
| Disclosure date | 2026-06-04 per the supplied intel and vendor release timing. |
| Weakness / researcher | CWE-416 Use After Free. I did not locate a publicly attributable reporter for this exact CVE in the sources reviewed. |
noisgate verdict.
The decisive factor is the attacker position requirement: this bug only matters after the renderer is already compromised, so it is not an initial-access vulnerability for the enterprise. That makes it a valuable exploit-chain component, but not the kind of bug that justifies emergency treatment across a 10,000-host fleet absent KEV, PoC, or active campaign evidence.
Why this verdict
- Start from vendor 8.8, then cut hard for prerequisite: this is not internet-to-host by itself; the attacker must already have renderer code execution.
- Platform narrowing matters: affected scope is Linux and ChromeOS, not the full desktop Chrome estate, so exposed population is materially smaller.
- No heat around it: no KEV, no public PoC found, and the supplied EPSS 0.0008 is extremely low.
- Modern controls should break the chain earlier: browser isolation, crash telemetry, EDR, and rapid auto-update are more likely to stop or surface the preceding renderer exploit than an edge service would be.
Why not higher?
Because the vulnerability assumes a prior compromise stage, it is compounding rather than initiating attacker success. In enterprise terms, this is a chain amplifier for already-sophisticated browser exploitation, not a mass-reachable remote entry point.
Why not lower?
A working sandbox escape in Chrome still has serious endpoint impact, especially on Linux admin workstations and sensitive ChromeOS roles. If an attacker already has renderer execution, this bug can meaningfully raise privileges and break containment, so it is not mere hygiene.
What to do — in priority order.
- Keep Linux and ChromeOS on rapid browser auto-update — For a MEDIUM verdict there is no mitigation SLA; keep this in the normal browser-update ring and complete vendor remediation within the 365-day window. Auto-update matters more here than bespoke blocking because exploitability is tightly coupled to exact build versions.
- Harden risky browsing tiers — Apply stricter browsing isolation or separate profiles for privileged Linux users, kiosks, and internet-facing research roles. There is no mitigation SLA — go straight to remediation planning, but reducing hostile-content exposure lowers the odds that a first-stage renderer exploit ever lands.
- Watch for renderer crash bursts — Use EDR, browser crash telemetry, and SOC correlation to flag repeated Chrome child-process crashes and sandbox anomalies on Linux/ChromeOS. This does not replace patching, but it is the most practical way to spot exploit-chain activity while you remediate inside the 365-day window.
- Perimeter scanning doesn't help: this is a client-side browser issue, not a remotely enumerable daemon.
- MFA doesn't help: authentication controls are irrelevant once a user is convinced to browse attacker-controlled content.
- A generic network IPS rule is weak here: the vulnerable trigger is embedded in normal browser content flows and typically rides over HTTPS.
Crowdsourced verification payload.
Run this on the target Linux or ChromeOS endpoint locally, or via your fleet agent/SSH. Invoke it as bash check_chrome_cve_2026_11028.sh; no root is required, but the script needs permission to execute the installed Chrome binary if it lives under a restricted path.
#!/usr/bin/env bash
# check_chrome_cve_2026_11028.sh
# Detects whether local Google Chrome / Chromium build is older than 149.0.7827.53
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED_VERSION="149.0.7827.53"
FOUND_VERSION=""
FOUND_BIN=""
CANDIDATES=(
"google-chrome"
"google-chrome-stable"
"chromium"
"chromium-browser"
"/opt/google/chrome/chrome"
"/usr/bin/google-chrome"
"/usr/bin/google-chrome-stable"
"/usr/bin/chromium"
"/usr/bin/chromium-browser"
)
get_version() {
local bin="$1"
local raw
raw="$($bin --product-version 2>/dev/null || $bin --version 2>/dev/null)" || return 1
echo "$raw" | grep -Eo '[0-9]+(\.[0-9]+){3}' | head -n1
}
ver_lt() {
# returns 0 if $1 < $2
[ "$1" = "$2" ] && return 1
local first
first=$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)
[ "$first" = "$1" ]
}
for bin in "${CANDIDATES[@]}"; do
if command -v "$bin" >/dev/null 2>&1; then
ver=$(get_version "$bin")
if [ -n "$ver" ]; then
FOUND_VERSION="$ver"
FOUND_BIN="$bin"
break
fi
elif [ -x "$bin" ]; then
ver=$(get_version "$bin")
if [ -n "$ver" ]; then
FOUND_VERSION="$ver"
FOUND_BIN="$bin"
break
fi
fi
done
if [ -z "$FOUND_VERSION" ]; then
echo "UNKNOWN - could not determine Chrome/Chromium version from common paths"
exit 2
fi
if ver_lt "$FOUND_VERSION" "$FIXED_VERSION"; then
echo "VULNERABLE - $FOUND_BIN version $FOUND_VERSION is older than fixed $FIXED_VERSION"
exit 1
else
echo "PATCHED - $FOUND_BIN version $FOUND_VERSION is at or newer than fixed $FIXED_VERSION"
exit 0
fi
If you remember one thing.
Sources
- Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
- Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
- CISA Known Exploited Vulnerabilities Catalog
- FIRST EPSS project
- MITRE CWE-416 Use After Free
- CVE.org record for analogous Chrome renderer-compromise-to-sandbox-escape pattern (CVE-2026-5288)
- NVD detail for analogous Chrome sandbox-escape phrasing (CVE-2026-8001)
- NVD detail for analogous Media-on-Linux/ChromeOS renderer-compromised bug (CVE-2026-8535)
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.