CVE-2026-85050 is a critical flaw in the graphics-rendering code inside Google Chrome for Android — specifically in WebGL, the API that lets ordinary web pages ask the device's GPU to render 2D and 3D graphics. Under the right crafted conditions, a malicious web page can trigger an out-of-bounds write in this code path severe enough to let an attacker run their own code outside the browser's security sandbox — not just inside the constrained tab process the sandbox is designed to trap misbehaving web content in, but on the device itself, with no further steps required.
The CVSS v3.1 base score of 9.6 reflects exactly that distinction. Chrome patches memory-corruption bugs on a routine, almost weekly cadence, and the overwhelming majority stay contained to the sandboxed renderer process — serious, but survivable by design. This one didn't stay contained, and that single fact (formally, a CVSS Scope change — see Section 05) is what separates a 9.6 from the 8.8 sandbox-contained bugs patched in the very same release.
Everyone running Chrome for Android prior to version 152.0.7977.82 is at risk, which in practice means most of Chrome's global Android install base until the staged auto-update rollout completes. Android is the one platform in this release where patch adoption is least uniform: OEM-skinned builds, carrier-gated update channels, and devices running Android versions old enough to no longer receive current Chrome builds at all mean the fleet-wide patch tail here is meaningfully longer than on desktop Chrome.
This CVE shipped as one of twelve fixed in Google's September 3, 2026 stable-channel release — a release whose public narrative was almost entirely captured by a different bug in the same batch, CVE-2026-85046, which Google confirmed was already being actively exploited. CVE-2026-85050 was not reported as exploited as of this card's compile date. That gap between "most severe" and "most talked about" is itself the analytically interesting part of this card, and is developed further in Section 07.
WebGL is Chrome's bridge between fully untrusted, attacker-controlled JavaScript running in a web page and the native, platform-specific graphics driver stack underneath it — a seam that has to accept arbitrary shader programs, buffer geometry, and texture data from web content and hand validated versions of that data down to GPU driver code that was never designed with a hostile caller in mind. That bridge has been a recurring source of memory-safety bugs across every major browser engine for over a decade, not because engineers are careless, but because the validation surface is large, GPU driver behavior varies by vendor and platform, and the performance cost of exhaustive bounds-checking on every graphics call is high enough that some validation gaps persist despite continuous fuzzing investment.
Google's own security bulletin for this release does not publish the specific function, commit, or validation check that failed here — this is standard, deliberate practice for Chrome security fixes: full technical detail is withheld for a period after the patch ships specifically to blunt the window in which an attacker could reverse-engineer the fix into a working exploit against still-unpatched devices (the "N-day" exploitation risk). As of this card's compile date, one day after disclosure, no independent technical writeup or proof-of-concept reproducing the specific bounds-check failure has surfaced in the sources reviewed. That is a genuine, stated gap in this card, not an oversight — see Section 04 for why that gap is expected to persist for some time.
What is confirmed, from the CVE description itself, is the consequence rather than the mechanism: the corruption this bug produces is severe enough to escape the renderer sandbox's security boundary entirely, rather than remaining confined to it. That is the architecturally significant fact this card centers on, developed fully in Sections 05 and 07.
This lifecycle is unusually compressed compared to most vulnerabilities in this project's library, and that compression is itself informative about how Chrome's disclosure model works. The CVE record shows a reservation date of 2026-09-02 — one day before the CVE was published — and the public disclosure, the patched release, and the CVE record all landed together on 2026-09-03. There was no period of public "vulnerability known, patch not yet available" exposure, because Google does not publish security-relevant bug details before a fix ships. Discovery details (who found it, when, and how it was reported) have not been made public as of compile date — contrast this with the companion CVE-2026-85046 in the same release, which Google credited to an external researcher by name, a level of disclosure specificity CVE-2026-85050 has not (yet) received.
No public reporting reviewed for this card documents exploitation of CVE-2026-85050 specifically, before or after the patch. "Resolution" is marked in-progress rather than complete because Chrome's fix ships via a staged auto-update rollout — a meaningful fraction of the Android install base will not have received 152.0.7977.82 on day one, and Android's OEM/carrier update fragmentation means that tail is longer here than on desktop Chrome.
Google's Chrome security team operates one of the more disciplined coordinated-disclosure models among major software vendors: bug reports (external or internal) are tracked in a restricted-access Chromium issue tracker entry — one source lists this bug as tracker issue #549350408, though the entry's access-restriction status was not independently confirmed for this card — and details stay non-public until a fix has shipped, and typically for a further window afterward (commonly cited in security community reporting as roughly a month, or until sufficient user population has updated) specifically to blunt N-day reverse-engineering-to-exploit windows. That practice is precisely why this card is honestly thinner on exploit mechanics than older, fully-elaborated CVEs elsewhere in this library — the gap is a disclosure-policy artifact, not a research shortfall.
The community-reaction gap is worth stating plainly rather than glossing over: of the searches run to compile this card, queries for "Chrome zero-day" or "Chrome vulnerability this week" surfaced CVE-2026-85046 by name repeatedly and prominently, while CVE-2026-85050 required searching its specific CVE identifier to find any coverage at all, and even then mostly on CVE-aggregation sites rather than dedicated security journalism. Reasonable, since confirmed active exploitation (85046's status) is the correct urgency signal for time-constrained defenders — but it means this card's own compile process is a small, live case study in exactly the severity-versus-salience gap discussed in Section 07.
Per the vendor description, a maliciously crafted HTML page invokes WebGL rendering calls that trigger an out-of-bounds write within Chrome's graphics-handling code. Because the resulting memory corruption is severe enough to affect resources outside the vulnerable component's own security boundary, successful exploitation grants code execution beyond the renderer sandbox — a full escape, rather than the contained, tab-scoped compromise that most Chrome memory-safety bugs produce even when successfully exploited. No public source reviewed documents the specific exploitation chain, required heap-grooming technique, or whether a single bug alone is sufficient versus requiring chaining with an additional bug; this level of detail is exactly what Google's disclosure timing (Section 04) withholds at this stage.
Context from the same release sharpens what makes this bug distinct: the two other WebGL/rendering-adjacent CVEs patched alongside it, CVE-2026-85046 (V8 type confusion, CVSS 8.8, confirmed exploited in the wild) and CVE-2026-85051 (Compositing type confusion, CVSS 8.8), are both explicitly described in their own CVE records as producing code execution inside the sandbox. An attacker who only has one of those two bugs still needs a separate sandbox-escape primitive — like this one — to achieve full device compromise. CVE-2026-85050 supplies that primitive on its own. That is the entire reason it scores higher than either of its actively-exploited or better-known siblings in the same patch batch, despite carrying no confirmed exploitation of its own as of compile date.
| Vendor | Product | Affected Versions | Fixed Version | Status |
|---|---|---|---|---|
| Chrome (Android) | < 152.0.7977.82 | 152.0.7977.82 | Patched — staged auto-update rollout in progress at compile date |
No threat-actor group, APT, or eCrime operator has been publicly attributed exploitation of CVE-2026-85050 specifically as of compile date. This project's actor and incident card libraries were checked directly — no companion actor or incident card exists referencing this CVE. For comparison, CVE-2026-85046 in the same release is confirmed exploited, though Google's own bulletin does not name the exploiting party, which is standard practice for Chrome zero-day disclosures.
Given the sandbox-escape capability this CVE represents, the actors most likely to eventually weaponize it — commercial spyware vendors and well-resourced APT operators who specifically shop for full-chain mobile compromise primitives — are not the kind who typically surface in public exploitation telemetry quickly, if at all. Absence of public attribution one day after disclosure carries limited evidentiary weight either way.
The browser sandbox exists precisely so that a successful memory-corruption bug in the renderer process is survivable — contained to the tab, unable to touch the rest of the device. A Scope-Changed bug like this one defeats that entire design assumption in a single step, which is exactly why its CVSS math (9.6) exceeds its sandbox-contained siblings in the same patch batch (8.8 apiece) even though the underlying bug classes — out-of-bounds write versus type confusion — are not inherently more or less severe as isolated memory-safety issues. The sandbox escape, not the memory-corruption primitive itself, is what does the real architectural damage.
WebGL specifically recurs as a Chrome/Chromium bug source for a structural reason: it is an unusually wide API surface bridging fully untrusted, attacker-supplied web content directly down to native GPU driver code that spans many vendors, drivers, and operating-system combinations, none of which were designed with a hostile caller in mind. That is a seam the sandbox model has to work hardest to seal, and one that years of iterative hardening — site isolation, process sandboxing layers, continuous fuzzing investment — has narrowed without eliminating the underlying class of bug. This is not a Chrome-specific failure; every major browser engine with GPU-accelerated web graphics has shipped comparable sandbox-escape bugs rooted in the same architectural seam.
The disclosure-versus-salience gap documented in Sections 04 and 06 is itself a lesson worth stating explicitly: this release's public narrative was almost entirely captured by the actively-exploited, by-name-credited CVE-2026-85046, while the technically more severe, full-sandbox-escape CVE-2026-85050 required deliberate, CVE-ID-specific searching to find coverage of at all. Defenders and organizations that triage patch urgency primarily off security-news headlines rather than reading full vendor advisories will systematically under-prioritize bugs shaped exactly like this one — high CVSS, no (yet) confirmed exploitation, low public salience, and the single component in the whole release actually capable of a complete, one-bug device compromise.
No public source reviewed documents a specific behavioral signature, IOC, or exploit artifact for CVE-2026-85050 — that is expected given the one-day age and Google's disclosure-timing practice (Section 04), and is stated here explicitly rather than invented. The only reliably actionable detection surface at this stage is Chrome version compliance across managed Android fleets, not behavioral detection of the exploit itself.
Hypothesis: if an adversary already holds a foothold via a separate campaign and is layering in browser-based exploitation as an escalation or secondary-access vector, hunt for anomalous WebGL-context renderer/GPU-process crashes or restarts on managed Android devices, correlated with subsequent unexpected process behavior outside Chrome's normal process hierarchy — specifically on any device still reporting a pre-152.0.7977.82 version string.
Primary hunt target in practice: Chrome version telemetry itself. With no public behavioral IOC yet available, device-management consoles flagging out-of-compliance browser versions is the most reliable, evidence-backed signal available to hunters today — this is a legitimate and correct purple-team conclusion for a client-side bug this fresh, not a placeholder.
Because Chrome auto-updates for the overwhelming majority of installations, "patch guidance" here is less about scheduling a maintenance window than about verifying that auto-update actually completed across the fleet. Android is the layer most likely to lag: OEM-skinned builds, carrier-gated update channels, and devices on Android versions old enough to no longer receive current Chrome builds at all are the operationally relevant gap for any organization managing Android endpoints. Notably, despite the 9.6 severity, Google shipped this fix on its ordinary release cadence rather than as an emergency out-of-band patch — consistent with no confirmed in-the-wild exploitation of this specific bug at ship time.
This section does not apply in its usual form. CVE-2026-85050 is a client-side browser vulnerability triggered when a victim's device loads a malicious web page — there is no vulnerable network service listening on a port to scan, fingerprint, or dork for. Fabricating nmap output, service banners, or Shodan/Censys dorks for a browser rendering-engine bug would misrepresent what this vulnerability class actually is, so none are presented here. What follows instead is the genuine client-side analog to each of this section's usual sub-topics.
Chrome/152.0.7977.82) and is the direct client-side analog to a version-discriminating network scan — any endpoint-visibility tool that logs outbound User-Agent strings can flag pre-patch devices this way.