{ "id": "8f092fb0-43f6-4d4c-998b-d2be2b370e75", "created_at": "2026-04-06T00:17:05.521318Z", "updated_at": "2026-04-10T03:30:33.707693Z", "deleted_at": null, "sha1_hash": "9461ef422abe1cd8774dcefec7fc4153a5b46539", "title": "Mitigating CVE-2022-22948: VMware vCenter Information Disclosure - Pentera", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 86432, "plain_text": "Mitigating CVE-2022-22948: VMware vCenter Information\r\nDisclosure - Pentera\r\nBy Yuval Lazar\r\nArchived: 2026-04-05 23:05:11 UTC\r\nNew zero-day vulnerability joins a chain of recently discovered vulnerabilities capable of operating an end-to-end\r\nattack on ESXi. Organizations should evaluate risk and apply vCenter client patches immediately.\r\nExecutive Summary\r\nPentera Labs’ Senior Security Researcher, Yuval Lazar, discovered an Information Disclosure vulnerability\r\nimpacting more than 500,000 appliances running default vCenter Server deployments. This finding is critical\r\ngiven its potential global impact. According to VMware – more than 80 percent of virtualized workloads are\r\nrunning on VMware technology, including 100 percent of Fortune 500 and Fortune Global 100 companies. The\r\nease and convenience that vCenter offers for managing virtualized hosts in enterprise environments provides\r\ncybercriminals with centralized access and the potential to inflict widespread damage on organizations. In the full\r\nattack vector, threat actors can completely take over an organization’s ESXi’s deployed in a hybrid infrastructure\r\nand virtual machines hosted and managed by the hypervisor from just endpoint access to a host with a vCenter\r\nclient. VMware has issued a patch for the vulnerability that can be found here.\r\nBackground\r\nInstalled in hundreds of thousands of organizations worldwide and used to manage some of their most critical\r\nasset and core systems, VMware vCenter Server is a high-priority target for cybercriminals. Once compromised,\r\nthe ease and convenience that vCenter offers for managing virtualized hosts in enterprise environments will play\r\ninto the adversary’s hands, providing centralized access and widespread damage. Spurred by previously reported\r\nvulnerabilities, increasing demand from our customers, and threats observed in the wild, most notably recent\r\nreports of a python ransomware strain targeting ESXi, Pentera Labs has doubled down on exploring new vCenter\r\nattack vectors. The result of these explorations was the discovery of a new Information Disclosure vulnerability.\r\nThe findings were proactively reported to VMware and later released under CVE-2022-22948.\r\nComplete Attack Vector\r\nThe vulnerability described in this paper is part of a critical kill chain that leads to an ESXi takeover. In the full\r\nattack vector, which is a subject for a future article, we can see that initial endpoint access to a host with a vCenter\r\nclient lends itself to a complete takeover of the organization’s ESXis. The devil and his merry band of demons are\r\nin the details of the chained vulnerabilities exploited as part of this attack vector.\r\nComplete Attack Operation\r\nhttps://pentera.io/blog/information-disclosure-in-vmware-vcenter/\r\nPage 1 of 5\n\nFrom initial access to complete server takeover\r\nImage 1 – Chaining multiple vulnerabilities for a complete view of cybersecurity risk\r\nImpact\r\nPentera Labs firmly believes security readiness is not measured by a single vulnerability or the security team’s\r\nability to discover or patch it. Rather, an organization’s security posture is determined by whether that\r\nvulnerability can be exploited directly or chained to preceding vulnerabilities across the complete attack operation.\r\nIn the case of VMware vCenter vulnerabilities, the adversary can take over the host where the vCenter application\r\nis running and all of its ESXi servers deployed in a hybrid infrastructure and virtual machines hosted and managed\r\nby the hypervisor. Recent reports of ransomware gangs encrypting large amounts of virtual machines highlight the\r\ncriticality of ransomware strains adding this vector to their arsenal of TTPs.\r\nVulnerability Walkthrough\r\nWith our customers’ increased focus on virtualization infrastructure, Pentera Labs researchers set out on a mission\r\nto further enhance its existing attack frameworks used to identify, elevate, exploit and progress attack operations.\r\nAs always, Pentera’s methods are to assume the attacker’s view and identify ways in which the adversary can take\r\nadvantage of critical weaknesses – those known and those yet to be discovered.\r\nThe Credentials Disclosure\r\nAs our starting point, we gained shell access to a fresh instance of a VMware vCenter using a low-privileged user\r\nnamed ‘vpshere-ui’, a member of the “cis” group. So far, so good. During our research on the vCenter client, we\r\nlocated a file containing plaintext login credentials for the client’s postgresDB: “/etc/vmware-vpx/vcdb.properties”. This file is accessible to any of the users that are part of the “cis” group. In other words, any\r\nuser that is a member of the “cis” group can connect to the vCenter’s Postgres database.\r\nGraphical user interface, text Description automatically generated\r\nCredentials to PostgresDB in vcdb.properties \r\nExploring the vCenter internal DB \r\nArmed with the PostgresDB credentials, we proceeded to conduct an examination of the PostgresDB. We used the\r\nfollowing command to connect to the DB, placing the credentials found in vcdb.properties to good use:\r\n/opt/vmware/vpostgres/current/bin/psql -d VCDB -U vc -w \u003cPassword\u003e\r\nHere we discovered that it contains a wealth of information about the ESXi and vCenter, including information\r\nabout the datacenters and virtual machines that are stored on them. For example:\r\nhttps://pentera.io/blog/information-disclosure-in-vmware-vcenter/\r\nPage 2 of 5\n\nVCDB query for information about virtual machines located on the ESXi Another table is the table ‘vpx_host’\r\ncontaining details for a user called ‘vpxuser’ and its password phrase. The vpx_host table holds a record for each\r\nmanaged ESXi, each containing a user called “vpxuser” and a unique password phrase. So we retrieved the\r\npassword phrase, using the command:\r\n/opt/vmware/vpostgres/current/bin/psql -d VCDB -U vc -w \u003cPassword\u003e -c 'SELECT user_name, password FROM vc.vpx_h\r\nText Description automatically generated\r\nThe vpxuser password phrase  Next, we dived in to investigate the “vpxuser”.\r\nvpxuser – who are you?\r\nTurns out that “vpxuser” is a high-privileged user automatically created on the first connection between the ESXi\r\nto the vCenter. The “vpxuser” user is created on the ESXi by default and is designed according to the principle of\r\nleast-privilege, so it can be managed by the vCenter without the use of root. The user is created through a process\r\ncalled “vpxd” which is responsible for communication between the ESXi and the vCenter. There isn’t a lot of\r\ninformation about this user, but we found a comment about it on the “passwd” file on the ESXi. The “passwd”\r\nfile is usually used to keep track of users that have access to a system and it contains information about the user\r\naccounts. We were able to gather a lot of information about the user “vpxuser” from the file. Eventually, it was the\r\ndescription that led us to our next finding – “VMware VirtualCenter administration account”.\r\nWe started investigating the “vpxd” process using IDA in an effort to better understand how the “vpxuser” and its\r\npassword are created and recorded in the PostgresDB that began this journey. Our first step was to search for the\r\nstring “VMware VirtualCenter administration account” using IDA’s Strings tab to see where else this string is\r\nreferenced. This search led to the function related to the creation of the user on the ESXi. From there, we could\r\nidentify the function where the password is created as the figure below shows.\r\nPassword creation function call Diving into the “create_random_password” function, we identified the use of\r\nRandom_Crypto (open-vm-tools), which suggests that the password for this user is randomly created.\r\nGraphical user interface, text, application Description automatically generated\r\n Random_Crypto function in “create_random_password”  We knew that the password must be saved to the\r\nvCenter’s PostgresDB since it is randomly generated upon the first connection and is required for further\r\ncommunication. Yet, as we previously saw in the DB, the password is not saved in plaintext. We immediately\r\nnoticed that the password phrase is encoded in base64, yet the encoded phrase was not readable, so we assumed it\r\nis also encrypted.\r\nText Description automatically generated\r\nhttps://pentera.io/blog/information-disclosure-in-vmware-vcenter/\r\nPage 3 of 5\n\nThe vpxuser password phrase \r\nDecrypting the vpxuser password \r\nWe started exploring the processes the password goes through, as it is created, encrypted, encoded and finally,\r\nsaved in the DB. Eventually, we found the encryption function – only to discover that it uses OpenSSL Symmetric\r\nEVP common encryption method.\r\nA call to the function that encrypts the password\r\nOpenSSL Symmetric Encryption EVP \r\nSymmetric encryption uses the same secret key both to encrypt and decrypt the information. By using symmetric\r\nencryption algorithms, data is converted to a form that cannot be understood by anyone who does not possess the\r\nsecret key. The EVP functions provide a high level interface to OpenSSL cryptographic functions. In order to\r\nperform symmetric encryption or decryption using EVP you will need to know:\r\nThe algorithm – There are several types of encryption algorithms that can be used, such as block or stream\r\nalgorithms. As we later discovered, AES_256_CBC is the algorithm used here.\r\nThe key – You need to possess the secret key to decrypt the message.\r\nThe Initialization Vector (IV) – An Initialization Vector is a random number used in combination with a\r\nsecret key as a means to encrypt data. This number is sometimes referred to as a nonce. An IV is used to\r\navoid repetition during the data encryption process, making it impossible for hackers who use dictionary\r\nattacks to decrypt the exchanged encrypted message by discovering a pattern.\r\nSo now that we know what a symmetric encryption looks like, let’s go back and identify the password creation\r\nmethod. Since the IV is  randomized, we deduced that it’s probably also saved to the DB. And it is! Once we found\r\nthe function where the IV is created, this led the road to the decryption function!\r\nGraphical user interface, text Description automatically generated\r\nThe call to the OpenSSL decryption function We were ready to proceed, having found all 3 prerequisites needed to\r\ndecrypt a symmetric encryption:\r\n1. The algorithm –  We could just tell that the algorithm is AES_256_CBC.\r\n2. The IV – We realized that the first 16 bytes of the password phrase are the IV.\r\n3. The key – We found that the encryption key is created in advance and saved to the file “/etc/vmware-vpx/ssl/symkey.dat”.\r\nThere was still one missing piece to this puzzle. The “/etc/vmware-vpx/ssl/symkey.dat” file is only accessible to\r\nhigh-privileged users, so we needed a method that would give us root privileges to read it. Luckily, we had a\r\nmethod ready on stand-by thanks to our previous research and discovery of CVE-2021-22015, a privilege\r\nescalation vulnerability. Once we extracted the key, we had all the ingredients necessary to decrypt the password.\r\nWe wrote a python script to extract the cleartext password and got ourselves high-privilege credentials to ESXi!\r\nhttps://pentera.io/blog/information-disclosure-in-vmware-vcenter/\r\nPage 4 of 5\n\nAnalysis Summary \r\n1. Logged into the vCenter’s PostgresDB.\r\n2. Found the encoded and encrypted password for vpxuser, a high-privileged user automatically created on\r\nthe first connection between the ESXi to the vCenter.\r\n3. Reverse-engineered the creation of vpxuser to devise a method for decrypting the vpxuser password.\r\n4. Leveraged vScalation (CVE-2021-22015), a Privilege Escalation method also discovered by Pentera Labs\r\nto gain root privileges necessary to decrypt the vpxuser password.\r\n5. Once decrypted, the compromised root account vpxuser  confirms complete takeover of the ESXi server\r\nand a new zero-day is born.\r\nTo remediate CVE-2022-22948, apply the updates listed in VMware’s Advisory site.  There is no known\r\nworkaround.\r\nMITRE Technique\r\nExploitation for Credential Access (T1212) Exploitation for Privilege Escalation (T1068)\r\nAcknowledgments\r\nI wanted to say thanks to everyone at VMware involved with the patch for this vulnerability. They were kind,\r\nprompt in their responses, and very easy to work with.\r\nProof of Concept\r\nWe were ready to verify that we had enough to decrypt the password.  Using a script we created for this purpose,\r\nwe entered the encoded-encrypted vpxuser password phrase and the key as arguments. This is the result we\r\nreceived:\r\nOur Python script decrypted the password! We used the vpxuser credentials to connect via SSH to the managed\r\nESXi with high privileges and gained full control of the ESXi. We could control the ESXi as we wish – extract the\r\nmemory of virtual machines, list inventory, get sensitive files, access sensitive information, you name it. Watch\r\nYuval’s 20-minute online session covering this vulnerability or read the PDF version of this article.\r\nSource: https://pentera.io/blog/information-disclosure-in-vmware-vcenter/\r\nhttps://pentera.io/blog/information-disclosure-in-vmware-vcenter/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://pentera.io/blog/information-disclosure-in-vmware-vcenter/" ], "report_names": [ "information-disclosure-in-vmware-vcenter" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434625, "ts_updated_at": 1775791833, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/9461ef422abe1cd8774dcefec7fc4153a5b46539.pdf", "text": "https://archive.orkl.eu/9461ef422abe1cd8774dcefec7fc4153a5b46539.txt", "img": "https://archive.orkl.eu/9461ef422abe1cd8774dcefec7fc4153a5b46539.jpg" } }