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

Out of bounds read in ANGLE in Google Chrome on Linux prior to 149

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

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.

"Remote bug, but Linux-only, user-driven, and disclosure-only keeps this in routine browser hygiene."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure a Linux Chrome user to attacker HTML

The attacker needs a user on Chrome for Linux < 149.0.7827.53 to open a crafted page. In practice the delivery tool is usually a phishing link, malicious ad, or compromised site rather than a direct network probe, because this is a browser client bug, not a server-side listener.
Conditions required:
  • Victim is running affected Chrome on Linux
  • Victim visits attacker-controlled or attacker-influenced content
  • Enterprise policy has not blocked risky browsing paths
Where this breaks in practice:
  • 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
Detection/coverage: Network vulnerability scanners are weak here; version inventory from EDR, browser management, package telemetry, or MDM is the reliable coverage.
STEP 02

Trigger the ANGLE out-of-bounds read

Once the page is rendered, attacker-controlled content exercises the vulnerable ANGLE code path and can cause an out-of-bounds read. The practical weapon here is the crafted web page itself; there is no evidence in public sources of a broadly circulated exploit kit or turnkey PoC for this specific CVE.
Conditions required:
  • The vulnerable graphics path is reachable on the target build
  • The page reaches the relevant ANGLE handling path during rendering
Where this breaks in practice:
  • 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
Detection/coverage: Crash telemetry may catch failed attempts; preventive detection is limited because the trigger is normal-looking web content.
STEP 03

Harvest process memory disclosure

Successful exploitation yields potentially sensitive data from process memory. That can matter for tokens, page data, or adjacent secrets in-process, but the CVE does not claim arbitrary code execution or sandbox escape.
Conditions required:
  • Valuable data is resident in the affected process at exploit time
  • The attacker can turn leaked bytes into something operationally useful
Where this breaks in practice:
  • 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
Detection/coverage: Traditional endpoint tooling rarely sees the memory leak directly; downstream signs are more likely account misuse or suspicious web sessions if useful tokens are exposed.
STEP 04

Convert leaked data into follow-on access

The attacker still needs a second stage to monetize the leak, such as replaying a token or combining the disclosure with another browser bug. That means the vulnerability is better understood as an enabler than a complete compromise path on its own.
Conditions required:
  • Leaked material contains reusable secrets
  • Those secrets are not bound to device, origin, or session controls
  • The attacker has infrastructure to operationalize the data
Where this breaks in practice:
  • 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
Detection/coverage: Identity telemetry and browser-session anomaly detection are more useful than CVE scanning at this stage.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in the cited sources; not KEV-listed.
KEV statusAbsent from CISA's Known Exploited Vulnerabilities Catalog.
PoC availabilityNo authoritative public PoC located for CVE-2026-11051. Chromium bug reference exists, but the public issue page is access-restricted.
EPSSSupplied intel says 0.00035. That is extremely low exploit-likelihood signal; percentile was not confirmed from authoritative output during this review.
CVSS vector meaningCVSS: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 versionsGoogle Chrome on Linux prior to 149.0.7827.53.
Fixed versionVendor fix is Chrome 149.0.7827.53 for Linux via the stable channel release on 2026-06-02.
Exposure realityThis 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 timelineChrome stable release carrying the fix published 2026-06-02; NVD shows the CVE record published 2026-06-04.
Reporting / sourceNVD references Chromium issue 498828605; public advisory language attributes the severity to Chromium security severity: Medium.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

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.

HIGH Affected version and platform scope
MEDIUM Assessment that this is routine-priority rather than urgent
LOW Exact exploit reliability across GPU/driver combinations

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.

05 · Compensating Control

What to do — in priority order.

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

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.

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

If you remember one thing.

TL;DR
Monday morning, pull a list of Linux endpoints running Chrome < 149.0.7827.53, fix the stragglers through your normal browser-update channel, and give extra attention to Linux admin and engineering workstations. Because this is LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene treatment; in plain terms, no mitigation SLA applies, so handle it in routine browser maintenance rather than emergency patching, but close it out before it sits for quarters.

Sources

  1. NVD CVE-2026-11051
  2. Chrome Releases: Stable Channel Update for Desktop (Chrome 149 stable)
  3. Chromium issue 498828605
  4. Chromium Security
  5. Chromium Site Isolation
  6. FIRST EPSS API documentation
  7. CISA Known Exploited Vulnerabilities Catalog
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.