CVE-2021-21978

What it actually does

VMware View Planner 4.x prior to 4.6 Security Patch 1 contains an unauthenticated remote code execution vulnerability in the View Planner Harness logupload web application. The issue combines improper input validation with missing authorization checks, allowing a network-accessible attacker to upload an arbitrary crafted file into the logupload component and execute code inside the logupload container. Successful exploitation can give the attacker control over the containerized service context, enabling command execution, file modification, data access available to that container, and potential movement to adjacent services depending on container isolation and host configuration.

Why it matters to the business

A vulnerable View Planner Harness exposed to untrusted networks can be fully compromised without credentials or user interaction. Because the vulnerability has a critical CVSS score, very high EPSS likelihood, and weaponized exploit maturity, organizations should treat exposed instances as high-risk even though it is not listed in CISA KEV. Compromise can disrupt benchmarking or lab operations, expose sensitive test data, provide a foothold into VMware-related infrastructure, and potentially lead to broader internal network intrusion if the appliance or container has trusted connectivity.

How an attack unfolds

An attacker first identifies a reachable VMware View Planner Harness running a vulnerable 4.x release. They access the logupload web application and send a crafted unauthenticated upload request that bypasses missing authorization controls and insufficient file validation. Instead of uploading a benign log artifact, the attacker places an executable server-side payload or script in a location where the logupload component will process or serve it. The attacker then triggers the uploaded payload through the web application or container runtime path, resulting in command execution inside the logupload container. From there, they may establish persistence within the container, collect configuration files and credentials accessible to the service, enumerate the container network, and attempt lateral movement or container escape if additional weaknesses are present.

How to fix it

Upgrade VMware View Planner 4.x to version 4.6 Security Patch 1 or later as advised by VMware. If immediate upgrade is not possible, remove external or untrusted network access to the View Planner Harness, restrict access to trusted administrative networks only, place the service behind strong network controls, and monitor or disable the logupload web application where operationally feasible. Because exploitation results in code execution, do not rely solely on patching if the service was exposed; perform compromise assessment and consider rebuilding affected View Planner components from trusted media if suspicious activity is found. Ensure container runtime, host OS, and adjacent VMware infrastructure are also patched and segmented.

How to confirm the fix worked

Confirm the running VMware View Planner version is 4.6 Security Patch 1 or later. Verify that the View Planner Harness and logupload web application are not reachable from the internet or untrusted networks. Perform an authenticated administrative review of installed version/build information and compare it to VMware advisory guidance. From a network perspective, validate that only approved management subnets can reach the Harness service. Review the logupload deployment directory and container filesystem for unexpected uploaded scripts, archives, binaries, or recently modified files. After remediation, test that unauthenticated upload requests to logupload are rejected and that uploaded content cannot be executed.

Typical attack path

1. Scan for network-accessible VMware View Planner Harness instances.
2. Fingerprint the View Planner/logupload web application to confirm a vulnerable 4.x deployment prior to 4.6 Security Patch 1.
3. Send an unauthenticated crafted file upload request to the logupload endpoint.
4. Place a web-executable payload or command-execution artifact through the arbitrary upload flaw.
5. Trigger the uploaded payload to execute commands inside the logupload container.
6. Run discovery commands, collect files and secrets available to the container, and establish command-and-control or persistence.
7. Use the compromised container as a foothold to reach adjacent internal systems or management networks.

How to detect it

Review web access logs for the View Planner Harness and logupload application for unauthenticated POST or multipart upload requests, especially requests that upload files with executable extensions or unusual content types. Examine application logs, container logs, reverse proxy logs, and host audit logs around any upload events for follow-on requests that access the uploaded file. Inspect the logupload container filesystem for unexpected files, recent modifications, web shells, scripts, ELF binaries, archive files, or files with double extensions. Hunt for web service processes spawning shells or interpreters, such as sh, bash, python, perl, curl, wget, nc, or busybox. Review outbound network telemetry from the View Planner host/container for unusual connections to external IPs, command-and-control patterns, or downloads immediately after upload requests. If centralized EDR or container runtime telemetry is available, search for exec events inside the logupload container and unexpected process trees originating from the web application process. Because public weaponized exploitation exists, any exposed vulnerable system should be assessed for compromise even if no obvious indicators are present.

• POST /logupload
• multipart/form-data
• Content-Disposition: form-data; name="file"
• /logupload/
• filename="*.jsp"
• filename="*.war"
• filename="*.php"
• filename="*.sh"
• filename="*.py"
• filename="*.pl"
• filename="*.elf"
• filename="*.so"
• filename="*.jar"
• filename="*.jspx"
• filename="*.jsp%00"
• filename="*.jsp;.jpg"
• filename="*.jsp.jpg"
• /bin/sh -c
• /bin/bash -c
• sh -i
• bash -i
• python -c
• perl -e
• curl http://
• wget http://
• nc -e
• ncat -e
• busybox nc
• /tmp/
• /var/tmp/
• /dev/shm/

What your security team should do

• Immediately inventory all VMware View Planner deployments and identify any 4.x instances older than 4.6 Security Patch 1.
• Prioritize patching or decommissioning internet-exposed or broadly reachable View Planner Harness systems due to weaponized exploit availability and very high EPSS probability.
• Restrict network access to View Planner Harness and logupload services to trusted administrative subnets only.
• Conduct threat hunting on any instance that was exposed before remediation, focusing on suspicious uploads, container command execution, reverse shell activity, and unexpected outbound connections.
• If indicators of exploitation are found, isolate the affected system, preserve logs and container images for forensics, rotate credentials accessible from the container, and rebuild from trusted sources.
• Add SIEM detections for unauthenticated upload attempts, suspicious file extensions in upload paths, and web service child processes executing shell commands.