How to Fix CVE-2016-3643: SolarWinds Virtualization Manager Privilege Escalation Vulnerability

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚠️ Fix the sudoers policy now. CVE-2016-3643 is in CISA's Known Exploited Vulnerabilities catalog (added 2021-11-03). It is a local root escalation on the SolarWinds Virtualization Manager appliance, so apply the vendor appliance update and scope the appliance's sudoers policy. A network firewall does not address it.

What is CVE-2016-3643?

CVE-2016-3643 is a local privilege escalation flaw in SolarWinds Virtualization Manager 6.3.1 and earlier. Virtualization Manager (VMAN) is not a Windows application. It ships as a Linux-based virtual appliance, an OVA you import into VMware or Hyper-V, and it runs its own CentOS-derived operating system under the hood. That detail matters because it changes everything about how you fix this.

The bug lives in the appliance's sudo configuration. The /etc/sudoers policy on these builds is too permissive. A low-privileged local account, the kind a junior operator or a constrained service identity might hold, can invoke commands through sudo that run as root. The advisory proves it with the simplest possible example: sudo cat /etc/passwd. That single command reads a root-owned file the user should never be able to touch directly. Swap cat for an editor, a shell, or a script and the same misconfiguration hands the attacker complete control of the appliance.

So the impact is total: full root on the box. That lines up with the CVSS 3.1 score of 7.8 High and the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, where confidentiality, integrity, and availability are all rated High once the attacker is in. The CVE record does not assign a specific weakness class beyond CWE-noinfo, but the behavior is a classic sudo-misconfiguration escalation.

One thing to be precise about: the attack vector is Local (AV:L). The attacker is not breaking in over the network here. They already have a foothold, an SSH session, a console login, a compromised low-tier account, and they use the sudo flaw to climb from that foothold to root. That is exactly why a firewall rule does nothing for this CVE, and why the fix is about the appliance's own user and sudo policy rather than any open port.

CISA added CVE-2016-3643 to its Known Exploited Vulnerabilities catalog on 2021-11-03, and the SSVC assessment marks exploitation as active. A working exploit sits on Exploit-DB (entry 39967). This is confirmed real-world abuse, not a paper finding.

Identify whether you are affected

You are exposed if you run a SolarWinds Virtualization Manager appliance at version 6.3.1 or any earlier 6.3.x / 6.x build. Because this is a self-contained appliance, you do not check it with dpkg or rpm -qa against a normal package name. You check the VMAN product version itself.

From the appliance console or an SSH session, confirm the build:

# On the SolarWinds Virtualization Manager appliance (Linux console / SSH)
# The product version is recorded in the appliance, not in a distro package.
cat /etc/solarwinds-release 2>/dev/null || cat /opt/SolarWinds/*/version* 2>/dev/null

# Inspect the sudoers policy that drives this CVE.
# Look for broad NOPASSWD / ALL grants to non-admin users or groups.
sudo cat /etc/sudoers
sudo ls -l /etc/sudoers.d/ && sudo cat /etc/sudoers.d/*

You can also read the version from the VMAN web console (Settings, then About). If the build is 6.3.1 or lower, you are in scope. If a non-administrative account can run anything beyond a tightly scoped allowlist through sudo, treat the appliance as vulnerable regardless of the version string.

How to fix CVE-2016-3643

There are two parts to a real fix: apply the SolarWinds update that corrects the appliance's sudoers policy, and tighten that policy yourself so no low-privileged account can reach root in the meantime. The CVE record does not publish a clean fixed-version string, so do not chase one. Pull the corrected build directly from your SolarWinds Customer Portal or the official advisory, and confirm with SolarWinds support that the package you apply addresses the sudo misconfiguration.

Note up front: there is no apt, dnf, yum, winget, or MSI step here. This is a vendor appliance. You update it through SolarWinds' own upgrade path for Virtualization Manager, not through a Linux distro package manager and never through a Windows installer.

Step 1: apply the SolarWinds update

1. Sign in to the SolarWinds Customer Portal and download the latest available Virtualization Manager appliance update for your line. SolarWinds distributes VMAN fixes as appliance updates, not as OS packages.
2. Snapshot the VMAN virtual machine in VMware or Hyper-V before you touch anything, so you can roll back cleanly.
3. Apply the update through the VMAN admin console (the appliance's own Upgrade / Maintenance workflow) following the version-specific steps in the SolarWinds documentation.
4. Reboot the appliance if the upgrade workflow asks for it, then re-check the product version from the console.

Step 2: fix the sudoers policy on the appliance

This is the heart of the vulnerability and it is the one thing you can correct immediately, even before a vendor update lands. Edit sudoers only with visudo so a syntax error cannot lock you out:

# On the VMAN appliance, as root. Always use visudo to edit safely.
sudo visudo

# Remove or scope down any line that gives broad root access to non-admin
# users or groups, for example an over-permissive entry like:
#   someuser  ALL=(ALL) NOPASSWD: ALL
# Replace blanket grants with an explicit, minimal command allowlist, e.g.:
#   svcaccount  ALL=(root) /usr/bin/systemctl restart vman-service

# Then audit drop-in files the same way.
sudo visudo -f /etc/sudoers.d/yourfile

Validate the result before you log out:

# Confirm sudoers parses cleanly (no syntax errors).
sudo visudo -c

# From the low-privileged account, confirm it can NO LONGER read root files.
# This is the exact technique the advisory used. It should now be denied.
sudo -l                 # review what this account is still allowed to run
sudo cat /etc/passwd    # expected: "Sorry, user ... is not allowed to execute ..."

If you can't patch immediately

Because CVE-2016-3643 is a local escalation, the meaningful interim controls are about who can reach a shell on the appliance, not about network ports. A firewall in front of VMAN does not address this flaw, so do not waste a change window on iptables rules expecting them to close it.

Do this instead:

• Cut down local accounts. Every account that can log into the appliance is a potential launch point for this exploit. Remove or disable any login that does not strictly need appliance shell access.
• Restrict SSH. Limit SSH to named administrators and a management subnet, and disable direct console/SSH access for service or operator accounts that only need the web UI.
• Fix sudoers now (Step 2 above). Scoping the sudoers policy is the actual mitigation and you can apply it without waiting for the vendor package.
• Watch for abuse. Monitor /var/log/secure (or the appliance's auth log) for unexpected sudo invocations by non-admin users.

# Surface recent sudo activity on the appliance to spot abuse of the flaw.
sudo grep -i sudo /var/log/secure | tail -n 50

Confirm the fix

Verification for this CVE is behavioral, not a version diff. Prove that the previously-working escalation no longer works:

# 1. From a non-admin account on the appliance, the proof-of-concept must fail.
sudo cat /etc/passwd
# Expected: a "not allowed to execute" denial, not the file contents.

# 2. Re-check what each non-admin account may run; it should be a tight allowlist.
sudo -l

# 3. Confirm the product version reflects the vendor update you applied.
cat /etc/solarwinds-release 2>/dev/null

Then re-run whatever vulnerability scanner first flagged CVE-2016-3643 and confirm it clears. If the scanner keys only off the VMAN banner version, make sure its plugin feed is current, since detection metadata for older KEV entries can lag a release. Finally, review the appliance's auth logs for any sudo abuse that may have occurred while the appliance was exposed.

Frequently asked questions

What exactly is wrong in CVE-2016-3643?

The VMAN appliance ships an over-permissive /etc/sudoers policy. A low-privileged local user can run commands as root through sudo, which the advisory demonstrates with sudo cat /etc/passwd. From there it is trivial to take full root on the appliance.

Is CVE-2016-3643 a remote vulnerability?

No. The CVSS vector is AV:L (Local). The attacker must already have a shell or account on the appliance, then uses the sudo flaw to escalate. A network firewall does not fix it; tightening sudoers and restricting local access does.

Does SolarWinds Virtualization Manager run on Windows?

No. VMAN 6.3.x is a Linux-based virtual appliance shipped as an OVA. There is no MSI and no winget package. Any instruction that tells you to run winget, msiexec, apt, or dnf for this product is wrong.

How do I actually remediate it if there is no published fixed version?

Apply the SolarWinds-supplied appliance update that corrects the sudoers configuration from the Customer Portal, and in parallel scope the appliance's sudoers policy with visudo so non-admin accounts can no longer run arbitrary commands as root.

Is there a public exploit, and is it actively exploited?

Yes on both counts. Exploit-DB entry 39967 and a Full Disclosure post document the technique, and CISA lists CVE-2016-3643 in its Known Exploited Vulnerabilities catalog (added 2021-11-03). Treat it as an emergency change.

References

• Official vendor advisory: http://seclists.org/fulldisclosure/2016/Jun/26
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2016-3643
• CISA KEV catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Additional reference: https://www.exploit-db.com/exploits/39967/
• Additional reference: http://packetstormsecurity.com/files/137487/Solarwinds-Virtualization-Manager-6.3.1-Privilege-Escalation.html

Written by Sai Kiran Pandrala on 2026-05-25. Sourced from the official vendor advisory, the NVD record, and the CISA KEV listing. Always confirm against the vendor advisory before applying changes in production.

Related fixes

Other CVEs touching related code paths, worth patching together with this one:

• How to Fix CVE-2016-3715: Arbitrary file deletion in ImageMagick
• How to Fix CVE-2016-9079: Use After Free in Firefox
• How to Fix CVE-2016-8562: Security vulnerability in SIMATIC CP
• How to Fix CVE-2016-0167: Privilege escalation in Microsoft Windows Win32k
• How to Fix CVE-2016-7836: Remote Code Execution in SKYSEA Client View