Patching
Chrome 155 fixes seven critical flaws: get the fleet to .84
Chrome's October 13 update fixes 7 critical memory bugs, and an October 15 build adds one more. Target versions and how to force them across a fleet.
Google pushed Chrome 155.0.8059.79/.80 for Windows and macOS, and 155.0.8059.79 for Linux, to the Stable channel on October 13. The update fixes 37 vulnerabilities: 7 rated critical, 29 high and 1 medium. Chrome for Android received 155.0.8059.79 the same day, and Google says it carries the same security fixes. Two days later, on October 15, Google shipped 155.0.8059.84/.85 (155.0.8059.84 on Linux) with 10 more fixes. The critical one among them, CVE-2026-110922, is a use-after-free in Prerender, the feature that loads a page in the background before the user opens it.
Google does not report any of these bugs as exploited. The two updates follow the first Chrome 155 stable build on October 6, which fixed 247 vulnerabilities, four of them critical: use-after-free bugs in Chromecast, Browser, Navigation and Track. Malwarebytes reported that build's Windows and macOS number as 154.0.8037.39/.40, but Google's notes give 155.0.8059.39/.40. A machine that has not relaunched since early October is missing all three. The target for every desktop is now 155.0.8059.84 or later.
How the critical bugs work
Six of the seven critical bugs are use-after-free flaws, in the Browser, PDF, Network, Core, SVG and Media components. A use-after-free happens when code releases a block of memory but keeps a pointer to it and uses it later. If an attacker can get their own data allocated into that freed block first, for example by building objects of the right size with JavaScript, the browser ends up reading the attacker's values as if they were its own, such as a function pointer. That is how a memory bug becomes code execution. Use-after-free accounts for 25 of the 37 fixes in this release.
The seventh critical bug, CVE-2026-110152, is a buffer overflow in ANGLE, reported by Zhenpeng (Leo) Lin of depthfirst on September 30. ANGLE (Almost Native Graphics Layer Engine) translates the WebGL and OpenGL ES calls that web pages make into whatever graphics interface the operating system provides, such as Direct3D on Windows or Metal on macOS. A buffer overflow writes past the end of an allocated buffer and corrupts the memory beside it. Any website can draw with WebGL, so ANGLE handles data straight from untrusted pages.
What sets this batch apart is where the code runs. Chrome renders each site in a sandboxed process with few rights, so a typical renderer bug needs a second bug to escape. The public CVE records for five of the seven describe a remote attacker executing code outside the sandbox, each scored CVSS 9.6: the ANGLE bug, CVE-2026-110149 in Browser, CVE-2026-110136 in PDF, CVE-2026-110161 in Network and CVE-2026-110165 in Core. Four are triggered by a crafted HTML page, so the user only has to load a page. The Network record says "crafted network traffic" instead. The SVG (CVE-2026-110148) and Media (CVE-2026-110151) bugs give code execution inside the sandbox and score 8.8.
The CVE records for the ANGLE and Core bugs name "Google Chrome on Android", while Google's desktop release notes list both as fixed in the desktop build. Treat desktop and Android as affected.
What attackers are doing
Nothing reported so far. Google's notes for the October 6, 13 and 15 releases do not flag any bug as exploited in the wild, and the reporting from PiunikaWeb, DigitBin and SQ Magazine agrees.
The quiet period is the time to roll out. Google's notes say access to bug details "may be kept restricted until a majority of users are updated with a fix", which tells you how Google sees the risk: the danger window is the time between release and broad adoption. Chromium is open source, and each release note links to the full log of code changes in the build. An attacker who compares the old and new source (patch diffing) can often locate the fixed function and work back to the bug without the bug report.
What to do
1. Check the running version
On one machine, chrome://version shows the version of the browser process that is actually running. Chrome downloads updates in the background and switches to them only on relaunch, so an inventory of installed files can show 155.0.8059.84 while the user is still on 154. Our Chrome 154 post covers the file and registry checks that tell the two apart on Windows and macOS.
Across a fleet managed in Chrome Enterprise Core (formerly Chrome Browser Cloud Management), turn on browser reporting under Menu, Chrome browser, Settings, and the Admin console lists each managed browser with its version. Filter for anything below 155.0.8059.84.
2. Force the relaunch
Set RelaunchNotification to 2, which shows a recurring prompt that a relaunch is required and relaunches at the end of the period (1 only recommends it). Pair it with RelaunchNotificationPeriod, in milliseconds. The default is 604,800,000, or seven days, which is too long for this release; 86,400,000 gives users one day. RelaunchWindow sets the time of day the forced relaunch happens. In the Google Admin console the same setting is under Chrome updates, Relaunch notification, where the period is set in hours (1 to 168).
With Group Policy or Intune, these are the same policy names in Google's Chrome ADMX templates, written under HKLM\SOFTWARE\Policies\Google\Chrome. Check that no profile still sets TargetVersionPrefix to an older major version from a past rollout, because that pin holds machines back. On a test machine, chrome://policy should show each policy with status OK.
3. Check the other Chromium browsers
Microsoft Edge, Brave, Opera and Electron apps such as Slack, Discord and Visual Studio Code ship their own copy of Chromium, and they pick up these fixes only when their vendor releases a new build. Microsoft's Edge security release notes say each new Edge build incorporates the latest Chromium security updates, and that the CVE list is added "as soon as available". Edge numbers its builds differently from Chrome, so match a build to these CVEs through Microsoft's notes or its Security Update Guide, not by comparing version strings.
4. Handle machines that never relaunch
Some machines never see the prompt. For kiosks and shared devices that run Chrome for weeks, schedule a nightly restart of the browser or the device through your endpoint tool. On non-persistent virtual desktops (VDI), Chrome updates inside a session are thrown away at logoff, so rebuild the golden image with 155.0.8059.84 and roll the pool. On Linux, Chrome updates through the package manager from Google's repository at dl.google.com/linux, so run your normal apt or dnf update job, then restart Chrome. Linux policies live as JSON files in /etc/opt/chrome/policies/managed.
On the Extended Stable channel, look up the matching build in the Extended Stable entries on the Chrome Releases blog.
A browser release every week
Chrome shipped three security builds in ten days this month, adding up to 294 fixes. A browser on the monthly operating system patch cycle spends most of that time behind. What works is a short forced-relaunch period, a weekly report of running versions for every Chromium-based browser, and a separate plan for the kiosks, VDI pools and Linux hosts that never restart on their own.
Our safeguarding and hardening team sets up browser update and relaunch policies, and security operations can build the version report that shows which machines are still behind. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Chrome Releases: Stable Channel Update for Desktop, October 13, Chrome Releases: Stable Channel Update for Desktop, October 15, Chrome Releases: Stable Channel Update for Desktop, October 6, Chrome Releases: Chrome for Android Update, October 13, HKCERT bulletin, PiunikaWeb, DigitBin, SQ Magazine, Malwarebytes, OpenCVE: CVE-2026-110152, OpenCVE: CVE-2026-110149, Strix: CVE-2026-110161, Strix: CVE-2026-110148, Google: Notify users to relaunch for pending updates, Microsoft Edge security release notes.