Google Chrome Multiple Vulnerabilities in Nessus: How to Fix Them

Google Chrome < 134.0.6998.177 Vulnerability is a Nessus finding meaning a Windows host runs a Chrome build older than the fix for CVE-2025-2783, a sandbox escape exploited in the wild. Fix it by updating Chrome to the current stable release, forcing a browser relaunch so the update actually applies, and removing unmanaged per-user copies.

What the scanner is actually detecting

Tenable publishes a new plugin in its Google Chrome < version series whenever a stable Chrome release carries security fixes, so a host that stopped updating collects a stack of them. The plugins usually seen together for this finding are:

All three are local checks in the Windows family. Nessus signs in over SMB with credentials, enumerates installed software and compares each install’s version with the first fixed build. Nothing is exploited. Each plugin only asks “is the installed version lower than X?”, so a single update to the current stable build clears every older Chrome plugin at once. Plugin 233369 is Microsoft Edge: the same Chromium bug, fixed through Edge’s own updater, so it needs its own step below.

The plugin output lists every install path it found. A path under C:Users<name>AppDataLocalGoogleChrome is a per-user install, which your system-wide deployment tools may not touch at all.

Real-world risk

CVE-2025-2783 is an incorrect handle in Mojo, Chromium’s inter-process communication layer, that let a remote attacker escape the Chrome sandbox on Windows through a malicious file. Tenable lists a CVSS 3.1 base score of 8.3 with high attack complexity and required user interaction. Google’s March 25, 2025 release notes credit Kaspersky researchers and state that Google was aware of reports that an exploit existed in the wild, and CISA lists the CVE in its Known Exploited Vulnerabilities catalog.

Keep it in proportion: a sandbox escape is usually one link in a chain, and the attacker still needs the user to open or visit something. The exposure is highest on workstations, VDI and jump hosts where people browse, and lower on servers where Chrome was installed once and never opened. The more important signal is age. This fix shipped in March 2025, so any host still flagged has missed every Chrome security release since then, not just this one.

How to confirm it on the host

List every Chrome binary, machine-wide and per-user, with its version and whether an update is staged but waiting for a relaunch:

$paths = @(
  "$env:ProgramFilesGoogleChromeApplicationchrome.exe",
  "${env:ProgramFiles(x86)}GoogleChromeApplicationchrome.exe"
) + (Get-ChildItem 'C:Users*AppDataLocalGoogleChromeApplicationchrome.exe' -Force -ErrorAction SilentlyContinue).FullName

$paths | Where-Object { $_ -and (Test-Path $_) } | ForEach-Object {
  [pscustomobject]@{
    Path          = $_
    Version       = (Get-Item $_).VersionInfo.ProductVersion
    PendingUpdate = Test-Path (Join-Path (Split-Path $_) 'new_chrome.exe')
  }
}

When Chrome is running during an update, the installer stages the new build as new_chrome.exe and swaps it in only when the browser restarts. PendingUpdate = True therefore means the fix is downloaded but not active. Next, check whether policy is holding updates back:

Get-ItemProperty 'HKLM:SOFTWAREPoliciesGoogleUpdate' -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:SOFTWAREPoliciesGoogleChrome' -ErrorAction SilentlyContinue |
  Select-Object Relaunch*

Red flags are UpdateDefault or Update{8A69D345-D564-463C-AFF1-A69D9E530F96} set to 0 (updates disabled) or 2 (manual only), a TargetVersionPrefix{8A69D345-D564-463C-AFF1-A69D9E530F96} pinned to an old major version, and AutoUpdateCheckPeriodMinutes set to 0. The GUID is Chrome’s application ID in Google Update. On the machine itself, chrome://settings/help shows the running version and chrome://policy shows which policies Chrome received.

How to fix it

Single machine

Open chrome://settings/help. Chrome checks for an update, downloads it and offers a Relaunch button; the finding is not fixed until you click it. To reinstall or upgrade in place without the updater, deploy the Chrome Enterprise 64-bit MSI (GoogleChromeStandaloneEnterprise64.msi, from the Chrome Enterprise download page) with your software distribution tool:

msiexec /i GoogleChromeStandaloneEnterprise64.msi /qn

Users who already have Chrome open still need to relaunch before the new version runs.

Keep Google Update enabled with Group Policy

Load the Google Update templates (google.admx and GoogleUpdate.admx into C:WindowsPolicyDefinitions, with the ADML files in the language subfolder), then open Computer Configuration > Policies > Administrative Templates > Google > Google Update > Applications > Google Chrome:

• Update policy override: Enabled, Always allow updates (recommended).
• Target version prefix override: Not Configured, unless you pin deliberately and move the pin with every release.
• Under Google Update > Preferences, leave Auto-update check period override unset or above 0.

The registry equivalent for testing on a single device:

reg add "HKLMSOFTWAREPoliciesGoogleUpdate" /v "Update{8A69D345-D564-463C-AFF1-A69D9E530F96}" /t REG_DWORD /d 1 /f

Google Update honors these policies only on devices joined to Active Directory or Microsoft Entra ID, managed by MDM, or enrolled in Chrome Enterprise Core. A standalone workgroup PC ignores them.

Force the relaunch that applies the update

Chrome updates silently in the background, but a user who never closes the browser keeps running the old, vulnerable build. The RelaunchNotification policy fixes that. At Computer Configuration > Policies > Administrative Templates > Google > Google Chrome, enable Notify a user that a browser relaunch or device restart is recommended or required and choose Required. Chrome then shows a recurring warning and relaunches itself when the notification period ends, restoring the user’s session. Set the period with RelaunchNotificationPeriod in milliseconds: the default is 604800000 (7 days) and the minimum is 3600000 (1 hour).

reg add "HKLMSOFTWAREPoliciesGoogleChrome" /v RelaunchNotification /t REG_DWORD /d 2 /f
reg add "HKLMSOFTWAREPoliciesGoogleChrome" /v RelaunchNotificationPeriod /t REG_DWORD /d 86400000 /f

The example above allows 24 hours. If a forced relaunch mid-shift is unacceptable, RelaunchWindow (Chrome 93 and later) defers the end of the period into a time window you choose, at the cost of a slightly later fix.

Remove per-user installs

Per-user copies live under %LOCALAPPDATA%GoogleChromeApplication, update under the user’s own context and often escape central reporting. Google documents that once a system-level Chrome is present, the per-user copy uninstalls itself the next time the user launches it. Dormant accounts never launch it, so remove those copies explicitly by running the registered uninstaller in that user’s context (for example from a logon script):

$u = Get-ItemProperty 'HKCU:SoftwareMicrosoftWindowsCurrentVersionUninstall*' -ErrorAction SilentlyContinue |
  Where-Object DisplayName -eq 'Google Chrome'
if ($u) { cmd /c "$($u.UninstallString) --force-uninstall" }

The stored string already includes --uninstall; --force-uninstall skips the confirmation prompt. Do not add --delete-profile. To stop new per-user installs, set Allow installation under Google Update > Applications > Google Chrome to Always allow Machine-Wide Installs, but not Per-User Installs (value 4). It only governs installs through Google’s installer and updater, so pair it with application control if you need a hard block.

Microsoft Edge (plugin 233369)

Update from edge://settings/help, and make sure Microsoft Edge Update is not blocked: Update{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} under HKLMSOFTWAREPoliciesMicrosoftEdgeUpdate should be 1 (Always allow updates), set through Administrative Templates > Microsoft Edge Update > Applications > Microsoft Edge > Update policy override. Edge supports the same RelaunchNotification and RelaunchNotificationPeriod values under HKLMSOFTWAREPoliciesMicrosoftEdge. See Microsoft’s Edge Update policy reference.

How to verify the fix and rescan

1. Re-run the inventory script. Every path should report a version at or above the plugin’s fixed version, with PendingUpdate False.
2. On a sample device, open chrome://policy, click Reload policies and confirm the update and relaunch policies show status OK.
3. Rescan with the same credentialed policy. These are local checks, so an unauthenticated scan cannot confirm closure.

Chrome findings come back whenever a device stops updating, so trend them in your patch compliance metrics rather than treating each plugin as a one-off ticket.

What can break and how to roll back

• Forced relaunch: with Required, Chrome closes at the deadline. Tabs are restored, but unsaved input in web forms can be lost. Tell users what the warning means before enabling it.
• Web apps and extensions: a new major version can change behavior for internal web apps or extensions. Pilot on a small group first.
• Per-user removal: shortcuts pinned to the per-user chrome.exe stop working. Profile data is kept, because both install types use %LOCALAPPDATA%GoogleChromeUser Data.

To roll back, enable Rollback to Target version and set Target version prefix override to the major version you want (for example NNN.) under Google Update > Applications > Google Chrome. Google warns that users lose browsing data on rollback unless Chrome sync or roaming profiles are on, and rollback targets must be version 72 or later. A rollback reopens the vulnerabilities, so time-box it and record it as an exception.

Common false positive reasons

• Updated but not relaunched: not a true false positive, since the running browser is still vulnerable, but it explains “we already patched that”. Check for new_chrome.exe.
• Abandoned per-user installs: copies in profiles of departed users are real files on disk and get reported even if nobody runs them. Remove them rather than excluding the finding.
• Uninstall leftovers: an orphaned folder or registry entry can keep detection firing after Chrome is gone. Confirm chrome.exe exists at the reported path before you remediate.
• Scan timing: Google rolls stable updates out “over the coming days/weeks”, so a scan just after a release can catch hosts that have not been offered it yet.

FAQ

Why does Nessus still report the old version after Chrome updated?

The update is staged but the browser has not restarted. Relaunch Chrome, or enforce it with RelaunchNotification set to Required.

Do I have to fix each Chrome plugin separately?

No. Every plugin checks for a version lower than its fixed build, so installing the current stable release closes all of them at once.

Do the Google Update policies work on non-domain PCs?

No. They apply only to devices that are domain-joined, Entra ID joined, MDM-managed or enrolled in Chrome Enterprise Core.

Can we disable auto-update and push the MSI ourselves?

Google does not recommend it. Chrome security releases do not follow Patch Tuesday, so a manual MSI process must react within days, not weeks.

Tracking this finding across many hosts

A Chrome plugin that keeps returning on the same hosts points to a broken updater, which your vulnerability recurrence rate will show. SITEY imports Nessus results uploaded as .nessus exports, merges duplicates within each scanner and can retest individual Nessus findings after a fix. Its AI can draft host-specific remediation scripts that run only after human approval, deployed by SITEY agents on Windows endpoints and followed by a retest to confirm closure.

Sources

• Tenable: Google Chrome < 134.0.6998.177 Vulnerability, plugin 233331
• Tenable: CVE-2025-2783
• Chrome Releases: Stable Channel Update for Desktop, March 25, 2025
• Google: Manage Chrome updates (Windows)
• Google: Notify users to restart to apply pending updates