CVE-2020-4006 is a command injection vulnerability in VMware Multiple Products. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector contain a command injection vulnerability.
What this vulnerability means in VMware products
Command injection in VMware Multiple Products means attacker-controlled input can reach operating system commands instead of staying inside the application boundary. In products that sit close to authentication, admin workflows, or remote management, that can turn a web-facing flaw into powerful server-side execution.
That matters because command injection is usually not just a data issue, it is a control issue. Once an attacker can steer command execution, they may be able to read configuration, alter services, plant persistence, or pivot into adjacent systems that trust the compromised product.
Why it is dangerous in this product family
The affected VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector products are part of identity and access infrastructure, so exploitation can have outsized impact. A compromise here can expose sessions, administrative trust relationships, connectors, and the management plane that other systems depend on.
For this reason, treat the vulnerability as an infrastructure risk rather than a narrow application bug. Even when the vulnerable service is only one component in a larger environment, command execution on an access layer can become a launching point for broader compromise.
For background on the vulnerability record and authoritative product details, use the CVE Program and the NIST National Vulnerability Database, then confirm patch guidance in the vendor advisory.
How organisations check exposure and reduce blast radius
Exposure review starts with asset inventory, because organisations often miss connector deployments, internet-facing appliances, or older instances that are still reachable from outside. The next question is whether the service is exposed to untrusted users, whether it is reachable from the internet, and whether the vulnerable role is actually deployed in production.
When immediate patching is not possible, compensating controls should narrow access to the product as much as practical. That usually means restricting network reachability, limiting administrative exposure, tightening segmentation, and monitoring the affected host for unexpected command execution or configuration changes.
The vulnerability should also be prioritised using active exploitation context, not just theoretical severity. CISA’s KEV listing is a strong signal that this is an exploitation-priority issue, so a slow remediation cycle creates avoidable risk.
Use a structured vulnerability process such as NHIMG’s Vulnerability Management Guide to connect asset scope, KEV status, remediation timing, and verification into one workflow.
Detection, compromise review, and recovery focus
After remediation, organisations should assume that exploitation may have occurred before the fix landed. Review logs for anomalous commands, unexpected child processes, suspicious service changes, new local accounts, outbound connections, and signs that the product was used as an execution foothold.
Because this is a server-side execution issue, compromise review should not stop at the application itself. Inspect neighbouring systems that trust the product, and check whether stored credentials, tokens, certificates, or connector secrets could have been accessed during the intrusion window.
Where identity infrastructure is involved, the most important recovery question is whether attacker activity could have preserved access after the vulnerability was removed. If so, credential rotation, session invalidation, and trust relationship review become part of incident response, not optional hardening.
For a broader view of how attackers use exposed keys, tokens, and compromised services to move beyond the initial foothold, see the State of NHI and AI Agent Breach Report 2026.
Risk and Threat Considerations
Command injection in access and identity infrastructure is dangerous because it can convert a single exposed management service into broad server control. That creates a realistic path to persistence, lateral movement, and theft of sensitive configuration or trust material.
Failure mechanism: An attacker supplies input that is passed into an operating system command, then uses the resulting execution context to read secrets, change services, or stage follow-on access.
Impact: The compromise can extend beyond the vulnerable product itself, affecting sessions, connectors, downstream trust, and any system that depends on the compromised access layer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Addresses patching and mitigation for exploited command injection in exposed products |
| RA-5 — Vulnerability Monitoring and Scanning | Supports asset exposure review and KEV-driven identification of vulnerable instances | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Applies to log review and post-patch compromise investigation after command injection exploitation | |
| Recommendation — Prioritize SI-2 remediation for affected VMware components and verify compensating controls until patching completes. Use RA-5 to continuously identify exposed VMware instances and confirm where the vulnerability is reachable. Use AU-6 to review logs for suspicious commands, child processes, and post-exploitation activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Covers prioritising and remediating KEV-listed vulnerabilities in exposed systems |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Supports hardening and exposure reduction for internet-facing VMware access components | |
| Recommendation — Apply CIS-7 to inventory, prioritise, and remediate the affected VMware products quickly. Use CIS-4 to restrict exposure and harden the VMware deployment while remediation is in progress. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a high-priority exposure when the product is internet-reachable or supports privileged access paths. The most important operational question is not whether the bug exists, but whether the deployment can be reached and abused before remediation lands.
What to watch for: Focus on unusual process launches, unexplained configuration drift, unexpected outbound traffic, and any evidence that the appliance or connector began behaving like a foothold rather than a trusted service.
Practitioner takeaway: Remediate quickly, verify exposure from the network edge inward, and review identity-bearing material as part of the post-fix investigation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org