Is CVE-2021-22017 (VMware vCenter Server Improper Access Control) being exploited in the wild?

Yes. CISA added CVE-2021-22017 to its Known Exploited Vulnerabilities catalogue on 10 January 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Rhttproxy as used in vCenter Server contains a vulnerability due to improper implementation of URI normalization. Any organisation running the affected product should treat remediation as urgent.

What active exploitation means for CVE-2021-22017

CISA’s KEV listing is the practical signal that matters here: this is not a theoretical flaw or a lab-only proof of concept. For defenders, the immediate question is whether the vulnerable vCenter Server instance is exposed, reachable, and still accepting traffic that could hit the affected rhttproxy path. That determines whether remediation must be treated as an incident response priority rather than routine maintenance.

For a VMware vCenter Server issue, exposure is often broader than teams expect because vCenter is usually central to virtual infrastructure administration. If an attacker can exploit the access-control weakness, the impact can extend well beyond a single management interface, so inventorying every reachable vCenter instance is the first step before any risk discussion about blast radius or downtime.

When you are checking scope, use the CISA Known Exploited Vulnerabilities Catalog and the CVE Program record together, then verify each instance against the vendor’s guidance rather than relying on the CVE title alone.

Why remediation should be urgent even before you confirm abuse

“Exploited in the wild” changes the response posture. It means you should assume the flaw is already part of attacker tradecraft, not just a future risk, and that delay increases the chance of opportunistic scanning or follow-on access. In practice, this raises the priority of isolation, patching, and compromise checks above less urgent change windows.

Because vCenter Server is a high-value administrative plane, compromise can enable far more than a single service outage. A successful exploit can expose credentials, session state, administrative workflows, and downstream management functions, which is why teams should treat the issue as a potential path to broader infrastructure control, not only as a point vulnerability.

For a management-plane issue like this, the operational priority is to protect the control surface first, then investigate whether access was already abused. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the KEV, emergency patching, and post-patch hunting sequence that applies to actively exploited flaws.

What to check if patching is delayed

If you cannot remediate immediately, the safest assumption is that exposure exists until proven otherwise. Restrict network reachability to the narrowest possible administrative paths, review authentication logs around the vCenter management plane, and look for any sign of unusual requests, unexpected admin actions, or new accounts and sessions created near the exposure window.

When the vulnerable service may have been used for interactive administration, rotate any credentials that could have been exposed through the management path, including privileged accounts used to access vCenter and any adjacent automation accounts with broad virtual infrastructure rights. Also validate whether backup, monitoring, or orchestration tools authenticated through the same trust boundary.

For this kind of response, the practical benchmark is not “did we see a clear alert,” but “have we reduced the attack surface enough that exploitation becomes materially harder while we investigate.” If you need a broader remediation and prioritisation model, the Vulnerability Management Guide covers KEV triage, exception handling, and verification in a way that fits exploited infrastructure flaws.

Risk and Threat Considerations

Actively exploited management-plane flaws are dangerous because they combine initial access potential with high-trust administrative reach. In a platform like vCenter Server, that can turn a single access-control issue into a route toward broader virtualisation control, persistence, and repeated re-entry if the attacker can establish credentials, sessions, or tooling access.

Failure mechanism: An attacker abuses improper URI normalisation in the rhttproxy path to bypass intended access controls, reach restricted functionality, and potentially pivot into administrative workflows that were assumed to be protected.

Impact: The likely consequence is management-plane compromise or follow-on intrusion across the virtual environment, which can affect availability, integrity, and the confidentiality of administration data and credentials.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited flaws require prioritised vulnerability handling and verification.
Recommendation — Prioritise KEV-listed vulnerabilities for rapid remediation and post-fix validation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about known exploited vulnerability exposure and triage.
	SI-2 — Flaw Remediation	Remediation urgency and verification are central for an actively exploited product flaw.
Recommendation — Scan for exposed instances and track remediation until the vulnerability is removed. Remediate the flaw promptly and confirm the fix across all affected systems.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	The subject is an actively exploited vulnerability that must be managed and verified.
Recommendation — Triage, remediate, and record exploited vulnerabilities through formal vulnerability management.
OWASP ASVS	V16 — Security Logging and Error Handling	Post-exploitation checking depends on trustworthy logs and detection evidence.
Recommendation — Retain and review logs that can prove or disprove exploitation attempts.

Practitioner Guidance

What to verify: Confirm whether each vCenter instance is internet-facing, reachable from user networks, or exposed through shared administrative paths. Then verify that the vendor remediation state matches the exact deployment, because management appliances are often missed in standard server patch inventories.

Decision rule: If you cannot patch immediately, treat the system as a potentially compromised control plane and focus on containment, log review, and credential rotation before concluding there is no abuse. If patching is complete, still perform targeted hunting for suspicious administrative activity around the exposure window.

Practitioner takeaway: For KEV-listed infrastructure flaws, the absence of confirmed compromise is not a reason to defer action, because the main operational question is whether the attacker had enough time and reach to turn a single vulnerability into broader administrative access.