Security2 publishersAlso reported elsewhere2 min readPublished
Chrome's 247 October 6 security fixes take effect only after a browser relaunch
Google's October 6 Chrome desktop update fixes 247 security flaws, four of them rated Critical. The fixes apply when Chrome relaunches, so a browser nobody closes keeps running the vulnerable build until someone restarts it.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- CVE-2026-106197, a Critical use-after-free in Chrome's Browser module, lets a remote attacker run arbitrary code outside the sandbox through a crafted HTML page.
- A second Critical use-after-free, CVE-2026-106358, sits in Navigation and offers the same out-of-sandbox code execution from a crafted page.
- The V8 JavaScript engine bug, CVE-2026-106240, is a type confusion rated High that gives a remote attacker code execution inside the sandbox.
- Google pushed Android build 155.0.8059.39 the same day to a small share of users and described it as stability and performance improvements.
- ChromeOS was updated as well; Chromebooks fetch the update when they connect and need a restart to finish installing it.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- decision Anyone pushing a forced relaunch outside the normal change window has to justify it on bug class and reach, the only risk evidence published so far.
- exposure An extension that blocks the updater is a failure path separate from users who never close Chrome, so a relaunch prompt alone may leave some machines on the old build.
- constraint With two of the four Critical bugs undescribed, triage cannot rank them against the Browser and Navigation flaws, so the release gets patched as one unit.
Malwarebytes wrote that Chrome flaws allowing code execution outside the browser sandbox can turn a visit to a malicious or compromised website into code running on the underlying operating system, "often without requiring additional exploitation steps" [10]. A use-after-free happens when a program touches memory after it has been freed. The result can be a crash or, in some cases, code the attacker chose [15].
The firm ranked the bugs partly by where they sit. It called the Browser-module bug "a strong priority candidate" because it is in general browser functionality [6]. Navigation is central to ordinary browsing, and Malwarebytes described the second bug as possibly broadly exposed if attacker-controlled pages or redirects can reach the vulnerable path [7].
The V8 type confusion is rated High, and its code execution stays inside the sandbox [8]. Malwarebytes still counted it among three likely high-impact fixes, writing that a flaw in the JavaScript engine is "always a plausible candidate for attacks delivered through malicious web content" [13][9].
The write-up reports none of the 247 flaws as exploited in the wild and ties none to an actor. It describes only two of the four Critical bugs [14][16]. On that record this is patch-cycle work with no external deadline [14].
Chrome's updater is the default path, but Malwarebytes notes that a browser that is never closed falls behind on updates [3]. The manual route ends at the same step: open About Google Chrome, let it check, then click Relaunch to apply the build [4]. Inventory checks need more than one version string. Malwarebytes lists 155.0.8059.39 for Linux and 154.0.8037.39 or .40 for Windows and Mac [2].
What to watch
- A report that any of the four Critical CVEs is under active exploitation; that would set a deadline the current record lacks.
- Published details for the two Critical bugs Malwarebytes did not describe, including their component and whether they reach outside the sandbox.
- A security fix list for Android build 155.0.8059.39 as its rollout widens past the initial small percentage of users.