TL;DR

Google shipped Chrome 147 (version 147.0.7727.137/138) on April 28, 2026 with 30 security fixes in a single release — an unusually dense patch batch that Google developers attribute, in part, to AI-assisted vulnerability research accelerating discovery. Four of those fixes carry the highest possible severity rating: critical use-after-free (UAF) flaws in the Canvas, iOS, Accessibility, and Views components. A fifth high-severity UAF in the GPU subsystem rounds out the memory corruption cluster. Successful exploitation of CVE-2026-7363 (Canvas) enables arbitrary code execution inside Chrome's sandbox on Linux and ChromeOS via nothing more than a malicious webpage visit. Two of the four critical CVEs were found internally by Google — indicating the company spotted its own critical bugs before external researchers did, which historically precedes weaponization timelines. The fix is live. If your fleet isn't patched to 147.0.7727.137+, it's exposed.

---

Background: Why Browser UAFs Are Still the Browser Industry's Deepest Wound

Use-after-free vulnerabilities are among the oldest and most consistently weaponized bug classes in software. The mechanics are deceptively simple: an application frees a block of memory, but a reference to that block persists elsewhere in the codebase. When the stale pointer is dereferenced — intentionally or accidentally — it reads or writes into memory the allocator may have already reassigned to another object. In a complex, multi-process browser, the consequences range from crashes to full arbitrary code execution.

Chrome's architecture — built around a multi-process isolation model with a strict renderer/browser process separation and a sandbox that restricts what the renderer can touch — is explicitly designed to contain UAF exploitation. The theory is: even if an attacker achieves arbitrary code execution in the renderer (via a bug like CVE-2026-7363), they land inside a restricted sandboxed process with limited syscall access, no file system visibility, and constrained IPC. Getting out requires a second vulnerability: a sandbox escape.

In practice, UAFs are routinely chained with privilege-escalation bugs, kernel exploits, or renderer-to-browser IPC confusion attacks to achieve full device compromise. The four CVEs disclosed in Chrome 147 collectively cover four different subsystems — a diversity that matters: each UAF represents a different memory management failure path, different heap layout requirements, and potentially different exploitation primitives.

The AI-Amplification Signal

The size of this batch — 30 vulnerabilities in a single stable release — is not accidental. Google noted that a "significant increase in found and corrected security flaws has been observed here for several weeks." Heise's coverage explicitly flags that Google developers appear to be using AI for vulnerability research. This is consistent with what the industry has been watching all year: Anthropic's Mythos project, OpenAI's GPT-5.4-Cyber program, and internal Google Project Zero AI tooling are all accelerating the rate at which critical browser bugs surface. The flip side of that acceleration: the gap between discovery and exploitation is compressing, not expanding. Attackers have the same AI tooling available.

---

Technical Analysis

CVE-2026-7363 — Use-After-Free in Canvas (Critical, Linux/ChromeOS)

Reporter: heapracer (external researcher) | Bounty: $7,000 | Bug ID: 494352590

The Canvas component (<canvas>) is Chrome's 2D and WebGL rendering surface. It's one of the most performance-sensitive and complex subsystems in the browser, managing GPU-accelerated drawing operations, JavaScript-facing CanvasRenderingContext2D and WebGLRenderingContext objects, and the bridge between Blink's DOM layer and Chrome's GPU process.

The UAF in CVE-2026-7363 was found to be exploitable for arbitrary code execution within Chrome's sandbox on Linux and ChromeOS. The specific code path has not been disclosed (Google withholds technical details until the majority of the user base is patched — standard practice for high-severity CVEs), but the attack surface is well-understood from prior Canvas UAFs:

1. Object lifecycle mismatch: A JavaScript object holding a reference to a Canvas rendering context is garbage-collected or explicitly destroyed on the JS side. The underlying C++ CanvasRenderingContext2D object — or a subordinate cc::PaintCanvas, SkCanvas, or GPU command buffer wrapper — is freed by the renderer's memory allocator.

2. Stale reference remains: A second code path (typically a callback, an event handler, or an async GPU operation) retains a raw pointer to the freed object.

3. Heap grooming: The attacker-controlled JavaScript shapes the heap by allocating controlled-size objects to occupy the freed slot. Modern Chrome uses PartitionAlloc, which partitions allocations by type, making this harder but not impossible with sufficiently powerful primitives — cross-partition exploits exist.

4. Dereference and control: When the stale pointer dereferences the now-attacker-controlled memory, the attacker redirects execution. On 64-bit Linux/ChromeOS, modern exploits typically target vtable pointers to redirect virtual function calls to arbitrary gadgets.

The $7,000 bounty is on the low end for a critical Chrome bug, suggesting this was not a fully weaponized issue at disclosure, but the attack primitive is clear.

CVE-2026-7361 — Use-After-Free in iOS Chrome (Critical)

Reporter: Google (internal) | Bounty: TBD | Bug ID: 493221953

Chrome on iOS operates under stricter Apple-imposed constraints — WebKit's WKWebView underpins the actual rendering engine (Apple requires all iOS browsers to use WebKit), with Chromium's networking and Chrome-specific layers sitting above it. The UAF here affects Chrome's own code layer above WebKit — likely in Chrome's iOS-specific navigation, tab management, or JavaScript bridge code.

The critical severity rating indicates heap corruption is achievable via malicious webpage visits. On iOS, sandbox escapes face Apple's additional entitlement model and App Store restrictions, but compromised renderer code can still exfiltrate sensitive data from the browser process without a full escape.

The fact that Google found this internally before external researchers is notable. It suggests either Google's AI-assisted fuzzing caught it, or internal code review during the Canvas fix surfaced it as a related class of vulnerability.

CVE-2026-7344 — Use-After-Free in Accessibility (Critical)

Reporter: Google (internal) | Bounty: Pending | Bug ID: 503419515

Chrome's Accessibility layer (content/browser/accessibility/) translates the Blink DOM into accessibility trees for screen readers and assistive technology. It sits at the boundary between the privileged browser process and the renderer — a boundary that has historically been one of Chrome's most productive exploitation surfaces.

Accessibility UAFs in Chrome have been weaponized in the past: the accessibility layer often involves complex object graph management where UI elements can be destroyed while accessibility objects still hold references to them. Because the Accessibility layer touches both the renderer and browser processes, a UAF here has the potential to bridge isolation boundaries directly — making it higher-value than a pure renderer UAF if an attacker can reach the browser-side code.

CVE-2026-7343 — Use-After-Free in Views (Critical)

Reporter: (withheld) | Bounty: Pending | Bug ID: 503645680

Chrome's Views framework is the UI toolkit that builds Chrome's desktop interface — tabs, toolbars, dialog boxes, and the browser shell. Views is browser-process-resident code. A UAF in Views means the vulnerable code executes with browser process privileges, outside the renderer sandbox entirely.

If exploitable, a Views UAF does not require a sandbox escape step: code execution lands directly in the browser process. This makes CVE-2026-7343 potentially the highest-value bug in this cluster, despite limited public detail. The primary attack surface question is how attacker-controlled content from a webpage reaches the Views layer — a non-trivial but historically achievable path via IPC message confusion or malformed data flowing from renderer to browser.

CVE-2026-7333 — Use-After-Free in GPU (High Severity)

Reporter: c6eed09fc8b174b0f3eebedcceb1e792 | Bounty: $16,000 | Bug ID: (withheld)

The $16,000 bounty — largest in this batch and higher than any of the four critical-rated bugs — underscores a known quirk of Chrome's bug bounty program: severity ratings and bounty amounts don't always correlate. GPU UAFs are notoriously difficult to develop into reliable exploits (the GPU process has its own sandboxing layer), but the primitives are exceptionally powerful when they work. The higher bounty likely reflects more complete proof-of-concept work submitted by the researcher.

---

The AI-Discovery Inflection Point

The 30-bug batch is worth dwelling on. Chrome's patch cadence has been roughly 4-week cycles for years, averaging 8-15 external researcher reports per release. Thirty fixes in a single drop is approximately double the recent average. Chrome's own team attribution of this to AI-assisted research mirrors what Lyrie has been tracking across the industry:

• Google's Project Zero has been deploying ML-assisted variant analysis to find bug families, not just individual bugs
• Anthropic's Mythos program produced 2,000 zero-days in 7 weeks before being restricted
• Microsoft's AI red-team tooling is reportedly running continuous fuzzing against Chromium via its edge fork

When AI finds a UAF, it often surfaces a class of UAF — related code patterns across different subsystems. The Canvas + Accessibility + Views + iOS cluster in Chrome 147 looks like exactly that: four UAFs discovered by systematic variant analysis of a common object-lifetime-management pattern, not four independently discovered bugs.

The attacker-side implication is that this same technique is available to threat actors with access to AI tooling. The discovery-to-weaponization window that used to measure in months now measures in days for well-resourced crews.

---

IOCs / Indicators

No in-the-wild exploitation has been reported for this batch as of April 30, 2026. Google does not publicly confirm exploitation status at disclosure for these CVEs.

Version-based detection:

• Vulnerable: Chrome < 147.0.7727.137 (Windows/Linux) or < 147.0.7727.138 (macOS)
• Safe: 147.0.7727.137/138+

Network-level indicators (generic Canvas/UAF exploit patterns):

• Large, complex WebGL or Canvas API sequences from unexpected domains
• JavaScript that aggressively allocates and deallocates typed arrays, SharedArrayBuffers, or ArrayBuffers in loops (heap grooming)
• Rendering frames that attempt rapid object lifecycle transitions (create → use → destroy → create at same address)
• IPC message floods from renderer to browser process (Views/Accessibility exploit footprint)

Endpoint-level indicators:

• Chrome renderer crash followed immediately by unexpected subprocess spawn
• Browser process spawning non-Chrome child processes post-sandbox
• Heap allocation patterns detectable via Chrome's built-in sandbox logging (enable via --enable-sandbox-logging in enterprise deployments)

---

Lyrie Take

The signal isn't the bugs. It's the batch size.

Four critical UAFs in one release is not Chrome having a particularly bad month — it's the first clearly visible output of AI-augmented internal security research hitting production patch pipelines at scale. When Google finds 30 bugs in a cycle that previously yielded 12, the correct inference is not "Chrome was always this insecure." It's: the tool that found these bugs will find the next 30 in the next cycle too, and threat actors have equivalent tooling running in parallel.

For defenders, the browser surface has always been the highest-value remote attack vector. These CVEs confirm it's also the most actively mined one. The Accessibility and Views UAFs are particularly concerning: one sits at a process boundary, the other is the browser process. A working exploit chain against either, chained with a kernel privilege escalation, gives an attacker full OS-level access — zero user interaction beyond loading a page.

From a Lyrie platform perspective, machine-speed detection matters most here: between a user visiting a malicious page and a UAF exploit completing initial shellcode execution, the window is sub-second. Human-in-the-loop detection is structurally insufficient. Behavioral analysis of Chrome's IPC streams and memory allocation patterns, running at endpoint speed, is the detection primitive that closes this gap.

---

Defender Playbook

Immediate (< 24 hours)

1. Patch Chrome to 147.0.7727.137/138+ across all managed endpoints. Use enterprise management (Google Admin Console, Intune, Jamf) to force-push the update — do not rely on user-initiated restarts.

2. Prioritize Linux and ChromeOS endpoints for CVE-2026-7363 specifically (explicitly called out as an exploitation vector in those environments).

3. Enable Chrome's Extended Stable channel for enterprise users who cannot absorb rapid updates — this channel gets security-only patches with longer stability testing.

4. Block Chrome updates from being rolled back via policy (TargetVersionPrefix in Chrome enterprise policies, set to 147.x.x.x or later).

Short-Term (< 1 week)

5. Enable Chrome's --js-flags=--no-expose-wasm-in-shell on high-risk endpoints as a hardening measure — reduces heap grooming surface in WebAssembly-heavy exploit chains.

6. Deploy Chrome's Site Isolation policy (SitePerProcess: Enabled) if not already enforced — forces each site into its own renderer process, increasing attacker's work to reach cross-site data.

7. Enable V8 sandbox where available (Chrome 125+ enterprise policy: V8SandboxEnabled: true) — provides an additional isolation layer around the JavaScript engine.

8. Monitor for unusual Chrome subprocess spawning via EDR rules — any child process of chrome.exe or chrome that is not chrome, crashpad_handler, or nacl_helper should alert.

9. Log Chrome IPC crashes — Chrome's --renderer-startup-dialog and crash reporting infrastructure can surface exploitation attempts as renderer crashes with unusual stack traces.

Architectural

10. Deploy browser isolation (remote browser isolation or Chromium-based containerized browsing) for high-value users — executives, finance, engineering leads — as a structural control against browser-side RCE.

11. Review SIEM rules for heap-spraying indicators — large ArrayBuffer or SharedArrayBuffer allocations from unexpected browser origins are detectable via network proxies with JavaScript sandboxing.

12. Assume browser-as-initial-access in your threat model for the next 90 days: with AI-assisted discovery accelerating, similar UAF cluster drops are likely across Chrome and other Chromium-based browsers (Edge, Brave, Arc).

---

Sources

1. Google Chrome Releases Blog — Stable Channel Update for Desktop, April 28, 2026: https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop_28.html

2. CyberSecurityNews — "Critical Chrome Vulnerabilities Enables Remote Code Execution Attacks," April 29, 2026: https://cybersecuritynews.com/chrome-vulnerabilities-2/

3. Heise Online — "Critical vulnerabilities in Chrome and Firefox closed," April 29, 2026: https://www.heise.de/en/news/Critical-vulnerabilities-in-Chrome-and-Firefox-closed-11276019.html

4. SecurityWeek — "Chrome 147, Firefox 150 Security Updates Rolling Out": https://www.securityweek.com/chrome-147-firefox-150-security-updates-rolling-out/

5. Neowin — Chrome 147.0.7727.138 release notes (CVE detail listing): https://www.neowin.net/software/google-chrome-14707727138-offline-installer

6. CVEFeed Newsroom — Latest CVE updates, April 29-30, 2026: https://cvefeed.io/newsroom/latest

7. PCWorld — "Google just patched 30 high-risk Chrome security vulnerabilities": https://www.pcworld.com/article/3127760/google-just-patched-30-high-risk-chrome-security-vulnerabilities.html

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk