Chrome 157 Patch Tackles 213 Vulnerabilities, Seven Critical

Last updated: November 5, 2026

What should security teams do about Chrome 157’s 213 patched vulnerabilities? Start with the critical detail: Google has released the update, but it has not reported any of the listed flaws as exploited in the wild.

The scale of the release makes rapid deployment a priority. The real question is whether Chrome’s gradual rollout has reached every managed browser before users or attackers do.

Chrome 157’s critical fixes, at a glance

• Google promoted Chrome 157 to the stable channel on November 3 for Windows, macOS and Linux.
• The release contains 213 security fixes, including seven vulnerabilities rated Critical.
• Desktop builds are rolling out as 157.0.8103.38/.39 for Windows and macOS and 157.0.8103.38 for Linux.
• Chrome for Android was also updated to 157.0.8103.38, with availability on Google Play expected over the following days.
• Google disclosed no evidence that the addressed vulnerabilities were exploited in the wild.

What makes this Chrome 157 release stand out

Seven critical flaws is a substantial concentration of risk for a routine browser update. According to SecurityWeek, all seven are memory-safety bugs: four use-after-free defects, two buffer overflows and one memory-corruption issue.

The best-paid finding was a Dawn buffer overflow. Dawn is the open-source, cross-platform implementation of the WebGPU standard, and the researcher received a $10,000 bounty. An ANGLE memory-corruption flaw earned $1,000. ANGLE handles graphics translation within Chrome and was the focus of a separate critical issue described by Malwarebytes, which said a crafted HTML page could potentially let a remote attacker execute code outside the sandbox.

That distinction matters. A browser sandbox is like a locked side room around a suspicious process: even if an attacker controls code inside it, the design is meant to keep the damage contained. A flaw that can escape that boundary turns browser rendering into a more direct route toward system compromise.

SecurityWeek also reported that Google fixed 77 high-severity vulnerabilities. More than a dozen of those were credited to outside researchers. The company published $31,000 in bounties overall, although it had not yet determined payments for 39 findings.

No exploitation has been confirmed publicly, though. SecurityWeek said Google’s advisory mentioned no signs that the defects had been used in attacks. That is reassuring, but it isn’t the same as proof that exploitation is impossible. Browser exploits are often discovered and patched before defenders can observe them.

Why this matters for security teams

Chrome is an easy asset to underestimate because updating it feels like housekeeping. Yet browsers parse hostile content, run complex media and graphics code, and regularly connect to services that handle credentials and business data.

This release also shows why “patch Tuesday” is not a useful endpoint. The vulnerable code may sit inside the stable channel, but the fix travels through automatic updates. Security teams need to confirm that managed Chrome instances have actually restarted onto the new build.

For example, say you run Chrome through enterprise management software and support thousands of employees. Your dashboard shows “157” as the broad release, but that alone doesn’t prove every workstation is protected. Check the full build number, confirm that the browser has relaunched, and identify systems that continue serving 157.0.8103.38 or .39 with the patch missing.

Automatic updates are the easiest option, Malwarebytes reported, but they can stall if Chrome remains open or an extension interferes. That makes update-state monitoring part of vulnerability management, not an optional convenience.

Our analysis: urgent, but not a confirmed active campaign

The unusual feature here is volume, not documented exploitation. A patch bundle containing 213 fixes creates a broad reduction opportunity, especially for organizations that routinely expose browser-based services to untrusted content.

But there’s an important counterpoint: the sources did not report an active ransomware campaign, malware operation or in-the-wild exploitation tied to these Chrome defects. The practical risk is therefore exposure-driven exploitation. If a user visits a malicious page and the browser contains the relevant flaw, the browser may be the initial attack surface.

That is where the critical memory bugs deserve priority. Use-after-free errors can make released memory available for unintended reuse, while buffer overflows can overwrite adjacent data. Neither label tells defenders which pages are dangerous or whether a working exploit exists; those are separate questions.

The reporting also differs slightly in emphasis. Malwarebytes focused on the ANGLE flaw and Android’s ANGLE exposure, while SecurityWeek gave a broader breakdown of the critical bugs, high-severity count, bug types and bounty payments. Together, the accounts show a release dominated by memory-safety defects and broad vulnerability classes.

Common weaknesses in the patch set included incorrect or missing authorization, which Google reported 51 times, and use-after-free defects, reported 45 times. There were also 19 UI-misrepresentation issues, 13 type-confusion flaws, 13 information leaks, 11 out-of-bounds read or write cases, nine improper-input-validation flaws and nine uninitialized-resource defects.

Those counts are not scores showing which flaw will be exploited next. They are a map of where the release concentrated engineering effort.

A practical rollout for defenders

First, confirm the installed build rather than assuming a restart occurred. Open Chrome’s About Google Chrome page or use its Help menu to trigger a check, then relaunch when prompted. Malwarebytes recommends this route for users who do not want to wait for the staged rollout.

Next, map exposure. Identify systems that browse external or untrusted sites, especially developer workstations, help desks, kiosks and machines with privileged access. Browser hardening still matters, but updating is the immediate control for these vulnerabilities.

Finally, watch for signs of suspicious browsing activity while the rollout completes. The absence of reported exploitation does not justify delaying the patch or treating update completion as an all-clear.

What to watch next

The immediate stance is straightforward: accelerate Chrome 157 deployment and verify the exact build on managed endpoints. Don’t describe this as a confirmed active exploitation event; neither source reported one.

What to watch next is any Google or third-party disclosure of exploitation, technical details that clarify which of the seven critical bugs is reachable under realistic conditions, and signs that attackers are weaponizing the patched flaws. Until then, the strongest signal is the defect count itself—and the potentially costly gap between a release reaching the stable channel and every user actually receiving it.