CVE-2019-5544: VMware ESXi and Horizon DaaS OpenSLP Heap-Based Buffer Overflow Vulnerability

CVE-2019-5544 is a heap-based buffer overflow in the OpenSLP service used by VMware ESXi and Horizon Desktop as a Service (DaaS). An attacker who can reach the service on the network can overwrite heap memory and achieve remote code execution. This matters because ESXi hosts are foundational to many virtualization environments; successful exploitation can give an attacker a foothold on the hypervisor layer. The vulnerability has been used by ransomware operators, so unpatched systems remain a high-priority risk.

Defenders should treat any internet- or broadly network-reachable OpenSLP endpoint on these products as exposed until they confirm the vendor fix is applied. Specifics of affected builds and exact patch identifiers must be confirmed against the vendor advisory.

How it works

The weakness is classified as CWE-787 (out-of-bounds write). OpenSLP implements the Service Location Protocol and listens for network requests. The flaw allows a crafted request to overflow a heap buffer inside the OpenSLP process. By controlling what is written past the intended buffer bounds, an attacker can corrupt heap metadata or adjacent objects and divert execution flow to attacker-controlled code.

According to the CISA summary, the attacker needs network access to port 427—the port commonly associated with SLP. No authentication requirement is described in the provided facts, so the attack surface is the reachable OpenSLP service itself. Exact packet structure, heap layout details, and exploit reliability vary by build and configuration; those mechanics are not specified here and must be taken from the vendor advisory rather than assumed.

Am I affected? How to find it in your systems

VMware ESXi is typically deployed as the bare-metal hypervisor in on-premises and private-cloud clusters. Horizon DaaS appears in desktop-as-a-service deployments that rely on the same OpenSLP component. Inventory every ESXi host and Horizon DaaS instance, including nested or lab systems that may still be reachable.

• Enumerate hosts via vCenter, standalone host lists, configuration-management databases, or network discovery that identifies ESXi management interfaces.
• Confirm whether the OpenSLP service is present and listening on port 427 (TCP/UDP). Check host firewall rules and service status on each system.
• Compare installed build or patch levels against the fixed versions listed in the VMware advisory for CVE-2019-5544; do not rely on version guesses.
• Review network flow or firewall logs for unexpected inbound traffic to port 427 from untrusted segments. Sudden OpenSLP process crashes, restarts, or anomalous child processes on the hypervisor can be secondary indicators, though they are not definitive proof of exploitation.

If OpenSLP has already been disabled or removed per prior hardening guidance, verify that the service is truly absent and that no residual listener remains.

How to remediate

Patch first. Apply the updates VMware released for ESXi and Horizon DaaS exactly as described in the vendor advisory. CISA’s required action is to apply updates per vendor instructions; follow that sequence and validate that the OpenSLP component is at a fixed level afterward.

• Schedule maintenance windows for hypervisor hosts; use rolling cluster updates where supported so workloads remain available.
• After patching, re-check that port 427 is either no longer exposed or is bound only to the updated, non-vulnerable service.
• For this class of flaw, also reduce the attack surface: disable OpenSLP if the environment does not require Service Location Protocol, restrict management interfaces to dedicated networks, and enforce host firewall rules that deny unsolicited SLP traffic.
• Document the before-and-after configuration and retain evidence of patch installation for audit and incident-response purposes.

If you can't patch immediately

Until the vendor update can be installed, apply compensating controls that limit reachability and increase detection.

• Segment ESXi and Horizon DaaS management interfaces onto isolated networks; block port 427 at network firewalls and host-based firewalls from all untrusted sources.
• Disable the OpenSLP service entirely if business functions do not depend on it—confirm the correct disable procedure in VMware documentation so you do not break required discovery features.
• If a web application firewall or virtual-patching capability sits in front of the affected interfaces, enable any vendor-supplied or custom rules that drop malformed SLP traffic; treat this only as a temporary bridge.
• Heighten monitoring: alert on any connection attempts to port 427, on OpenSLP process anomalies, and on unusual hypervisor process creation. Retain relevant logs for later forensic review.
• Prioritize internet-facing or partner-reachable hosts for emergency change windows; internal-only systems still need a firm patch date.

If your data may have been exposed

Actively exploited vulnerabilities, including those known to be used by ransomware, frequently precede broader compromise and data theft. If you have evidence of exploitation or cannot rule it out, follow your incident-response plan: isolate affected hosts, preserve memory and disk images where feasible, rotate credentials that may have been accessible from the hypervisor, and assess guest workloads for secondary intrusion. You can also run a free exposure scan of your email addresses to check whether associated accounts appear in known breach datasets, which may help prioritize further credential hygiene.