CVE-2021-22017 is an improper access control vulnerability in VMware vCenter Server. CISA added it to the Known Exploited Vulnerabilities catalogue on 10 January 2022, which means attackers have used it in real attacks. Rhttproxy as used in vCenter Server contains a vulnerability due to improper implementation of URI normalization.
What the vulnerability means for access control
Improper access control in a platform component means a request can reach functionality or data that should have been blocked. In vCenter Server, URI normalization is part of how requests are interpreted, so flaws there can let an attacker bypass intended policy checks and reach protected administrative paths.
That matters because vCenter sits at the center of VMware estate administration. A weakness in request handling can therefore turn a single web-facing flaw into broad control over inventory, configuration, and downstream virtual infrastructure.
Why URI normalization bugs are dangerous in management software
URI normalization is supposed to make different encodings or path forms resolve consistently. When the normalization logic is wrong, one path variant may be treated as harmless by the filter but still accepted by the backend, which creates a classic access control mismatch.
Management interfaces are especially sensitive to this pattern because they often expose privileged functions behind URL routing, not just a simple login page. If an attacker can steer a request around the intended route checks, they may reach administrative actions without the access decision that should have protected them.
How organisations assess exposure and verify remediation
For a CVE like this, exposure checking starts with a complete asset inventory for every vCenter Server instance, including lab, disaster recovery, and internet-exposed deployments. Teams should then compare those instances against the vendor advisory and the NIST National Vulnerability Database entry, rather than relying on product name alone.
Because CISA placed this issue in the KEV catalogue, the practical question is not whether the flaw exists in theory, but whether any reachable instance is still vulnerable in the environment. The most reliable review is a version- and configuration-specific check paired with external exposure analysis, especially where management services may be reachable from broader admin networks or through jump hosts.
Authoritative CVE records from the CVE Program help anchor the incident to a unique identifier, while vendor guidance remains the source of truth for affected builds and fixed releases.
Detection, response, and identity impact after exploitation
Once a management-plane access control flaw is exploited, defenders should look for suspicious requests to privileged vCenter paths, unusual URI encodings, and administrative actions that do not match normal operator behaviour. Post-patch review should also examine whether the attacker used the initial foothold to modify roles, create accounts, alter sessions, or stage further access into virtualized workloads.
Identity impact can be material if exploitation led to credential theft, session theft, or use of service credentials tied to management workflows. In that case, password rotation alone is not enough; organisations should review administrator accounts, API tokens, and any service accounts that could have been used to pivot from vCenter into adjacent systems.
Risk and Threat Considerations
This vulnerability is dangerous because it targets the control plane that administers many systems at once. If an attacker bypasses access checks in vCenter Server, the result can be much broader than a single application compromise, especially when the platform is trusted to manage hosts, guests, and infrastructure changes.
Failure mechanism: A flawed URI normalization path can let malicious requests bypass route-based authorization checks, exposing privileged functions that should never be reachable by an unauthorised caller.
Impact: Successful exploitation can lead to administrative compromise, infrastructure tampering, data exposure, and follow-on access to other systems managed through the same vCenter environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Improper access control maps directly to enforcing approved access decisions. |
| AU-6 — Audit Review, Analysis, and Reporting | Detection of suspicious URI patterns and privileged actions depends on actionable audit review. | |
| IA-5 — Authenticator Management | Compromise may require rotation of credentials, tokens, or service secrets used in management workflows. | |
| Recommendation — Enforce AC-3 on management-plane requests so only authorised actions reach privileged vCenter functions. Use AU-6 to review vCenter logs for anomalous requests and post-exploitation administrative activity. Apply IA-5 to rotate and revoke any credentials or tokens exposed during exploitation. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The flaw is a software access-control weakness on a critical enterprise platform that demands hardened configuration. |
| CIS-7 — Continuous Vulnerability Management | KEV-listed CVEs require rapid identification, prioritisation, and remediation of vulnerable assets. | |
| Recommendation — Harden vCenter deployments under CIS-4 and remove unnecessary exposure before exploitation occurs. Use CIS-7 to inventory vCenter instances, confirm exposure, and prioritise remediation of the KEV-listed flaw. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | The vulnerability is a reachable management-service flaw that attackers exploit through exposed interfaces. |
| Recommendation — Map exposed vCenter activity to T1190 and hunt for exploitation of the management interface. | ||
| OWASP ASVS | V8 — Authorization | The bug is an authorization failure caused by incorrect request-path handling. |
| Recommendation — Use V8 to validate that request normalization and route checks cannot bypass authorisation controls. | ||
| ISO/IEC 27001:2022 | A.8.8 — Management of technical vulnerabilities | A KEV-listed CVE is a technical vulnerability that needs structured identification and remediation. |
| Recommendation — Track and remediate the vCenter flaw under A.8.8 with verified vulnerability handling and closure. | ||
Practitioner Guidance
What to watch for: Treat vCenter as a high-value management asset and verify exposure with the same urgency you would apply to an external identity or access gateway. Where patching is delayed, reduce reachable surface area, tightly constrain administrative network paths, and assume that any exposed instance may be actively targeted once it appears in the KEV catalogue.
Practitioner takeaway: For management-plane CVEs, the key question is not just whether the system is patched, but whether compromise would let an attacker inherit trust over everything that system controls.