VMSA-2023-0019: How to Update VMware Tools and Fix CVE-2023-20900

VMSA-2023-0019 (CVE-2023-20900) is a SAML token signature bypass in the VGAuth service that ships with VMware Tools. On Windows guests, the fix is VMware Tools 12.3.0 or later, pushed from vCenter, PowerCLI Update-Tools or the silent installer. On Linux, update the distribution’s open-vm-tools package, or legacy tar-based Tools to 10.3.26.

What the scanner is actually detecting

Tenable Nessus plugin 180506, titled VMware Tools 10.3.x / 11.x / 12.x < 12.3.0 Authentication Bypass (VMSA-2023-0019), is a local check in the Windows plugin family. During a credentialed scan it reads the installed VMware Tools version from the registry over SMB and compares it with 12.3.0. It does not try to exploit anything; the result is purely version-based.

The underlying bug sits in VGAuthService, the component that validates SAML tokens for vSphere guest operations. It used the xmlsec library without restricting where the verification key came from, so a token could carry its own signing key and still pass validation.

The same Tools install usually triggers several related plugins, because later advisories moved the minimum version up:

The practical takeaway: stopping at 12.3.0 clears 180506 but leaves 184130 and 233416 open. Install the current Tools release instead and they all close in one maintenance pass.

Real-world risk

VMware first published the advisory on 2023-08-31 describing a man-in-the-middle attacker between vCenter and the VM, with a CVSSv3 score of 7.5. On 2023-09-05 it revised the advisory (VMSA-2023-0019.1) to clarify the attack vector: an attacker who has already been granted Guest Operation Privileges on a VM may elevate privileges if that VM has been assigned a more privileged Guest Alias. The revised score is 7.1 (CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H). Tenable’s plugin page still shows the original 7.5.

In plain terms, exploitation needs existing vSphere guest operation rights plus a Guest Alias that maps to a more powerful in-guest account. There is no unauthenticated path from the internet. VMware lists no workaround, though, so upgrading is the only real fix. Because VMware Tools runs as a privileged service on nearly every VM you own, treat this as routine fleet maintenance: lower priority than internet-facing criticals, but not something to leave open indefinitely.

How to confirm it on the host

On a Windows guest, ask the Tools utility for its version (run in PowerShell):

& "C:Program FilesVMwareVMware ToolsVMwareToolboxCmd.exe" -v

Or read the installed programs registry key, which is close to what the scanner sees:

Get-ItemProperty 'HKLM:SOFTWAREMicrosoftWindowsCurrentVersionUninstall*' |
  Where-Object DisplayName -eq 'VMware Tools' |
  Select-Object DisplayName, DisplayVersion

On a Linux guest:

vmware-toolbox-cmd -v
rpm -q open-vm-tools      # RHEL, Rocky, Alma, SLES
dpkg -l open-vm-tools     # Debian, Ubuntu

If vmware-toolbox-cmd reports 10.3.x and no open-vm-tools package is installed, the guest runs the legacy tar-based Tools that plugin 186616 targets.

To see every VM at once, use PowerCLI against vCenter:

Get-VM | Select-Object Name, @{Name='ToolsVersion';Expression={$_.Guest.ToolsVersion}}

How to fix it

First, check the Tools image on your ESXi hosts

vCenter’s “Install/Upgrade VMware Tools” pushes the Tools version bundled on the ESXi host, not the newest one Broadcom publishes. If the host carries an older bundle, VMs upgrade to that older version. Check what the host has:

esxcli software vib list | grep -i tool

If it is below your target, add the VMware Tools async release component to the cluster’s Lifecycle Manager image or baseline, or install the offline bundle manually:

esxcli software vib update -d "/vmfs/volumes/<datastore_name>/<filename>.zip"

Windows guests from the vSphere Client

1. Select a datacenter, cluster, host, folder or resource pool and open the VMs tab.
2. Select the powered-on VMs, right-click and choose Guest OS > Install/Upgrade VMware Tools.
3. Choose Automatic Upgrade and click Upgrade.

Do not uninstall the old Tools first. On Windows, removing Tools can remove the VMXNET3 driver and lose the guest’s network configuration.

Windows guests with PowerCLI

Update-Tools -VM (Get-VM -Name 'app01') -NoReboot

$vms = Get-Cluster 'Prod-A' | Get-VM | Where-Object {
  $_.PowerState -eq 'PoweredOn' -and $_.Guest.OSFullName -like '*Windows*'
}
Update-Tools -VM $vms -NoReboot -RunAsync

-NoReboot is supported only for Windows guests, and Broadcom notes the VM may still restart depending on the current Tools version, the target version and the host version. Plan a window either way.

Windows guests with the installer (ConfigMgr, Intune, RMM)

Download the current VMware Tools for Windows from Broadcom and deploy it with the documented silent syntax from an elevated Command Prompt:

setup64.exe /S /v "/qn /l*v ""%TEMP%vmmsi.log"" REBOOT=R"

Use the installer file name on your media (Broadcom’s examples use setup.exe). REBOOT=R suppresses the automatic restart, so schedule the reboot yourself.

Linux guests with open-vm-tools

vCenter cannot upgrade open-vm-tools; the distribution’s package manager owns it. Distributions shipped the fix as their own package updates:

sudo dnf update open-vm-tools                 # RHEL 8/9, Rocky, Alma
sudo yum update open-vm-tools                 # RHEL 7
sudo apt-get update && sudo apt-get install --only-upgrade open-vm-tools   # Debian, Ubuntu
sudo zypper update open-vm-tools              # SLES

Expect the version string to stay below 12.3.0 on some releases. Ubuntu 22.04, for example, fixed it in 2:12.1.5-3~ubuntu0.22.04.3 by backporting the patch.

Linux guests with legacy tar-based Tools 10.3.x

Upgrade to 10.3.26 at minimum. The cleaner long-term fix is to remove the tar install and switch to the distribution’s open-vm-tools package, so future Tools fixes arrive through normal OS patching.

Keep Tools current after this round

In the vSphere Client, open Edit Settings > VM Options > VMware Tools and select Check and upgrade VMware Tools before each power on. For many VMs, set the same policy with PowerCLI:

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$spec.Tools.ToolsUpgradePolicy = 'upgradeAtPowerCycle'
Get-Cluster 'Prod-A' | Get-VM | ForEach-Object { $_.ExtensionData.ReconfigVM($spec) }

The VM checks the host for a newer Tools version at power on. For Windows guests, the upgrade itself runs when you power off or restart the VM.

How to verify the fix and rescan

• Re-run VMwareToolboxCmd.exe -v or the PowerCLI report and confirm 12.3.0 or later (ideally the current release).
• On Linux, confirm the package carries the patch rather than trusting the version number:

  rpm -q --changelog open-vm-tools | grep CVE-2023-20900
  zgrep CVE-2023-20900 /usr/share/doc/open-vm-tools/changelog.Debian.gz

• Rescan with a credentialed Nessus scan. Plugin 180506 is a local check, so it needs Windows credentials to read the registry. Check that 184130 and 233416 cleared too.

What can break and how to roll back

• Reboots. Update-Tools restarts the VM unless you pass -NoReboot, and some upgrades restart anyway. Sequence clustered or paired servers so both nodes do not restart together; our guide to reboot orchestration during patching covers the planning.
• Drivers. Tools upgrades replace guest drivers such as VMXNET3. If NSX Guest Introspection drivers are installed, make sure all of them are upgraded in the same run.
• Platform support. VMware Tools 13.x supports only 64-bit Windows, from Windows 7 SP1 and Windows Server 2008 R2 SP1 onward. Keep 32-bit guests on the 12.x line and check its release notes.
• Rollback. Take a VM snapshot before the upgrade and revert it if the guest misbehaves, then delete the snapshot once the VM checks out. On Linux, sudo dnf downgrade open-vm-tools or sudo apt-get install open-vm-tools=<previous-version> restores the old package, and the vulnerability with it.

For large estates, push Tools to a pilot group first and widen from there, as described in ring-based patch deployment.

Common false positive reasons

• Backported Linux packages. Distributions patch open-vm-tools without moving to 12.3.0. A scanner rule that only compares the upstream version will keep flagging a fixed Ubuntu 22.04 or 20.04 guest. Check the package changelog for the CVE.
• Upgrade queued, not yet applied. A Windows VM set to upgrade at power cycle still reports the old version until it restarts.
• Stale results. The finding came from a scan that ran before the upgrade, or from an old imported report.
• Not a false positive: 180506 closing while 184130 or 233416 stays open. That means the host reached 12.3.0 but not a later fixed release.

FAQ

Does upgrading VMware Tools require a reboot?

Often on Windows, because guest drivers are replaced. REBOOT=R and -NoReboot defer it, but plan for one. On Linux, open-vm-tools is an ordinary package update; follow your distribution’s advisory on whether a restart is needed.

Is there a workaround if I cannot upgrade yet?

VMware lists none. Until you upgrade, reduce exposure by reviewing which vCenter roles grant guest operation privileges and which VMs have Guest Aliases assigned.

vCenter shows Tools as current, so why does Nessus still flag it?

“Current” means current relative to the Tools bundled on that ESXi host. If the host bundle is older than 12.3.0, update the host’s Tools component first, then upgrade the VMs again.

Should I install 12.x or 13.x?

Either clears this advisory. For 64-bit Windows 7 SP1 or Server 2008 R2 SP1 and later, the current 13.x release is the simplest choice; 32-bit guests stay on 12.x.

Tracking this finding across many hosts

VMware Tools findings tend to reappear across hundreds of VMs, so it helps to track them per host rather than per plugin. SITEY imports findings from 16 scanners, including Nessus results uploaded as .nessus exports, merges duplicates within each scanner, and can retest individual Nessus findings after an upgrade. Its AI can draft host-specific remediation scripts that go through human approval before SITEY agents run them on Windows and Linux endpoints, followed by a retest to confirm closure.

Sources

• Tenable: VMware Tools 10.3.x / 11.x / 12.x < 12.3.0 Authentication Bypass (VMSA-2023-0019), plugin 180506
• Tenable: VMware Tools for Linux 10.3.x < 10.3.26 Authentication Bypass (VMSA-2023-0019), plugin 186616
• Broadcom: VMSA-2023-0019 VMware Tools updates address a SAML Token Signature Bypass Vulnerability
• Broadcom Developer: PowerCLI Update-Tools command reference
• Broadcom TechDocs: Configure Virtual Machines to Automatically Upgrade VMware Tools