CVE-2022-22948

What it actually does

CVE-2022-22948 is an information disclosure flaw in VMware vCenter Server and VMware Cloud Foundation caused by improper file permissions on vCenter Server files. An attacker who already has non-administrative access to the vCenter Server can read sensitive files that should not be accessible to that privilege level. The vulnerability primarily affects confidentiality: it can expose configuration data, secrets, credentials, certificates, tokens, logs, or other sensitive operational information depending on the deployed version and file contents. It does not directly provide code execution or service disruption, but disclosed information may enable follow-on privilege escalation, lateral movement, or compromise of managed virtualization infrastructure.

Why it matters to the business

A successful exploit can expose sensitive vCenter information to a lower-privileged user, increasing the risk of administrative compromise of the virtualization management plane. Because vCenter commonly controls large numbers of virtual machines and critical workloads, leaked credentials, certificates, or configuration details could support broader infrastructure compromise. This vulnerability is listed in CISA KEV, has known exploitation in the wild, and had a federal remediation due date of 2024-08-07, so organizations should treat unpatched affected systems as high-priority even though the CVSS score is moderate. No ransomware use is identified in KEV for this CVE, but the flaw can still materially aid intrusion operations.

How an attack unfolds

An attacker first obtains valid, non-administrative access to a vulnerable vCenter Server or otherwise gains a low-privileged foothold on or against the vCenter appliance. The attacker then abuses overly permissive file permissions to read files that should be restricted to privileged service or administrative accounts. The attacker reviews the exposed data for credentials, service configuration, authentication material, certificates, tokens, internal hostnames, network details, or operational logs. If useful secrets are found, the attacker can attempt to authenticate as a more privileged user or service, pivot into connected VMware services, enumerate managed ESXi hosts and virtual machines, or combine the disclosed information with other vulnerabilities for deeper compromise. Public reporting and KEV inclusion indicate real-world exploitation, so defenders should assume that accessible sensitive files may have been inspected on unpatched internet- or enterprise-accessible vCenter systems.

How to fix it

Upgrade affected VMware vCenter Server and VMware Cloud Foundation deployments to a version containing VMware’s fix for CVE-2022-22948. Because no exact fixed versions were provided in the input, use the applicable VMware Security Advisory and product release notes for the deployed major and minor version, and verify that all vCenter Server appliances and Cloud Foundation components are updated. If immediate patching is not possible, reduce risk by restricting access to vCenter management interfaces, limiting shell and appliance access to trusted administrators only, enforcing least privilege for vCenter users, disabling unnecessary local accounts, auditing file permissions, and rotating any secrets that may have been exposed. For systems that remained vulnerable after the KEV due date, prioritize emergency remediation and post-remediation credential review.

How to confirm the fix worked

Confirm the deployed vCenter Server or VMware Cloud Foundation version is at or above the VMware fixed release for the affected branch. Validate that vCenter patch levels match the vendor advisory, not only the appliance build label. Review file permissions on sensitive vCenter configuration, certificate, credential, and log locations to ensure they are restricted to expected privileged users and services. Test with a non-administrative account to verify that sensitive files are no longer readable. Also verify that management access to vCenter is limited to approved networks and that low-privileged users cannot obtain appliance shell access unless explicitly required.

Typical attack path

1. Identify an affected VMware vCenter Server or VMware Cloud Foundation deployment.
2. Obtain non-administrative access to the vCenter Server through valid credentials, prior compromise, exposed management access, or another vulnerability.
3. Enumerate readable files and permissions available to the low-privileged account.
4. Access sensitive files that are incorrectly readable due to improper permissions.
5. Extract credentials, tokens, certificates, configuration values, hostnames, or operational details from the exposed files.
6. Use the disclosed information to attempt privilege escalation, lateral movement, or further compromise of the vCenter and managed virtualization estate.

How to detect it

There is no single reliable network signature for exploitation because the issue is caused by local or authenticated access to improperly permissioned files. Focus detection on whether low-privileged users accessed files or data they should not have been able to read. Review vCenter Server appliance logs, authentication logs, shell access records, SSO logs, sudo history, command history where available, and endpoint telemetry for suspicious file reads by non-administrative accounts. Look for unusual use of commands such as cat, less, more, grep, find, tar, scp, curl, or python by low-privileged users against vCenter configuration, certificate, credential, or log directories. Correlate suspicious file access with subsequent failed or successful logins, new sessions from unusual sources, SSO token activity, role or permission changes, service account use from abnormal hosts, and access to ESXi hosts or vCenter APIs. Because KEV indicates exploitation in the wild, any unpatched affected deployment should receive retrospective hunting covering the period before patching, especially for accounts that had only non-administrative access but later showed expanded access or unusual activity.

What your security team should do

• Immediately inventory VMware vCenter Server and VMware Cloud Foundation deployments and identify versions affected by CVE-2022-22948.
• Prioritize patching because the vulnerability is in CISA KEV and has active exploitation in the wild; systems still unpatched after 2024-08-07 should be treated as overdue and high risk.
• Restrict vCenter management interfaces to trusted administrative networks and remove unnecessary exposure to broad internal or external networks.
• Review all non-administrative vCenter, SSO, appliance, and local accounts for necessity, excessive access, and signs of misuse.
• Rotate credentials, API tokens, service account passwords, and certificates that may have been present in files readable by lower-privileged users on affected systems.
• Hunt for evidence that low-privileged accounts accessed sensitive configuration, certificate, credential, or log files before patching.
• Increase monitoring of vCenter authentication events, privilege changes, SSO activity, appliance shell usage, and access to managed ESXi hosts following any suspected exposure.
• If suspicious access is found, treat the vCenter management plane as potentially compromised and perform incident response across connected ESXi hosts and dependent workloads.