Upgrade VirtualBox

What the Oracle VirtualBox upgrader does

This Automox Worklet™ upgrades Oracle VirtualBox on Windows endpoints to a version you specify. The Worklet enumerates both the 32-bit and 64-bit Windows uninstall registry hives under HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall, locates the VirtualBox DisplayName, and compares the installed DisplayVersion against the target you set in the $AppVersion parameter.

When the installed version is lower than the target, the remediation script launches the uploaded installer (for example, VirtualBox-7.x-x.exe) with the arguments in $InstallerArgs. The default flags are --silent and --ignore-reboot, which run the upgrade without user interaction and skip the post-install reboot prompt. The installer drops the new binaries into C:\Program Files\Oracle\VirtualBox, refreshes the kernel drivers, and rewrites the registry DisplayVersion to the new value.

Endpoints without VirtualBox installed exit as not applicable. That makes the Worklet safe to scope at a broad Windows policy group so the hypervisor upgrade only touches the developer and lab subset, with no side effects on the rest of the fleet.

Why upgrade Oracle VirtualBox on Windows endpoints

Oracle ships VirtualBox security patches on the same Critical Patch Update cycle as the rest of the Oracle stack, and several recent cycles have included guest-to-host escape fixes in the VirtualBox VMM and shared-folder components. An out-of-date hypervisor on a developer laptop turns every malicious guest image into a path to the host. Pinning the fleet to a known-good version closes that window before the next CPU cycle adds a new one.

Oracle VirtualBox advisories regularly cover guest-to-host escapes and kernel-level driver flaws, and an outdated VBoxDrv on a developer workstation is a high-value pivot point. This Worklet walks the uninstall registry on each Windows endpoint, decides per host whether the upgrade applies, runs the silent VirtualBox installer when needed, and reports the result back to Automox so the hypervisor build stays consistent across every developer workstation and lab host under management.

How the VirtualBox version check and upgrade work

1. Evaluation phase: The Worklet enumerates HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall and HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall using Get-ChildItem and Get-ItemProperty, filters with Where-Object for entries whose DisplayName matches $AppName (default: "Oracle VM VirtualBox"), and reads the DisplayVersion property. The script casts both the installed and target versions to [version] and compares them. If DisplayVersion is lower than $AppVersion, the endpoint is flagged for remediation. If the version is equal or higher, the endpoint reports compliant. If no matching DisplayName is found, the endpoint exits as not applicable.

2. Remediation phase: The remediation script resolves the uploaded installer file in the Automox payload directory using $InstallerName (for example, VirtualBox-7.0.14-161095-Win.exe) and launches it with Start-Process -FilePath $InstallerName -ArgumentList $InstallerArgs -Wait. The default ArgumentList is --silent --ignore-reboot, which suppresses the installer UI and the reboot prompt. Start-Process -Wait blocks until the installer returns, the Worklet captures the exit code, and Write-Output records the upgrade status to the Automox activity log.

VirtualBox upgrade requirements

• Windows 10, Windows 11, or Windows Server 2016 or later with the Automox agent installed and running under SYSTEM

• Oracle VirtualBox already present in C:\Program Files\Oracle\VirtualBox; the Worklet only upgrades, it does not install fresh

• VirtualBox installer EXE (VirtualBox-7.x-x.exe) downloaded from oracle.com and uploaded to the Automox policy as a payload file

• $AppName set to the registry DisplayName value, typically "Oracle VM VirtualBox"

• $AppVersion set to the target version in dotted form (for example, 7.0.14)

• $InstallerName set to the exact filename of the uploaded EXE, including the build suffix (for example, VirtualBox-7.0.14-161095-Win.exe)

• $InstallerArgs set to the silent flags (default: --silent --ignore-reboot)

• All guest VMs powered off on the target endpoint; running VMs hold file locks on the VirtualBox kernel drivers and cause the installer to fail mid-upgrade

Expected VirtualBox state after the upgrade

After remediation completes, the DisplayVersion under HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall matches the $AppVersion you supplied, and the binaries under C:\Program Files\Oracle\VirtualBox are the new build. Launching the VirtualBox Manager and checking Help, then About VirtualBox shows the new version string. The next Automox evaluation run reports the endpoint as compliant because the installed version is no longer lower than the target.

Existing virtual machines, snapshots, saved states, and shared folders are preserved across the upgrade. The VirtualBox installer rewrites the kernel drivers (VBoxDrv, VBoxNetAdp, VBoxNetLwf, VBoxUSBMon) and updates the hostonly and NAT network back-ends. Users can re-open the Manager and start their VMs without reconfiguration. Update Guest Additions inside each running VM to match the new host version, otherwise display, clipboard, and shared-folder integrations may regress until the additions are refreshed.

If the installer exit code is non-zero, the Worklet writes "Installation failed" to the Automox activity log with the captured exception. The most common cause is a running VM holding a lock on the kernel drivers; the second is a typo in $InstallerName that does not match the uploaded payload filename. A non-zero exit can also indicate the installer wants a reboot despite the --ignore-reboot flag, which happens when the kernel driver version changes across a major release. In that case, schedule a follow-up reboot through a maintenance Worklet and re-evaluate after the endpoint comes back up.