CVE-2023-34048

What it actually does

This is a remotely reachable memory-corruption flaw in VMware vCenter Server’s DCERPC protocol implementation. An unauthenticated attacker with network access to the vulnerable service can send crafted DCERPC traffic that triggers an out-of-bounds write, potentially allowing arbitrary code execution in the context of the affected vCenter service. Because vCenter is a privileged management plane for ESXi hosts and virtual machines, successful exploitation can lead to full compromise of virtualization administration capabilities, credential theft, VM manipulation, and service disruption.

Why it matters to the business

Compromise of vCenter can give an attacker control over core virtualization operations, including access to virtual machines, snapshots, host configuration, and administrative credentials. This can result in outage of business-critical workloads, theft or tampering of sensitive systems, rapid lateral movement across the data center, and loss of confidence in backup and recovery processes. The vulnerability is high urgency: it has a CVSS score of 9.8, EPSS is extremely high at 0.99428, it is listed in CISA KEV, and exploitation has been observed in the wild; the CISA remediation due date was 2024-02-12.

How an attack unfolds

An attacker first identifies a reachable VMware vCenter Server instance and confirms that the DCERPC interface is accessible from their network position. They then send malformed DCERPC requests designed to corrupt memory through the out-of-bounds write condition. If exploitation succeeds, the attacker obtains code execution on the vCenter appliance without needing valid credentials or user interaction. From there, they typically attempt to establish persistence, enumerate vCenter inventory, extract credentials or tokens, create or abuse administrator-level accounts, access ESXi hosts, manipulate virtual machines, and use the virtualization layer as a platform for further intrusion. Public reporting and KEV status indicate real-world exploitation, so suspicious crashes or abnormal management-plane activity around vCenter should be treated as potentially serious.

How to fix it

Upgrade VMware vCenter Server to a vendor-fixed release immediately. The input did not provide exact fixed package versions, so use the latest VMware security advisory and supported release notes for CVE-2023-34048 to identify the correct fixed build for each deployed branch; commonly referenced fixed vCenter releases include 8.0 U2, 8.0 U1d, 7.0 U3o, or later applicable builds. Apply any corresponding VMware Cloud Foundation asynchronous patches where relevant. If immediate patching is not possible, restrict vCenter access to a small set of trusted administrative networks, block untrusted access to management and DCERPC-related services, enforce firewall segmentation around vCenter and ESXi management networks, disable unnecessary external exposure, and increase monitoring for crashes, unexpected service restarts, account changes, and anomalous vCenter API activity. Mitigations should be treated as temporary because this is unauthenticated remote code execution with known exploitation.

How to confirm the fix worked

Confirm remediation by checking the vCenter Server version and build against VMware’s fixed-version matrix for the deployed branch. Perform authenticated vulnerability scanning or configuration assessment to verify the vulnerable build is no longer present. Confirm that vCenter management interfaces and DCERPC-related services are not reachable from untrusted networks. Review firewall rules, load balancer configuration, and network ACLs to ensure only approved administrative sources can connect. After patching, restart and health-check vCenter services, validate successful login and inventory operations, and review appliance logs for continuing service crashes or suspicious access attempts. If compromise is suspected, do not rely solely on patch validation; perform forensic review of the vCenter appliance, SSO configuration, administrator accounts, certificates, ESXi trust relationships, and recent privileged actions.

Typical attack path

1. Scan for VMware vCenter Server instances reachable over the network.
2. Probe for exposed vCenter management and DCERPC-related services.
3. Send crafted DCERPC traffic that triggers the out-of-bounds write condition.
4. Achieve remote code execution in the context of the vulnerable vCenter service.
5. Run commands or deploy tooling on the vCenter appliance.
6. Enumerate vCenter users, sessions, ESXi hosts, clusters, datastores, and virtual machines.
7. Steal credentials, session material, or certificates useful for virtualization-plane access.
8. Create persistence through accounts, services, scheduled jobs, plugins, or appliance-level modifications.
9. Use vCenter privileges to access ESXi hosts and manipulate virtual machines, snapshots, or backups.
10. Move laterally from the virtualization management layer into guest workloads or supporting infrastructure.

How to detect it

Investigate whether vCenter was already exploited by combining network, appliance, identity, and virtualization-management telemetry. Review firewall, IDS, NetFlow, and packet-capture data for unexpected DCERPC/RPC-style traffic to vCenter from non-administrative sources, especially before patching. Inspect vCenter appliance logs for crashes, segmentation faults, service restarts, and core dumps involving vCenter directory or RPC-related services. Review vCenter SSO and administrative audit logs for new users, new group memberships, role changes, unexpected logins, token issuance anomalies, or changes to permissions. Examine vCenter task and event history for unusual VM power operations, snapshot creation or deletion, datastore browsing, host reconfiguration, certificate changes, plugin installation, or ESXi host access outside normal maintenance windows. On the appliance, look for unexpected shell history, new cron jobs, modified systemd services, unfamiliar binaries in temporary directories, web-accessible files, reverse-shell tooling, or outbound connections to unusual destinations. Because public exploitation has been reported and the vulnerability may result in arbitrary code execution rather than a consistent web artifact, absence of a single IOC does not rule out compromise; prioritize behavioral evidence around service instability followed by privileged management-plane activity.

• /var/log/vmware/vmdird/vmdird-syslog.log
• /var/log/vmware/vmon/vmon.log
• /var/log/vmware/vpxd/vpxd.log
• /var/log/vmware/sso/vmware-sts-idmd.log
• /var/log/vmware/sso/vmware-sts-idmd-access.log
• /var/core/core.vmdird
• /storage/core/core.vmdird
• core.vmdird
• segmentation fault
• Segmentation fault
• core dumped
• vmdird
• DCERPC
• DCE/RPC
• ncacn_ip_tcp

What your security team should do

• Treat this as an emergency remediation item because it is unauthenticated network RCE, KEV-listed, and has extremely high EPSS probability.
• Prioritize patching all externally reachable or broadly reachable vCenter Server instances first, then all remaining internal vCenter deployments.
• Verify every vCenter instance is on a fixed VMware build; include disaster recovery, lab, staging, and legacy management systems.
• Restrict vCenter management access to dedicated administrative networks and require VPN, bastion, or privileged access controls.
• Search historical telemetry for vCenter service crashes, core dumps, anomalous DCERPC traffic, unexpected SSO account changes, and unusual vCenter API operations.
• Review vCenter local OS accounts, SSO administrator groups, roles, permissions, certificates, scheduled tasks, plugins, and service definitions for persistence.
• Audit ESXi hosts managed by affected vCenter instances for new users, altered lockdown mode, modified firewall settings, suspicious VIBs, and unexpected VM operations.
• Rotate credentials and secrets that may have been exposed through vCenter if exploitation or suspicious post-exploitation behavior is identified.
• Preserve relevant logs and appliance snapshots before destructive remediation if incident response is required.
• Use CISA KEV status and the missed 2024-02-12 due date as justification for executive-level prioritization and exception tracking.