This is a peephole in a side window, not a blown front door
CVE-2026-11051 is an out-of-bounds read in Chrome's ANGLE graphics layer affecting Google Chrome on Linux before 149.0.7827.53. A victim has to render attacker-controlled web content, and the likely outcome is memory disclosure from the affected process, not code execution or a sandbox escape. The CVE text and vendor vector both point to a crafted HTML page as the trigger, with confidentiality impact only.
Google's MEDIUM / 6.5 label is basically fair in product space, but for enterprise patch triage this lands lower because the attack chain is narrow in practice: Linux only, user interaction required, information leak only, and browser hardening like sandboxing and Site Isolation reduces blast radius. No KEV listing, no active exploitation evidence, and the supplied EPSS 0.00035 all argue against treating this like an emergency.
4 steps from start to impact.
Lure a Linux Chrome user to attacker HTML
- Victim is running affected Chrome on Linux
- Victim visits attacker-controlled or attacker-influenced content
- Enterprise policy has not blocked risky browsing paths
- Linux desktop population is usually much smaller than Windows/macOS in enterprises
- Web filtering, email security, and user behavior reduce page-load opportunities
- No value at all against users already updated to 149.0.7827.53 or later
Trigger the ANGLE out-of-bounds read
- The vulnerable graphics path is reachable on the target build
- The page reaches the relevant ANGLE handling path during rendering
- Renderer/GPU-path bugs can be brittle across hardware, drivers, and distro packaging
- Exploit reliability is lower than classic logic bugs because the issue leaks memory rather than granting direct control
Harvest process memory disclosure
- Valuable data is resident in the affected process at exploit time
- The attacker can turn leaked bytes into something operationally useful
- Disclosure-only impact sharply limits follow-on options compared with RCE
- Site Isolation and process separation reduce opportunities to read cross-site data broadly
- Leaked data may be noisy, partial, or stale
Convert leaked data into follow-on access
- Leaked material contains reusable secrets
- Those secrets are not bound to device, origin, or session controls
- The attacker has infrastructure to operationalize the data
- MFA, token binding, short session lifetimes, and reauthentication can blunt value
- Many successful disclosures will not produce directly reusable secrets
- A second bug is often required for materially worse impact
The supporting signals.
| In-the-wild status | No public evidence of active exploitation found in the cited sources; not KEV-listed. |
|---|---|
| KEV status | Absent from CISA's Known Exploited Vulnerabilities Catalog. |
| PoC availability | No authoritative public PoC located for CVE-2026-11051. Chromium bug reference exists, but the public issue page is access-restricted. |
| EPSS | Supplied intel says 0.00035. That is extremely low exploit-likelihood signal; percentile was not confirmed from authoritative output during this review. |
| CVSS vector meaning | CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N means remote reachability with user interaction required, confidentiality impact only, and no integrity or availability impact. |
| Affected versions | Google Chrome on Linux prior to 149.0.7827.53. |
| Fixed version | Vendor fix is Chrome 149.0.7827.53 for Linux via the stable channel release on 2026-06-02. |
| Exposure reality | This is a client-side browser flaw, so Shodan/Censys-style internet exposure counts are not meaningful. Exposure is your installed Linux Chrome fleet, not an internet-listenable service. |
| Disclosure timeline | Chrome stable release carrying the fix published 2026-06-02; NVD shows the CVE record published 2026-06-04. |
| Reporting / source | NVD references Chromium issue 498828605; public advisory language attributes the severity to Chromium security severity: Medium. |
noisgate verdict.
The single biggest downward driver is that this is a Linux-only, user-driven information disclosure bug rather than a server-side foothold or code-execution primitive. In real enterprise fleets that means smaller exposed population, lower reliability, and weaker attacker payoff unless it is chained with something else.
Why this verdict
- Linux-only population cut: vendor severity assumes the product matters; enterprise exposure drops materially when the vulnerable slice is only Linux Chrome endpoints.
- User interaction required: attacker position is not unauthenticated direct-to-host exploitation; they need the victim to browse to hostile content, which implies phishing/ad-tech/compromised-site delivery and gives email/web controls a chance to stop it.
- Disclosure, not takeover: the CVSS vector has confidentiality-only impact with no integrity or availability loss, so this is not a one-bug workstation compromise story.
- Browser hardening matters: Chrome sandboxing and Site Isolation apply real downward pressure by constraining cross-site data exposure and containing many renderer-class failures.
- Threat intel is quiet: no KEV listing, no confirmed public exploitation, and the supplied EPSS 0.00035 all say attackers are not prioritizing this right now.
Why not higher?
To justify MEDIUM or HIGH in a 10,000-host patch queue, I would want one of three amplifiers: active exploitation, broader platform reach, or impact beyond memory disclosure. This CVE has none of them in the cited record. It is also not externally scannable infrastructure; it only matters where users actively browse hostile content on affected Linux Chrome builds.
Why not lower?
It is still a remotely triggerable memory-safety flaw in a heavily exposed application class: the browser. Confidential data leakage from browser process memory can matter, especially on developer or admin Linux workstations with sensitive sessions open. So this is not 'ignore'; it belongs in normal browser maintenance.
What to do — in priority order.
- Force browser auto-update — Make sure Linux endpoints receive Chrome 149.0.7827.53 or later through your normal browser/package channel. For a LOW verdict there is no SLA (treat as backlog hygiene), but do not let unmanaged developer workstations drift indefinitely because browser bugs age badly.
- Restrict risky browsing paths — Use secure web gateway, DNS filtering, and phishing controls to reduce the chance users land on attacker HTML. This is useful immediately because the exploit requires page delivery and remains worthwhile even if patch rollout is routine for a LOW finding.
- Prioritize high-value Linux users — If you have Linux admin, engineering, or cloud-ops workstations, patch those first because browser-resident credentials and cloud sessions are more valuable there. Even without a mitigation SLA for LOW, targeted prioritization improves risk reduction per hour spent.
- Harden session value — Shorten token lifetime where practical, require reauthentication for sensitive apps, and keep MFA enforcement tight. That limits the payoff of any browser memory disclosure if patching lags.
- A network vulnerability scan will not meaningfully protect you here; this is a client browser issue, not a remotely fingerprintable server daemon.
- Perimeter firewalls do not stop a user-initiated HTTPS session to a malicious page that delivers the trigger through normal web traffic.
- Treating this like a classic internet-exposed CVE and searching Shodan/Censys is a dead end; exposure lives in endpoint inventory, not public service banners.
Crowdsourced verification payload.
Run this on the target Linux endpoint or through your fleet agent as a regular user; root is not required unless your tooling limits package queries. Save as check-chrome-cve-2026-11051.sh and run bash check-chrome-cve-2026-11051.sh.
#!/usr/bin/env bash
# Check Google Chrome on Linux for CVE-2026-11051
# Affected: Google Chrome on Linux prior to 149.0.7827.53
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
FIXED_VERSION="149.0.7827.53"
have_cmd() {
command -v "$1" >/dev/null 2>&1
}
ver_lt() {
# returns 0 if $1 < $2
[ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ] && return 1
[ "$1" = "$2" ] && return 1
return 0
}
extract_version() {
# Pull first dotted numeric version from input
echo "$1" | grep -Eo '[0-9]+(\.[0-9]+){2,}' | head -n1
}
chrome_version=""
source_name=""
for bin in google-chrome-stable google-chrome chrome chromium-browser chromium; do
if have_cmd "$bin"; then
out="$($bin --version 2>/dev/null || true)"
ver="$(extract_version "$out")"
if [ -n "$ver" ]; then
chrome_version="$ver"
source_name="$bin"
break
fi
fi
done
# Prefer Google Chrome package metadata if binary lookup failed or found Chromium
if [ -z "$chrome_version" ] || [ "$source_name" = "chromium" ] || [ "$source_name" = "chromium-browser" ]; then
if have_cmd dpkg-query; then
out="$(dpkg-query -W -f='${Version}\n' google-chrome-stable 2>/dev/null | head -n1 || true)"
ver="$(extract_version "$out")"
if [ -n "$ver" ]; then
chrome_version="$ver"
source_name="dpkg:google-chrome-stable"
fi
fi
fi
if [ -z "$chrome_version" ]; then
if have_cmd rpm; then
out="$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' google-chrome-stable 2>/dev/null | head -n1 || true)"
ver="$(extract_version "$out")"
if [ -n "$ver" ]; then
chrome_version="$ver"
source_name="rpm:google-chrome-stable"
fi
fi
fi
if [ -z "$chrome_version" ]; then
echo "UNKNOWN: Google Chrome on Linux not found, or version could not be determined."
exit 2
fi
# This CVE is stated for Google Chrome on Linux. Chromium package versions may not map cleanly.
case "$source_name" in
chromium|chromium-browser)
echo "UNKNOWN: Detected $source_name version $chrome_version. CVE scope is Google Chrome on Linux; verify Chromium downstream backports separately."
exit 2
;;
esac
if ver_lt "$chrome_version" "$FIXED_VERSION"; then
echo "VULNERABLE: Detected $source_name version $chrome_version, which is earlier than fixed version $FIXED_VERSION."
exit 1
fi
if [ "$chrome_version" = "$FIXED_VERSION" ] || [ "$(printf '%s\n%s\n' "$FIXED_VERSION" "$chrome_version" | sort -V | tail -n1)" = "$chrome_version" ]; then
echo "PATCHED: Detected $source_name version $chrome_version, which is at or above fixed version $FIXED_VERSION."
exit 0
fi
echo "UNKNOWN: Unable to compare detected version $chrome_version against fixed version $FIXED_VERSION."
exit 2
If you remember one thing.
Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.