Google released Chrome 155.0.8059.79/.80 for Windows and macOS and 155.0.8059.79 for Linux on October 13. The release contains 37 security fixes, including seven vulnerabilities rated Critical across ANGLE, the browser process, PDF handling, networking, core code, SVG, and media.
For managed environments, the urgent task is not simply to approve the package. Teams need to update the baseline, make users relaunch the browser, identify unmanaged copies, and avoid confusing Chrome’s Early Stable and Extended Stable channels with the standard Stable target.
Move the Stable baseline to Chrome 155
The Chrome Releases bulletin lists the platform targets and the fixed vulnerabilities. Critical issues include CVE-2026-110152, a buffer overflow in ANGLE, and use-after-free defects affecting the browser, PDF, network, core, SVG, and media components.
Organizations that closed the previous Chrome 154 campaign should create a new target rather than extending the old ticket informally. Security reporting must display the required build by platform and channel. A device on the latest 154 build is no longer compliant with the standard Stable channel.
Verify the process that users are running
Chrome can download an update while existing browser processes continue to execute the older version. Endpoint inventory that reads only the installed package may therefore overstate coverage. Collect the running version after relaunch or reboot and distinguish four states: current and running, update staged but restart pending, installation failed, and no recent telemetry.
Privileged users, administrators, developers with production access, finance teams, and people handling untrusted documents should receive shorter relaunch deadlines. Where policy permits, use browser management to enforce relaunch after a defined grace period rather than waiting indefinitely for user behavior.
Keep channels separate
Google also published an Extended Stable update and began an Early Stable rollout of Chrome 156 to a small percentage of users. Those events do not create one universal target. Standard Stable, Extended Stable, Early Stable, Android, iOS, and ChromeOS have different build numbers and release behavior.
Map each managed population to its actual channel and vendor target. Do not mark an Extended Stable device noncompliant against a standard Stable number, and do not use the limited Chrome 156 Early Stable rollout as proof that the whole fleet should already be on 156.
Cover Android and embedded Chromium
Chrome 155.0.8059.79 for Android carries the corresponding desktop security fixes unless Google notes otherwise. Mobile management should verify application version and device check-in time, not only that automatic updates are enabled. Devices without access to the managed app store or with long update deferrals require an explicit exception.
Electron applications, Microsoft Edge, Brave, and embedded Chromium runtimes do not inherit Chrome’s build automatically. Inventory them as separate products and follow their vendors’ security releases. The same underlying flaw can remain reachable in an application long after the Chrome browser itself is current.
Hunt the gaps in browser inventory
Compare browser-management data with endpoint management, EDR, software inventory, VDI images, and identity sign-ins. Pay special attention to non-persistent virtual desktops, golden images, shared kiosks, developer workstations, portable installations, and devices that have been offline since before October 13.
For VDI, update both active sessions and the base image. Otherwise, a compliant session can be replaced by a vulnerable browser during recomposition. For managed Linux, confirm that the intended repository is active and that package pinning has not frozen Chrome below the target.
Define closure precisely
A useful closure metric is the percentage of active devices observed running the current channel-specific build within the last 24 hours. Keep restart-pending, offline, and exception devices visible in the denominator. Record the owner and expiry date for each approved exception.
Chrome 155 addresses a broad set of memory-safety and authorization failures. Rapid risk reduction depends on the final operational step: proving that the updated browser process is the one users are actually running.
