Google has shipped a Stable Channel update fixing 18 security vulnerabilities in Chrome — four rated Critical, fourteen rated High. None of the 18 show evidence of active exploitation at time of disclosure, distinguishing this from the actively-exploited V8 zero-day (CVE-2026-11645) patched earlier this month. The concentration of use-after-free bugs across WebGL, Autofill, Bluetooth, Blink, and WebView signals a broad memory-safety attack surface rather than a single root-cause issue.
Critical Vulnerabilities
CVE-2026-13028 — Use-after-Free in WebGL
Reported by an external researcher on June 7, 2026. A UAF in Chrome’s WebGL rendering engine that can be triggered via a specially crafted HTML page, allowing an attacker to escape the browser’s sandbox.
CVE-2026-13032 — Use-after-Free in WebGL
Discovered internally by Google on June 13, 2026. Same component, same sandbox-escape impact as above — two independent UAF paths into WebGL in a single release is notable and suggests the component received focused fuzzing attention this cycle.
CVE-2026-13033 — Out-of-Bounds Read in Blink (InterestGroups)
Found internally. Affects the InterestGroups component within Blink (Chrome’s rendering engine) — this is the API surface tied to the Privacy Sandbox / Protected Audience (FLEDGE) advertising auction mechanism. An OOB read here can leak adjacent memory contents to a malicious page.
CVE-2026-13038 — Use-after-Free in Autofill
Found internally, June 13–14, 2026. UAF in the Autofill subsystem — the component that handles stored form data, saved addresses, and payment card details, making this one to watch closely given the sensitivity of data Autofill typically touches.
Why the WebGL pair matters most
Use-after-free vulnerabilities occur when code continues referencing a memory location after it has been freed; if the freed memory gets reallocated and an attacker controls what’s written there, they can hijack the program’s execution flow. A sandbox escape converts “malicious code running in a restricted, browser-only context” into “malicious code able to touch the wider system” — the actual ceiling on impact depends on what gets chained next (a renderer-to-kernel privilege escalation, for instance). Two independent sandbox-capable UAFs in the same component in one release also raises the question of whether WebGL’s memory-lifecycle handling needs a structural look rather than point patches.
High-Severity Vulnerabilities
| CVE ID | Type | Component |
|---|---|---|
| CVE-2026-13021 | Inappropriate Implementation | DeviceBoundSessionCredentials |
| CVE-2026-13022 | Inappropriate Implementation | Autofill |
| CVE-2026-13023 | Uninitialized Use | GPU |
| CVE-2026-13024 | Insufficient Input Validation | Navigation |
| CVE-2026-13025 | Insufficient Input Validation | DevTools |
| CVE-2026-13026 | Use-after-Free | Digital Credentials |
| CVE-2026-13027 | Use-after-Free | FileSystem |
| CVE-2026-13029 | Use-after-Free | Web Authentication |
| CVE-2026-13030 | Uninitialized Use | GPU |
| CVE-2026-13031 | Use-after-Free | Blink |
| CVE-2026-13034 | Inappropriate Implementation | Passwords |
| CVE-2026-13035 | Use-after-Free | Bluetooth |
| CVE-2026-13036 | Use-after-Free | Blink |
| CVE-2026-13037 | Use-after-Free | WebView |
Points worth flagging from this batch:
- Bluetooth (CVE-2026-13035) and WebView (CVE-2026-13037) UAFs extend the exploitable surface beyond the rendering engine into device-interface and embedded-browser contexts — relevant for any Electron or Android in-app browser deployments riding on Chromium.
- Passwords (CVE-2026-13034) and Web Authentication (CVE-2026-13029) sitting in the same release as the Autofill flaws means credential-adjacent code took multiple hits this cycle.
- GPU (CVE-2026-13023, -13030) uninitialized-use bugs are typically lower-reliability for RCE than UAF but still useful for information disclosure or as a chain link.
- Most of these were caught via Google’s internal fuzzing/sanitizer stack (AddressSanitizer, MemorySanitizer, libFuzzer) rather than external bounty submissions — only CVE-2026-13028 above was externally reported.
Detection & Hunting Notes
Google is withholding exploit-relevant technical detail (commit diffs, PoC specifics) until rollout reaches majority adoption — standard practice, but it means there’s no public IOC set tied to this batch since nothing is confirmed exploited yet. Practical detection posture:
- Treat unexplained Chrome/Chromium renderer crashes (especially WebGL-context or Autofill-triggered) on managed fleets as worth a closer look until patch saturation is confirmed.
- Browser crash-reporting telemetry (chrome://crashes, or EDR-side renderer-crash signals) is your best early signal if any of these get weaponized post-disclosure — sandbox-escape UAFs in WebGL are exactly the class that gets reverse-engineered from a diff once Google’s restriction lifts.
- Any Chromium-based product sharing this codebase (Edge, Brave, Opera, Vivaldi) inherits the same exposure until they ship their own downstream patch — don’t assume Chrome-only scope on an enterprise fleet.
Remediation
- Update immediately — Chrome auto-updates on relaunch; verify fleet-wide via
chrome://versionrather than trusting install-package metadata alone. - Enforce via management tooling — Google Workspace Admin Console, Microsoft Intune/Endpoint Manager, or equivalent MDM to push compliance across endpoints rather than relying on individual auto-update timing.
- Don’t stop at Chrome — push corresponding updates for Edge, Brave, Opera, Vivaldi, and any Electron-based internal tooling once upstream patches land.
- Validate, don’t just deploy — confirm the running process version post-update, not just the installed package version; Chrome’s staged rollout means “update available” and “update applied” aren’t simultaneous across a fleet.
Bottom Line
18 vulnerabilities, 4 critical, all use-after-free or memory-safety class bugs, none currently exploited — but this is Chrome’s third major patch cycle in June 2026 alone (following the 74-CVE release with the actively-exploited CVE-2026-11645 V8 zero-day, and a 33-CVE release mid-month). The volume and recurring memory-safety pattern across releases this month is the real story here as much as any single CVE.
