Google patched an actively exploited Chrome vulnerability on September 3. Five days later, it patched another one.

The first, CVE-2026-85046, was a type-confusion flaw in Chrome’s V8 JavaScript engine. The second, CVE-2026-87491, was an out-of-bounds write in the same engine. In both cases, Google said it knew an exploit existed in the wild. CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog.

That is two browser vulnerabilities under active attack in less than a week.

Most firms will assume Chrome handled the problem automatically. It probably downloaded the update. Whether every employee started the updated version is a different question.

The update is waiting for a restart

Chrome and Microsoft Edge are designed to update quietly in the background. That works well until the update needs the browser to close and reopen.

For someone with email, a practice-management system, research tabs, a client portal, and half a dozen documents open, restarting the browser is inconvenient. The update prompt gets postponed. The laptop stays on for days, and the browser session stays open right along with it.

From the employee’s perspective, automatic updates are enabled. From a security perspective, the vulnerable browser may still be running.

This is the same gap we described when discussing Mac patching. A setting that permits automatic updates is not the same as a process that confirms updates were installed. The difference is evidence.

Why the browser deserves its own attention

The browser used to be one application among many. For most law firms and accounting offices, it now carries much of the workday.

Microsoft 365 opens in it. So do client portals, cloud accounting platforms, legal research services, payroll systems, and file-sharing links. Staff members follow links from email into the browser constantly, often while signed in to several business systems.

Both September Chrome vulnerabilities affected V8, the component that processes JavaScript on web pages. CISA said a specially crafted HTML page could exploit CVE-2026-87491 to execute code inside the browser’s sandbox. A separate vulnerability may still be needed to escape that sandbox and take broader control of the computer, but attackers routinely combine flaws when the target is worth it.

That distinction matters. These were not vulnerabilities that let anyone on the internet take over a laptop with no interaction. They still belonged at the top of the patch list because attackers were already using them.

Chrome was the product Google confirmed as affected. Other browsers built on Chromium, including Microsoft Edge, share much of the same underlying code and may require their own vendor updates when Chromium flaws are fixed. A firm needs visibility into both, along with any less common browsers employees have installed.

“Automatic” and “managed” are different

An automatic-update setting answers one question: is the browser allowed to download and install updates?

A managed patching process answers several more:

Which browsers and versions are installed across company devices?
Which computers have received the current security update?
Which updates are downloaded but waiting for a restart?
Which devices have not checked in recently?
Who follows up when an update fails?

Those are the questions that matter after a vendor says a vulnerability is under active attack.

For a 25-person office, checking each computer by hand is possible once. It is not a reliable monthly process. People work remotely, laptops go offline, and employees install a second browser for one website that behaves badly in their usual one. The forgotten browser can remain outdated even when it is rarely opened.

The same issue comes up with personal devices. If employees can sign in to business email or client files from an unmanaged home computer, the firm has no practical way to confirm the browser is current. That is one reason device-management and access policies matter. They let the firm make access decisions based on the condition of the device rather than trusting that every user keeps it updated.

What to check this week

Chrome users can open the three-dot menu, select Help, then About Google Chrome. That page checks for an update and shows whether the browser needs to relaunch.

Edge users can open the three-dot menu, select Help and feedback, then About Microsoft Edge. They can also enter edge://settings/help in the address bar.

If the browser asks to relaunch, save the work and do it. Reopening the same tabs takes less time than recovering from a compromised session.

Then ask whoever manages your computers for the firm-wide view:

Can they report the browser version on every managed device?
How quickly do they require updates when CISA confirms active exploitation?
Do they see computers that downloaded an update but have not restarted?
What happens when a laptop misses the deadline?
Are employees allowed to reach firm data from devices the firm cannot inspect?

A useful answer should include a report or dashboard, not an assumption that the browsers will take care of themselves.

This is also an insurance question

Cyber insurance applications increasingly ask how quickly critical vulnerabilities are patched and whether the firm can verify endpoint compliance. We covered that evidence gap in why insurance applications keep getting longer.

If the firm says critical updates are installed within a set number of days, that answer should include browsers. Saying “Chrome auto-updates” does not show when the update reached each computer or whether a required restart happened.

The two September vulnerabilities will not be the last browser flaws added to CISA’s catalog. The better response is a repeatable process: know what is installed, set a shorter deadline for actively exploited vulnerabilities, require the restart, and keep the report that shows the work was completed.

If you cannot see which browsers are current across every firm device, Artech can help you close that reporting gap.