← Back to Feed CACHED · 2026-09-30 01:33:52 · CACHE_KEY CVE-2026-11057
CVE-2026-11057 · CWE-457 · Disclosed 2026-06-04

Uninitialized Use in Skia Glyph Image Rendering in Google Chrome

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

This is the flashlight an intruder uses after they have already broken into the house — useful for finding valuables, but useless without the break-in

CVE-2026-11057 is an uninitialized memory read in Chrome's Skia graphics library, specifically in glyph image rendering. When the renderer process handles crafted font glyphs, it reads memory that was never properly zeroed, potentially exposing residual data — heap metadata, pointers, cross-origin fragments — from previous allocations. The critical gate: the renderer process must already be compromised via a separate vulnerability before this code path is attacker-reachable. Affected versions are all Chrome builds prior to 149.0.7827.53, released June 2, 2026. All desktop platforms (Windows, macOS, Linux, ChromeOS) and Chromium-derived browsers sharing the same Skia version are in scope.

Google rated this MEDIUM at CVSS 6.5, but that score is generous to the point of being misleading. The CVSS vector (AV:N/AC:L/PR:N/UI:R) entirely fails to encode the critical precondition: the attacker needs a *separate* renderer-compromise vulnerability first. CyberStrike lists an alternate vector at 4.8 (AC:H/PR:L) which better reflects reality. This CVE is an ASLR-bypass primitive — a building block, not a standalone threat. Researcher anansi2safe demonstrated it as one link in a full-chain Android Chrome exploit (paired with CVE-2026-5281, a Dawn use-after-free), but the chain's actual impact — code execution outside the sandbox — comes from the *other* bugs, not this one. Standalone, CVE-2026-11057 leaks bytes from process memory inside a sandbox the attacker already controls.

"Info leak inside an already-breached sandbox — a lockpick for a door the attacker already opened."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Compromise the renderer process

The attacker must first achieve code execution inside Chrome's renderer sandbox via a separate vulnerability — a V8 type confusion, a WebGPU use-after-free like CVE-2026-5281, or a Blink memory corruption. This is the hardest and most expensive step in the chain and is a strict prerequisite; CVE-2026-11057 cannot be triggered without it. The renderer sandbox severely constrains what this initial code execution can access.
Conditions required:
  • Separate renderer-compromise vulnerability (RCE inside sandbox)
  • Victim navigates to attacker-controlled or compromised page
Where this breaks in practice:
  • Renderer-compromise bugs are high-value, often zero-day-grade, and patched within days
  • Chrome's V8 sandbox and MiraclePtr have significantly reduced exploitable renderer bugs in 2025-2026
  • Chrome auto-update means the window for any given renderer bug is days, not weeks
Detection/coverage: EDR solutions (CrowdStrike, Defender for Endpoint, SentinelOne) detect anomalous renderer behavior and crash patterns. Chrome's CrashPad telemetry catches exploitation attempts server-side.
STEP 02

Trigger uninitialized Skia glyph read

With renderer code execution, the attacker crafts HTML/CSS that forces Skia to render specific glyph images without initializing the backing memory buffer. The uninitialized memory contains residual data from previous allocations within PartitionAlloc's Skia bucket. The attacker reads this data back through the compromised renderer context.
Conditions required:
  • Renderer process already compromised (Step 1)
  • Chrome version < 149.0.7827.53
Where this breaks in practice:
  • Chrome auto-updates aggressively — by September 2026, the vast majority of managed endpoints are past 149.x
  • PartitionAlloc bucket isolation means the leaked data is from Skia's own partition, limiting cross-compartment exposure
Detection/coverage: No direct scanner signature for this step. Version-based detection (Chrome < 149.0.7827.53) is the primary indicator.
STEP 03

Harvest ASLR layout or sensitive heap data

The leaked memory may reveal ASLR base addresses for Chrome's binary or system libraries, heap layout metadata, or partial cross-origin data fragments. This information is primarily useful for defeating ASLR to make a subsequent sandbox-escape exploit reliable. The anansi2safe PoC uses this step to locate vtable pointers, enabling a controlled indirect call (pc=0x7641414141) in the companion CVE-2026-5281 exploit.
Conditions required:
  • Successful uninitialized read from Step 2
  • Useful pointers or layout data present in the uninitialized region (probabilistic)
Where this breaks in practice:
  • Modern heap hardening (PartitionAlloc) reduces the chance of high-value data leaking into Skia glyph buffers
  • The data quality is non-deterministic — multiple trigger attempts may be needed
  • Even with ASLR bypass, a sandbox escape requires yet another vulnerability
STEP 04

Chain into sandbox escape (requires a third vulnerability)

The ASLR-defeating information from Step 3 enables reliable exploitation of a sandbox-escape vulnerability — a *third* bug in the overall chain. Without this additional vulnerability, the attacker remains trapped inside Chrome's renderer sandbox with read-only access to leaked bytes. The anansi2safe full-chain PoC used CVE-2026-5281 (Dawn UAF) for this step, achieving a vtable hijack and controlled indirect call outside the sandbox.
Conditions required:
  • ASLR layout obtained from Step 3
  • Separate sandbox-escape vulnerability available and unpatched on target
  • Companion vuln also unpatched on target
Where this breaks in practice:
  • Requires stacking three vulnerabilities total — renderer RCE, info leak, and sandbox escape
  • Chrome's multi-process architecture and strict site isolation limit lateral movement even within the browser
  • Sandbox-escape bugs are the rarest and most expensive class of Chrome vulnerabilities, often costing $250K+ on the exploit market
Detection/coverage: Chrome sandbox escape triggers alerts in EDR (unusual child process spawning, direct syscalls from renderer). Windows Exploit Guard and macOS sandbox violation logs provide additional coverage.
03 · Compensating Control

1
LOW 3.5→IGNORE 0.0
SEVERITY REDUCED
Enforce Chrome auto-update and verify fleet version compliance — Ensure all managed endpoints are running Chrome >= 149.0.7827.53 via your browser management tool (Chrome Browser Cloud Management, Intune, SCCM, or equivalent). This is a LOW-severity finding — no mitigation SLA applies under the noisgate framework. Go straight to the 365-day noisgate remediation SLA. Query your endpoint management platform for Chrome version < 149.0.7827.53 and flag non-compliant hosts for remediation.
2
LOW 3.5→LOW 2.5
Enable Site Isolation and V8 sandbox (verify defaults) — Confirm --site-per-process is enabled (default since Chrome 67) and V8 sandbox is active (default in Chrome 117+). These controls harden the renderer-compromise precondition (Step 1) by isolating cross-origin data and limiting V8 exploitation primitives. This does not patch CVE-2026-11057 but makes the prerequisite step significantly harder. Verify via chrome://flags or enterprise policy.
3
LOW 3.5→LOW 3.0
Deploy EDR with browser exploitation detection rules — Ensure EDR platforms (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne) are deployed with browser exploitation detection enabled. These provide detection coverage for Steps 1 (renderer compromise) and 4 (sandbox escape) of the attack path. Does not prevent the info leak itself but catches the chain before it achieves meaningful impact outside the sandbox.
What doesn't work
  • WAF or network-level filtering — This is a client-side browser rendering bug triggered by visiting a page. The payload is valid HTML/CSS that exercises a Skia code path; there is no network-layer signature to block.
  • Disabling JavaScript — The uninitialized read is in Skia's native glyph rendering, not in script execution. Disabling JS might prevent the renderer-compromise *precondition* in some cases, but it breaks virtually all web applications and is not practical at enterprise scale.
  • Content Security Policy (CSP) — CSP controls script and resource loading policy but cannot prevent Skia from processing font glyphs via its native rendering pipeline. The info leak is in compiled C++ code, not script execution.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNot observed standalone. CVE-2026-5281 (the companion bug in the anansi2safe chain) was confirmed exploited in the wild by Google TAG, but CVE-2026-11057 itself has no independent ITW evidence. Not on CISA KEV.
Proof of ConceptPublic full-chain PoC exists. Researcher anansi2safe published a full-chain Android Chrome exploit combining CVE-2026-11057 (Skia info leak) + CVE-2026-5281 (Dawn UAF) on Exploit Intel. The PoC includes exploit.html with heap spray and vtable hijack, claiming ~100% crash reliability. No standalone PoC for CVE-2026-11057 alone found on pocindex.io, GitHub, or ExploitDB. The SecureWithUmer/CVE-2026-PoCs aggregator does not list a dedicated entry for this CVE.
EPSS Score0.0025 (0.25%) — 16th percentile. Indicates very low predicted exploitation probability within 30 days. Consistent with the high prerequisite barrier.
CISA KEV StatusNot listed. As of 2026-09-30, this CVE is not in the Known Exploited Vulnerabilities catalog.
CVSS VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N (6.5 Medium per vendor). CyberStrike lists an alternate vector CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:N/A:N (4.8) which better reflects the renderer-compromise precondition. The AC:L in the primary vector is misleading — real attack complexity is high.
Affected VersionsGoogle Chrome < 149.0.7827.53 on all platforms (Windows, macOS, Linux, ChromeOS). Chromium-based browsers (Edge, Brave, Opera, Vivaldi) sharing the same Skia version are also affected.
Fixed VersionsChrome 149.0.7827.53 (stable, June 2, 2026). Distro backports: Fedora/EPEL via chromium-browser errata (Red Hat BZ 2485036); Debian DSA; Ubuntu USN. Microsoft Edge typically follows within 1-2 weeks of Chromium stable.
Scanning / ExposureNot applicable for GreyNoise/Shodan/Censys — this is a client-side browser vulnerability, not a server-side service. Enterprise exposure is measured by fleet Chrome version compliance. Any endpoint running Chrome < 149.0.7827.53 is technically exposed, but exploitation requires a separate renderer compromise first.
Disclosure Date2026-06-04 (reserved and published same day). Chromium issue: issues.chromium.org/498951946.
ReporterNot publicly attributed for CVE-2026-11057 specifically. The full-chain PoC author anansi2safe is documented on Exploit Intel. Google credited internal and external researchers in the Chrome 149 release notes.

Sources.

  1. OpenCVE — CVE-2026-11057 Details
  2. CyberStrike — CVE-2026-11057 Detail
  3. Red Hat Bugzilla — Bug 2485036
  4. Ubuntu Security — CVE-2026-11057
  5. Chromium Issue Tracker — 498951946
  6. Chrome Releases Blog — Stable Channel Update June 2026
  7. The Hacker News — CVE-2026-5281 Active Exploitation
  8. Exploit Intel — anansi2safe PoC Author
05 · The Call

Final Verdict
↓ DOWNGRADED to LOW (3.5/10)

Why this verdict

  • Renderer-compromise precondition is a massive gate. The attacker must already have code execution inside Chrome's renderer sandbox before CVE-2026-11057 is reachable. This precondition — equivalent to a separate high/critical-severity exploit — is not reflected in the CVSS vector's AC:L/PR:N, making the 6.5 score artificially inflated. Adjusting for this precondition alone drops real-world severity by at least one full tier.
  • Information disclosure only, not code execution. Even when successfully triggered, the impact is leaking bytes of uninitialized process memory. This is an ASLR-bypass primitive, not a standalone compromise. The attacker gains no new code execution, persistence, or lateral movement from this bug alone. C:H/I:N/A:N with a mandatory prior compromise is functionally a LOW-impact finding.
  • Chrome auto-update collapses the exposure window. Chrome 149.0.7827.53 shipped June 2, 2026 — nearly four months ago. Enterprise Chrome fleets with managed auto-update policies should be well past this version. The residual exposed population is limited to endpoints with stale, unmanaged browsers or locked Chromium builds in appliances.
  • EPSS confirms minimal standalone exploitation risk. At 0.25% (16th percentile), FIRST's model predicts negligible exploitation probability. Not on CISA KEV. No independent in-the-wild exploitation reported for this CVE.
  • Role multiplier: Chrome is a client-side browser on endpoints — it does not occupy a high-value server role (DC, IdP, hypervisor, CI/CD, PAM, backup, network edge). The blast radius of a *successful full chain* (requiring two additional vulns) is single-endpoint compromise, not fleet/domain/supply-chain scale. Headless Chrome in CI/CD pipelines is a niche case, but those instances typically run in ephemeral containers with no persistent credentials. The high-value-role verdict floor does not apply.

Why not higher?

While a public full-chain PoC (anansi2safe) exists that uses this CVE as a building block, CVE-2026-11057 is only the info-leak primitive — not the renderer compromise or the sandbox escape. Raising to MEDIUM would require this bug to have standalone exploitable impact or active in-the-wild exploitation, neither of which exists. The companion bug CVE-2026-5281 was exploited ITW, but that is a separate CVE with its own severity assessment. The chain's impact cannot be attributed to this link alone.

Why not lower?

IGNORE would be inappropriate because the bug has proven utility in a public full-chain exploit, and the anansi2safe PoC demonstrates near-100% reliability for the info leak step. Enterprises with unmanaged Chrome populations, locked Chromium builds in kiosks, or slow update cycles still carry residual risk. The CVE is real, patched, and has a working chain — it is just not impactful on its own.

06 · Verification

Crowdsourced verification payload.

Run on each target endpoint or collect results remotely via your endpoint management tool. No elevated privileges required — any user can query Chrome's version. Example: bash check_cve_2026_11057.sh. Works on macOS and Linux; for Windows endpoints, query HKLM\SOFTWARE\Google\Chrome\BLBeacon\version via Intune or SCCM instead.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_11057.sh
# Checks if installed Google Chrome / Chromium is vulnerable to CVE-2026-11057
# (Uninitialized Use in Skia, fixed in 149.0.7827.53)
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -uo pipefail

FIXED_MAJOR=149
FIXED_MINOR=0
FIXED_BUILD=7827
FIXED_PATCH=53

get_chrome_version() {
  local version=""
  if [ "$(uname)" = "Darwin" ]; then
    local chrome_path="/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    if [ -x "$chrome_path" ]; then
      version=$("$chrome_path" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
    fi
  fi
  if [ -z "$version" ]; then
    for cmd in google-chrome google-chrome-stable chromium-browser chromium; do
      if command -v "$cmd" >/dev/null 2>&1; then
        version=$("$cmd" --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+')
        if [ -n "$version" ]; then break; fi
      fi
    done
  fi
  echo "$version"
}

version_gte() {
  # Returns 0 if $1.$2.$3.$4 >= FIXED
  local maj=$1 min=$2 bld=$3 pat=$4
  if [ "$maj" -gt "$FIXED_MAJOR" ]; then return 0; fi
  if [ "$maj" -lt "$FIXED_MAJOR" ]; then return 1; fi
  if [ "$min" -gt "$FIXED_MINOR" ]; then return 0; fi
  if [ "$min" -lt "$FIXED_MINOR" ]; then return 1; fi
  if [ "$bld" -gt "$FIXED_BUILD" ]; then return 0; fi
  if [ "$bld" -lt "$FIXED_BUILD" ]; then return 1; fi
  if [ "$pat" -ge "$FIXED_PATCH" ]; then return 0; fi
  return 1
}

VERSION=$(get_chrome_version)

if [ -z "$VERSION" ]; then
  echo "UNKNOWN - Google Chrome / Chromium not found on this host."
  exit 2
fi

IFS='.' read -r major minor build patch <<< "$VERSION"

echo "Detected Chrome version: $VERSION"
echo "Fixed version:           ${FIXED_MAJOR}.${FIXED_MINOR}.${FIXED_BUILD}.${FIXED_PATCH}"

if version_gte "$major" "$minor" "$build" "$patch"; then
  echo "PATCHED - Chrome $VERSION >= $FIXED_MAJOR.$FIXED_MINOR.$FIXED_BUILD.$FIXED_PATCH"
  exit 0
else
  echo "VULNERABLE - Chrome $VERSION is below fixed version (CVE-2026-11057)"
  exit 1
fi