VMware vCenter Syslog directory traversal enables arbitrary code execution

VMware vCenter contains a directory traversal vulnerability in the Syslog server. A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.

• VMware Cloud Foundation: branches 9.1.x.x, 9.0.x.x, and 5.x are affected. For branch 5.x, Broadcom directs administrators to apply an asynchronous patch to 8.0 U3k.
• VMware vSphere Foundation: branches 9.1.x.x and 9.0.x.x are affected.
• VMware vCenter: branch 9.1.x.x is affected below 9.1.0.0300; branch 9.0.x.x is affected below 9.0.2.0100; branch 8.0 is affected below 8.0 U3k. Broadcom also lists 8.0 U2f as the fixed release for the corresponding deployment branch and provides guidance for branch 7.0 through Broadcom Support when an extended support contract is available.
• VMware Telco Cloud Infrastructure: version 3.0 is affected; the remediation guidance is KB449886.
• VMware Telco Cloud Platform: branches 5.1.x, 5.0.x, 4.x, and 3.0 are affected; the remediation guidance is KB449886.
• Broadcom does not provide a workaround for this vulnerability.

VMware vCenter has a CWE-22 flaw in which the Syslog server does not properly restrict pathname handling to an approved directory. A network-reachable attacker does not need prior privileges or user interaction, and Broadcom states that exploitation may result in arbitrary code execution. Evidence from an investigated campaign indicates that attacker-controlled path content was processed through Syslog handling to place files in cron-controlled locations, after which code ran in a root context. This is observed campaign behavior, not a complete vendor description of the vulnerable implementation. The vendor has not disclosed the exact path-validation defect, request format, or exploit payload.

• The vulnerability is remotely reachable through network access to vCenter.
• The record states that no prior privileges or user interaction are required and that exploitation complexity is low.
• The record marks the vulnerability as known exploited and as having a public exploit.
• A third-party investigation reported active exploitation of Internet-accessible vCenter systems, identifying 361 victim IP addresses across 47 countries. The investigation also reported reverse_ssh being used for post-compromise persistence.
• No complete exploit procedure or public payload has been confirmed in the vendor source.

The flaw may allow a remote attacker to execute arbitrary code on VMware vCenter without prior authentication or user interaction. Technical consequences may include compromise of the appliance, unauthorized access to or modification of data, and disruption of management services. In one reported investigation, code executed in a root context and was followed by persistence and administrator-account creation, showing that the risk can extend beyond a single Syslog operation. Actual impact depends on the privileges available through the appliance, connectivity to systems managed by vCenter, and the organization's network segmentation.

Successful exploitation may compromise the confidentiality, integrity, and availability of the vCenter appliance. Because vCenter is a centralized management plane, compromise could allow an attacker to alter configuration, establish persistence, or disrupt administration of virtual infrastructure. One investigated intrusion included administrator-account creation, persistence, and activity directed toward ESXi hosts after initial access, but that evidence describes a specific campaign rather than an outcome required in every deployment. The record does not establish that every affected system has been compromised.

1. Identify the applicable product branch and apply the corresponding fix: 9.1.0.0300 for vCenter 9.1.x.x, 9.0.2.0100 for vCenter 9.0.x.x, or the applicable 8.0 branch fix, 8.0 U3k or 8.0 U2f, listed in Broadcom's response matrix.
2. For VMware Cloud Foundation 5.x, apply the asynchronous patch to 8.0 U3k according to Broadcom's guidance. For VMware Telco Cloud Platform and VMware Telco Cloud Infrastructure, follow KB449886.
3. For vCenter 7.0, contact Broadcom Support if the organization has an extended support contract; do not infer an exact fixed release that the advisory does not specify.
4. Broadcom provides no workaround. Until patching is complete, restricting network access to vCenter may reduce reachability, but this is not a vendor-confirmed fix.
5. If exploitation is suspected, follow incident-response procedures, preserve relevant logs and artifacts, and review administrator accounts, scheduled tasks, persistence services, and unusual outbound connections before declaring the system clean.

1. Inventory all vCenter, VMware Cloud Foundation, VMware vSphere Foundation, and Telco Cloud deployments, then compare each installation with the affected branches.
2. Review Syslog and filesystem data for malformed path content, path traversal patterns, or unexpected content written to privileged locations such as /etc/cron.d.
3. Review cron and crond logs and scheduled-file names for reported indicators such as zz-poc59310-syslog.log, zz-poc59310, vmware-vpxd-stats-*, vmware-perf-collect-*, and vmware-perf-sync-*.
4. Check for unexpected files, processes, and services including linuxFile, systemlog, linux_x86, sys-9436d8.service, vmware-perf-update.jsp, and unexpected sudoers changes involving perfcharts.
5. Audit the creation of new vSphere or LDAP administrator accounts, unusual outbound connections, and user agents such as GoodMoodle-VCProbe/1.0 or GoodMoodle-VCFleet/1.0 where those fields are logged.
6. A reverse_ssh detection can be used as an investigation lead, but the tool is dual-use and should be correlated with unauthorized installation, execution on a vCenter appliance, and unexpected outbound connections. The absence of these indicators does not prove that the system was not compromised.