CVE-2021-22017

What it actually does

CVE-2021-22017 is an authorization bypass in VMware vCenter Server’s rhttproxy component caused by improper URI normalization. An unauthenticated attacker with network access to vCenter Server HTTPS port 443 can craft non-canonical URLs that are interpreted differently by the proxy and backend services, allowing requests to reach internal vCenter endpoints that should not be externally accessible through the proxy. The primary direct impact is unauthorized access to internal endpoints and potential information disclosure; in practice, this type of flaw is most concerning when chained with other vCenter weaknesses or used for reconnaissance against the virtualization control plane.

Why it matters to the business

vCenter Server is a high-value management plane for virtual infrastructure, so even a medium-severity access-control bypass can create meaningful operational risk. Successful exploitation may expose internal service data, assist attackers in mapping the environment, and provide a foothold for chaining with other VMware vulnerabilities. This vulnerability is listed in CISA KEV, has active in-the-wild exploitation, and the federal remediation due date of 2022-01-24 has long passed, so any remaining exposure should be treated as overdue and urgent despite the moderate CVSS score.

How an attack unfolds

An attacker first identifies an exposed VMware vCenter Server reachable over HTTPS on port 443. They then send specially crafted HTTP requests containing abnormal URI encodings, path normalization tricks, or non-canonical path forms to rhttproxy. Because the proxy improperly normalizes the URI, the request can bypass expected routing or access-control decisions and be forwarded to backend endpoints that are intended to be internal-only. The attacker reviews successful responses for sensitive service metadata, endpoint behavior, or data useful for follow-on activity. In real-world campaigns, this flaw is most likely to be used alongside scanning and exploitation of other VMware vCenter vulnerabilities rather than as a standalone destructive technique.

How to fix it

Upgrade VMware vCenter Server to a fixed, supported release per VMware’s security advisory for this issue. Where applicable, vCenter Server 7.0 should be upgraded to 7.0 U2c or later, and vCenter Server 6.7 should be upgraded to 6.7 U3o or later; use VMware’s current advisory and lifecycle documentation to confirm the exact fixed build for the deployed branch. If immediate patching is not possible, restrict access to vCenter Server port 443 to trusted administrative networks, VPNs, jump hosts, and management subnets only; remove direct internet exposure; monitor rhttproxy logs closely; and apply any VMware-provided workarounds that are explicitly supported for the deployed version. Because vCenter commonly has interoperability dependencies, validate backup, SSO, ESXi host compatibility, plug-ins, and management integrations before and after upgrade.

How to confirm the fix worked

Confirm remediation by checking the vCenter Server version and build against VMware’s fixed release matrix for CVE-2021-22017 and the associated advisory. Verify that port 443 is not reachable from untrusted networks and that firewall or load-balancer rules only permit administrative sources. Run an authenticated vulnerability scan or vendor-supported assessment to confirm the instance is no longer reported vulnerable. Review rhttproxy behavior with benign malformed-path test cases in a controlled environment and confirm they are rejected or normalized safely rather than forwarded to internal-only endpoints. After patching, monitor logs for continued attempts using encoded traversal or abnormal URI patterns, which may indicate ongoing scanning against a previously exposed service.

Typical attack path

1. Scan for internet-accessible or internally reachable VMware vCenter Server HTTPS services on port 443.
2. Fingerprint the target as vCenter Server and infer version/build information from banners, certificates, redirects, or exposed web resources.
3. Send crafted HTTPS requests using unusual URI normalization patterns such as encoded dot-segments, double encoding, duplicate slashes, or encoded path separators.
4. Observe whether rhttproxy forwards the request to internal-only backend endpoints instead of rejecting it.
5. Harvest returned metadata, endpoint responses, or error details to support reconnaissance or chaining with additional vulnerabilities.
6. Use the collected information to guide credential attacks, lateral movement, or exploitation of other vCenter flaws.

How to detect it

To determine whether exploitation already occurred, review VMware vCenter rhttproxy logs, web access logs, reverse proxy logs, WAF logs, load-balancer logs, and network telemetry for HTTPS requests to vCenter containing abnormal URI normalization patterns. Focus on requests with encoded dot-segments, encoded slashes or backslashes, double-encoding, repeated slashes, semicolon path parameters, or attempts to reach backend-looking service paths that are not normally accessed by users. Investigate requests that returned HTTP 200, 301, 302, 401, 403, or unusual 5xx responses, because both successful forwarding and backend error leakage may be useful to attackers. Correlate suspicious requests with source IP reputation, repeated scanning across multiple vCenter paths, unauthenticated access, and subsequent administrative logins or API activity from the same source. Relevant logs commonly include /var/log/vmware/rhttpproxy/rhttpproxy.log, /var/log/vmware/envoy/envoy.log on newer appliances, vCenter service logs under /var/log/vmware/, perimeter proxy logs, and packet metadata from sensors observing traffic to port 443. Because no single unique payload is canonical for this flaw, detection should rely on clusters of URI-normalization anomalies targeting vCenter rather than one exact string.

• /var/log/vmware/rhttpproxy/rhttpproxy.log
• /var/log/vmware/envoy/envoy.log
• /var/log/vmware/vpxd/vpxd.log
• %2e%2e
• %2E%2E
• ..%2f
• ..%2F
• %2e%2e%2f
• %2E%2E%2F
• %252e%252e
• %252f
• %255c
• %2f..%2f
• %5c..%5c
• GET /%2e
• GET /%2E
• GET //
• POST /%2e
• POST /%2E
• ;../
• %3b../
• rhttpproxy

What your security team should do

• Immediately inventory all VMware vCenter Server instances, including internal, lab, disaster recovery, and cloud-adjacent deployments.
• Prioritize patching because the vulnerability is in CISA KEV, has active exploitation, and the remediation deadline has passed.
• Remove direct internet exposure for vCenter Server and enforce administrative access through VPN, privileged access workstations, jump hosts, or management networks.
• Review rhttproxy, reverse proxy, WAF, and load-balancer logs for historical exploitation attempts, especially from September 2021 onward.
• Correlate suspicious URI-normalization attempts with successful HTTP 200, 3xx, or unusual 4xx/5xx responses and follow-on access from the same source IPs.
• Hunt for adjacent VMware exploitation activity because this flaw is commonly useful for reconnaissance and chaining rather than standalone impact.
• Ensure vCenter backups and recovery procedures are current before applying upgrades, then validate ESXi, plug-in, and SSO functionality after patching.
• Create SIEM detections for encoded dot-segments, double-encoded path separators, and abnormal requests to vCenter HTTPS endpoints.