Chrome 155 Patches 247 Flaws, Four Rated Critical

Chrome 155 Patches 247 Vulnerabilities, Four Rated Critical

Google released Chrome 155 on October 7, 2026, closing 247 security vulnerabilities across the browser's codebase, according to SecurityWeek's reporting on the update. Four of the fixed flaws carry a critical severity rating, the highest classification Google assigns to browser bugs, and all four are use-after-free defects located in the Chromecast, Browser, Navigation, and Track components.

A use-after-free vulnerability is a memory-safety bug that occurs when software keeps referencing a block of memory after it has already been freed for reuse. Attackers who can trigger this condition in a browser can sometimes corrupt memory in ways that crash the program or, in more severe cases, run arbitrary code inside the browser process. Google rates use-after-free bugs as critical specifically because successful exploitation can let an attacker execute code on a victim's device simply by having them visit a malicious web page.

The remaining 243 fixes in Chrome 155 span a mix of severities, from high to low, covering areas such as rendering, extensions, and network handling. Google's own Chrome Releases blog is the authoritative source for the full technical breakdown of each fix, including individual CVE identifiers, once the company publishes its detailed changelog for this version.

Why This Patch Batch Is Larger Than Usual

Fixing 247 issues in a single stable release is a high number even by Chrome's own standards, where monthly updates typically address anywhere from a dozen to a few dozen vulnerabilities. The size of this release suggests Google bundled a broader internal security sweep, external bug bounty submissions, and automated fuzzing results into one update cycle rather than spreading them across several smaller point releases.

That volume does not mean Chrome suddenly became less secure before this update. Most of the 247 issues were likely surfaced through Google's internal testing, its Project Zero research team, and the Chrome Vulnerability Rewards Program, which pays external researchers for responsibly disclosing bugs before they can be weaponized. The four critical use-after-free bugs matter most operationally because they sit closest to remote exploitation without requiring any user interaction beyond loading a web page.

Nothing in the available reporting indicates any of the 247 vulnerabilities, including the four critical ones, were exploited in the wild before Chrome 155 shipped. That distinction matters for prioritization: an actively exploited zero-day demands emergency, same-day action, while a bug patched before public disclosure still requires prompt updating but without the same urgency as an active-attack scenario.

What Healthcare Practices, Tax Firms, and Small Businesses Should Do

Chrome updates itself automatically on most consumer devices, but that default cannot be assumed for every managed environment. Practices and firms running Chrome on shared workstations, point-of-sale terminals, or locked-down clinical and tax software environments should confirm the update actually applied rather than trusting the automatic process alone.

• Verify the version number. Open Chrome, go to chrome://settings/help, and confirm the browser reports version 155 or later. Restart the browser if an update is pending, since Chrome often downloads patches silently but waits for a relaunch to apply them.
• Check managed fleets through your RMM or MDM tool. IT administrators managing Chrome across multiple endpoints, common in healthcare practices and tax offices running HIPAA-regulated or IRS-adjacent systems, should confirm their remote monitoring platform reports Chrome 155 across all machines, not just a sample.
• Prioritize devices that handle patient or client data in a browser. Browser-based electronic health record portals, tax preparation software accessed through Chrome, and online banking sessions are higher-value targets if a critical browser flaw is ever exploited, so these endpoints should be first in line for verification.
• Treat Chromecast exposure as an office device issue too. Since one of the four critical bugs sits in the Chromecast component, any device that casts content, including conference room displays and shared office screens, should also receive the update where applicable.

For individual consumers, the action is simpler: let Chrome update automatically, then manually restart the browser at the end of the day rather than leaving dozens of tabs open indefinitely, since an unrestarted browser does not apply a downloaded patch.

The Compliance Angle for Regulated Practices

Healthcare practices subject to the HIPAA Security Rule and tax preparers subject to IRS Publication 4557 safeguards are both expected to keep current patch levels on systems that touch protected data, even though neither framework names Chrome specifically. An unpatched critical browser vulnerability on a machine that accesses an electronic health record system or a tax preparation portal can become a documentation gap during an audit if a practice cannot show when the patch was verified and applied.

The practical fix is cheap compared to the alternative: log the date Chrome 155 was confirmed on each in-scope device, keep that record alongside other patch management evidence, and repeat the same check for the next Chrome release. Browsers patch monthly or more often, so this is not a one-time task but a recurring line item in a practice's security policy.