Is CVE-2022-22948 (VMware vCenter Server Incorrect Default File Permissions Vulnerability) being exploited in the wild?

Yes. CISA added CVE-2022-22948 to its Known Exploited Vulnerabilities catalogue on 17 July 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. VMware vCenter Server contains an incorrect default file permissions vulnerability that allows a remote, privileged attacker to gain access to sensitive information.

What “exploited in the wild” means for CVE-2022-22948

For a KEV-listed CVE, the practical question is not whether the bug exists, but whether defenders should assume active abuse is already underway somewhere. That changes triage: exposure becomes a near-term operational problem, not a theoretical vulnerability management item. Use the vendor advisory and CISA KEV record to confirm current remediation guidance and organisational priority.

When you are validating exposure, start with whether any vCenter Server instance in your estate is in the affected product family and whether the vulnerable permissions pattern is present. If the system is internet-facing, administrative, or used to manage sensitive infrastructure, treat it as a high-value target even before you know whether exploitation touched your environment.

For practical prioritisation, pair the KEV listing with exploitation-likelihood signals and local asset criticality. The CISA Known Exploited Vulnerabilities Catalog tells you that active exploitation evidence exists, while the FIRST EPSS model can help rank what to address first when multiple issues compete for the same maintenance window.

What this vulnerability changes in practice

incorrect default file permissions are dangerous because they can expose sensitive information to a remote, privileged attacker without requiring a complicated exploit chain. In a platform like vCenter Server, that matters because the affected system often sits close to the control plane for virtual infrastructure, so information disclosure can become a springboard for broader compromise.

The main operational risk is not just leakage of a file or configuration artifact. Once an attacker can read sensitive material, they may learn how the environment is structured, where administrative trust boundaries sit, and what to target next. That makes even a disclosure-oriented flaw relevant to escalation, lateral movement, and incident scope expansion.

The NIST National Vulnerability Database and the CVE Program remain the best places to anchor the exact record, while the vendor advisory should be used for authoritative product applicability and fix details. For practitioners, the important point is to distinguish a disclosure issue from a harmless misconfiguration, because on a management platform the blast radius can be much larger than the individual file suggests.

How to respond if patching is delayed

If immediate remediation is not possible, reduce exposure first. Restrict access to vCenter Server to trusted administrative networks, remove unnecessary internet reachability, and verify that only the smallest necessary set of administrators can reach the management surface. Where compensating controls exist, favour network containment and monitoring over assuming the issue is low risk because it is “just” file permissions.

If you cannot patch at once, check whether sensitive files or directories are reachable from the vulnerable path, whether audit logs show unusual reads or access attempts, and whether related administrative accounts show unexpected activity. Because this CVE is tied to active exploitation evidence, you should also review whether any secrets, session material, or configuration data exposed by the vulnerability could have been reused elsewhere in the environment.

For teams that maintain broader vulnerability processes, the Vulnerability Management Guide is useful for aligning KEV-based prioritisation with remediation SLAs, while the Ultimate Guide to NHIs, Key Challenges and Risks is relevant wherever management-plane exposure could also affect service identities or other privileged non-human access paths.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed flaws require fast identification and remediation prioritization.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Incorrect default file permissions are a configuration weakness that should be hardened.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities on exposed assets first. Harden default permissions and verify secure configuration baselines.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Documented	The question depends on confirming whether the vulnerable vCenter asset is present and exposed.
Recommendation — Maintain an accurate asset inventory and map it to active vulnerability intelligence.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	A KEV-listed CVE needs monitored exposure, validation, and response.
	SI-2 — Flaw Remediation	Active exploitation makes prompt patching and mitigation the central control action.
Recommendation — Scan, validate, and track remediation for actively exploited vulnerabilities. Apply vendor fixes and compensating controls without delay.

Practitioner Guidance

What to verify: Confirm whether any vCenter Server instance is reachable from untrusted networks, whether the vulnerable file-permissions condition is present, and whether the system has been accessed unexpectedly since the KEV listing date.

Decision rule: If the asset is management-plane critical or broadly reachable, treat it as urgent even if no compromise indicators are obvious; if it is isolated and tightly controlled, you still need to patch, but the containment window may be narrower.

What to prioritise: Remediation order should follow exploit evidence first, then asset criticality, then exposure. A KEV-listed flaw on a control plane deserves earlier attention than a similar-severity issue on a low-value internal application.

Practitioner takeaway: KEV inclusion means you should assume exploitation is plausible now, so the right response is to verify exposure, contain access, patch quickly, and investigate for secondary abuse rather than waiting for local proof of compromise.