Chrome 150 Update Seals Three Critical Use-After-Free Bugs — Time to Restart Your Browser

On July 17, Google shipped Chrome 150.0.7871.128/.129 for Windows and Mac, and 150.0.7871.128 for Linux, patching seven security vulnerabilities. Three of those flaws earned the company’s Critical severity rating, all of them use-after-free bugs residing in the browser’s CameraCapture, GPU, and Network components. No evidence of active exploitation has emerged. But the weekend is near, and the window between a public patch and adversary analysis is unforgiving.

The Critical Trio: CameraCapture, GPU, and Network

Google’s security bulletin lists CVE-2026-15899 (CameraCapture), CVE-2026-15900 (GPU), and CVE-2026-15901 (Network). All three fall into the use-after-free category—a class of memory-safety flaw in which code continues to reference a memory block after freeing it. Attackers who can control what data occupies that recycled memory can turn the mistake into arbitrary code execution, often as part of a larger exploit chain.

The severity tags should not be misread as an alarm about webcams or network cards being independently vulnerable. These identifiers point to weaknesses within Chrome’s own sandboxed processes. But CameraCapture handles real-time media streams. GPU juggles hardware-accelerated rendering and inter-process communication. Network parses every byte of web traffic. A critical memory corruption in any one of them expands the attack surface significantly.

Details remain sealed. Google restricts access to individual bug reports until “the majority of users” have received the fix—a standard practice designed to slow weaponization. That means defenders cannot yet examine the root causes, but the advisory is explicit enough to act on.

The Full Seven-Patch Breakdown

While the three Critical bugs demand immediate attention, the remaining four patches carry High severity and complete a cleanup that touches Cast, V8, Ozone, and Aura.

The V8 engine flaw stands out: an out-of-bounds read and write inside Chrome’s JavaScript and WebAssembly runtime, reported by an external researcher. It arrived on July 6, just 11 days before the fix landed. CVE-2026-15903 doesn’t carry a Critical badge, but V8 exploits have a long history of being paired with sandbox-escape techniques to achieve full system compromise. Treat it as urgent.

Why a Use-After-Free Bug Is No Minor Annoyance

Chrome’s multi-process architecture doesn’t mean memory-safety bugs are contained. Renderer compromises often form the first link in a chain. A use-after-free in the GPU process, for example, might allow an attacker to pivot from a crafted webpage into the more privileged process handling graphics, and from there look for a sandbox escape. The fact that no such chain is known today changes nothing about the need to patch.

Google discovered six of the seven flaws internally. That’s good news, but vulnerability researchers on both sides of the fence will now diff the updated binaries. The release itself hands attackers a roadmap. Staging updates over “coming days and weeks” only stretches the period during which some machines remain on vulnerable code.

Home Users: Install, Restart, Verify

If Chrome is your daily driver, you have one job.

1. Click the three-dot menu in the top-right corner.
2. Navigate to Help > About Google Chrome.
3. Wait for the version check. If you’re behind, the update will download automatically.
4. Relaunch the browser when prompted.

After the restart, the About page should show version 150.0.7871.128 or .129 on Windows and Mac, or .128 on Linux. The dual version numbers on desktop simply reflect platform-specific packaging; one isn’t more secure than the other. If the update doesn’t appear, close Chrome entirely and reopen it. Stale sessions can block the installer from swapping files.

Many users keep dozens of tabs open for days. The browser may have already fetched the update in the background, but until you restart, you’re browsing with the old, vulnerable process. Check, restart, and confirm.

Enterprise: Close the Restart Gap

IT teams should resist the reflex to treat a browser update as a low-priority software refresh. Chrome sits at the intersection of identity providers, SaaS platforms, payment portals, and personal browsing. In most organizations, it’s the application employees spend the most time inside. A critical memory flaw in the network stack or graphics engine is a real endpoint security issue.

Begin with your browser-management console or endpoint detection platform and filter for Chrome versions below 150.0.7871.128. Pay special attention to:

• Machines that downloaded the update but haven’t restarted Chrome. This is the most common blind spot. A dashboard showing 100% compliance by package version is misleading if the browser process is still running old code.
• Unmanaged installations. BYOD laptops, virtual desktops, test machines, and kiosks often slip through update policies. Take this release as an opportunity to inventory undocumented Chrome installations.
• Off-network endpoints. Users working remotely may not connect to internal update servers frequently. Push the update through your cloud-based management tools or instruct them to trigger a manual check.
• High-exposure groups. Prioritize administrators, finance teams, developers, and anyone handling sensitive web applications. They are the most likely targets if an exploit chain does emerge.

A reasonable timeline might be 48 hours for the most exposed machines, with a 72-hour deadline for the rest of the fleet. Communicate that restart is mandatory—not optional.

How We Got Here

Chrome 150’s security release follows a June and July reporting cadence. The first bug—CVE-2026-15899 in CameraCapture—dates to May 27. The most recent, the critical Network flaw (CVE-2026-15901), was filed on July 10 and fixed just seven days later. That turnaround reflects both the severity and the internal discovery path.

The V8 report from OpenAI Codex Security’s researcher amyb is a reminder that external eyes continue to find high-impact issues. The bug was filed on July 6 and fixed in the same July 17 batch. Google hasn’t published reward information, but the speed suggests it was prioritized.

Chrome 150.0.7871.128/.129 arrives one day after Google shipped Chrome 150’s initial security update with 15 fixes, including two Critical flaws. That previous bundle didn’t reach all users before this new one superseded it. The rapid-fire cadence is normal for Chrome, but it underscores a truth: manual patching is no longer a viable strategy for enterprise fleets.

What To Do Right Now

If you’re a home user:
- Open Chrome’s About page and install the update.
- Restart the browser immediately after.
- Verify the version number matches your platform’s release.

If you manage enterprise endpoints:
- Identify all Chrome installations running versions below 150.0.7871.128.
- Separate devices that have not downloaded the update from those that have not restarted.
- Set a restart deadline and enforce it.
- Check for unmanaged installations on employee-owned devices, VDI instances, and kiosks.
- Prioritize high-risk users as described.
- Do not describe these flaws as zero-days; no exploitation has been confirmed.
- Monitor Google’s advisory page for expanded technical details once the disclosure window opens.

None of this is novel. But the discipline of browser patching is often where security programs quietly fail. Three Critical memory-safety bugs in one release should be enough to justify a couple of hours of focused effort.

The Bigger Picture

Google will likely lift the restricted access on the underlying bug reports once the majority of users have moved to the patched build. At that point, defenders and attackers alike will get a closer look at the root causes. Until then, the best defense is speed. Every hour a vulnerable browser remains running is an hour when a reconnaissance-phase attacker could be probing for a way in.

Chrome 151 is already in early stable rollout, but that doesn’t supersede this patch. Users on the 150 branch should not wait for the next feature bump. The July 17 release fixes seven real vulnerabilities, and the CVE numbers are now public. The rest is operational.