Port 427 – SLP (Service Location Protocol)

Port 427 is the default port for SLP (Service Location Protocol), defined in RFC 2608, which lets devices and applications automatically discover services on a network without being told their addresses in advance. A client sends a SrvRequest and the SLP agents answer with matching service URLs, so a printer, file share, or hypervisor can be found by type instead of by hardcoded IP. SLP listens on both UDP and TCP 427 — UDP for the multicast discovery traffic and TCP for larger unicast exchanges. The reference implementation is OpenSLP, and its most consequential deployment is VMware ESXi, which historically ran an OpenSLP-based CIM service on 427 — the reason this otherwise obscure port became the entry point for one of the largest hypervisor ransomware campaigns on record.

Why It’s Open

SLP was built into an era of zero-configuration enterprise networking, and it lingers wherever service auto-discovery was convenient: network printers and multifunction devices (Konica Minolta, Xerox), NAS boxes, IP-based management controllers (IBM IMM, SMC IPMI), some routers, and — most importantly for a pentester — VMware ESXi hosts. On ESXi, the SLP service on 427 let vCenter and CIM clients enumerate the hypervisor’s hardware and services. Where 427 answers, the ESXi management surface is usually one scan away on port 902 (the VMware ESXi console/management port) — related but not the same service, so treat them as two distinct findings. Because SLP predates any real authentication model and is often left on by default, it frequently ends up exposed on internal segments, and sometimes straight to the internet.

Common Risks

• Reflective amplification DDoS. SLP lets an unauthenticated caller register services and query them, so a tiny spoofed request can be answered with a massively larger reply — an amplification factor reported as high as ~2,200× (CVE-2023-29552). An open 427 becomes a DDoS reflector, the same class of abuse as SNMP on 161, NTP on 123, and SSDP on 1900.
• Remote code execution on VMware ESXi. The OpenSLP service embedded in ESXi has carried multiple critical heap-corruption and use-after-free RCE bugs (CVE-2019-5544, CVE-2020-3992, CVE-2021-21974). An attacker who reaches port 427 can take over the hypervisor — and every VM on it.
• Information disclosure. An SLP Directory Agent (DA) or User Agent will happily enumerate the internal services and hosts registered with it, handing an unauthenticated caller a map of what’s running on the network and where.
• Rogue service registration. Because registration is unauthenticated, an attacker can advertise malicious or bogus services — both to poison legitimate discovery and to inflate the reply size used for amplification.
• Legacy exposure by default. SLP is often enabled by firmware or an older OS build that nobody remembers turning on, so it sits open long after the feature that needed it is gone.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service and version

nmap -sU -sV -p 427 <target>       # UDP is the primary SLP transport
nmap -sT -sV -p 427 <target>       # SLP also answers on TCP 427

Enumerate services with the OpenSLP client (slptool)

slptool findsrvtypes                       # list advertised service types
slptool findsrvs service:service-agent     # find SLP agents
slptool findsrvs service:VMwareInfrastructure   # find ESXi/CIM services
slptool findattrs service:<service-url>    # dump a service's attributes

Discover agents on the local segment with nmap’s SLP library

# broadcast-novell-locate is the shipped NSE that speaks SLP (via the srvloc library)
nmap --script broadcast-novell-locate

Check an ESXi host’s SLP service directly

# On the ESXi host itself — is the SLP daemon running / firewalled open?
chkconfig --list | grep slpd
esxcli network firewall ruleset list | grep CIMSLP

Probe the amplification / reply size

# Send an SLP SrvRequest and measure how large the reply comes back (CVE-2023-29552)
python3 -c "import socket; s=socket.socket(socket.AF_INET,socket.SOCK_DGRAM); \
s.sendto(bytes.fromhex('0201000024000000000000000000000000000200656e000000000f736572766963653a736572766963652d6167656e74000000'), ('<target>',427)); \
print(len(s.recvfrom(9000)[0]),'bytes returned')"

There is no dedicated Metasploit SLP module and no dedicated SLP-vulnerability NSE in the shipped nmap distribution (verified against the rapid7/metasploit-framework and nmap script databases) — SLP enumeration is done with slptool, nmap -sV, and the srvloc library, and the ESXi RCEs are demonstrated with public GitHub proof-of-concepts rather than a curated Exploit-DB entry. Log every open 427 and every service you enumerate so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

• CVE-2021-21974 — A heap-overflow (CWE-787) in the OpenSLP service as used in VMware ESXi 6.5, 6.7, and 7.0. An unauthenticated attacker with access to port 427 can trigger the overflow and get remote code execution on the host. CVSS 8.8 (AV:A/AC:L/PR:N/UI:N). Patched in VMware’s February 2021 advisory — and the bug most widely blamed for the February 2023 “ESXiArgs” mass-ransomware campaign.
• CVE-2020-3992 — A use-after-free (CWE-416) in ESXi’s OpenSLP service. A malicious actor on the management network with access to port 427 can trigger it for remote code execution. CVSS 9.8 (AV:N/AC:L/PR:N/UI:N). Fixed October 2020.
• CVE-2019-5544 — A heap-overwrite (CWE-787) in OpenSLP as used in ESXi and the Horizon DaaS appliances (and in upstream OpenSLP ≤ 2.0.0, shipped by Red Hat and Fedora). An attacker with network access to port 427 can overwrite the OpenSLP heap and execute code remotely. CVSS 9.8 (AV:N/AC:L/PR:N/UI:N). (The old page listed this as “exploitable for DDoS attacks” — it is a heap-overwrite RCE, not a DoS.)
• CVE-2023-29552 — The “ServiceLocation” reflection/amplification flaw (Bitsight & Curesec). SLP lets an unauthenticated remote attacker register arbitrary services, inflating the size of the server’s reply; combined with a spoofed source address this yields a Denial-of-Service amplification factor of up to ~2,200×. CVSS 7.5 (AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:H — availability only). Listed in the CISA Known Exploited Vulnerabilities catalog. (The old page called this “remote code execution” — it is an amplification DoS, not RCE.)

Mitigation

• Disable SLP if nothing uses it — especially on ESXi. VMware’s own guidance is to stop and disable the SLP service on ESXi hosts that don’t need it: /etc/init.d/slpd stop, then esxcli network firewall ruleset set -r CIMSLP -e false and chkconfig slpd off. Newer ESXi releases ship with SLP disabled by default. On any other host, remove or disable the SLP/OpenSLP daemon if the discovery feature isn’t in use.
• Block UDP and TCP 427 at the perimeter. Port 427 should never be reachable from the internet. Firewall both transports and restrict SLP to a dedicated management VLAN where discovery is actually needed.
• Patch OpenSLP and ESXi. Bring hypervisors up to a build past the CVE-2019-5544 / CVE-2020-3992 / CVE-2021-21974 fixes, and update upstream OpenSLP packages on Linux hosts.
• Neutralize amplification at the edge. Anti-spoofing (BCP 38) and rate-limiting blunt the reflection abuse of CVE-2023-29552 — the same edge controls that protect NTP (123), SNMP (161), and SSDP (1900).
• Monitor for rogue registrations and queries. Alert on unexpected SLP service registrations and on 427 traffic crossing network boundaries.

Real-World Example

In early February 2023, a ransomware campaign dubbed ESXiArgs swept across internet-exposed VMware ESXi hosts, encrypting virtual machines at thousands of organizations within days — French hosting provider OVHcloud and CERT-FR raised the first alarms, and roughly 2,400 hosts were flagged as compromised over the first weekend. The initial-access vector was the OpenSLP service on port 427: most reporting and CERT-FR attributed it to CVE-2021-21974, an OpenSLP heap overflow that VMware had patched back in February 2021, meaning the victims were all running builds two years out of date with SLP still exposed. It’s worth being honest about the attribution — responders including Rapid7 and OVHcloud noted the exact vulnerability was never fully confirmed (older builds were hit too, so a different OpenSLP bug may have been involved in some cases). Either way the lesson is the same: an unpatched, internet-reachable SLP service on 427 was all it took, and VMware’s remediation advice led with the step a pentest would flag first — disable the SLP service you aren’t using.

FAQ

What is port 427 used for?

Port 427 is used by the Service Location Protocol (SLP), which lets clients discover network services — printers, file shares, hypervisors — by type instead of by hardcoded address. A client multicasts a SrvRequest and SLP agents reply with matching service URLs. SLP’s best-known deployment is the OpenSLP-based CIM service that VMware ESXi historically ran on this port.

Is port 427 TCP or UDP?

Both. SLP registers 427 on UDP and TCP. UDP 427 carries the multicast discovery traffic (and is what makes SLP usable for amplification attacks), while TCP 427 is used for larger unicast exchanges that don’t fit a single datagram. When you assess this port, scan both transports.

Is port 427 dangerous?

It can be. On VMware ESXi it has exposed critical remote-code-execution bugs (CVE-2019-5544, CVE-2020-3992, CVE-2021-21974) that let an attacker take over the hypervisor, and the protocol itself is abusable as a ~2,200× DDoS amplifier (CVE-2023-29552). An internet-facing port 427 should be treated as an active exposure; behind a management VLAN with a patched daemon the risk drops sharply.

What is the SLP service on VMware ESXi?

It’s an OpenSLP-based service that let CIM clients and vCenter discover the ESXi host’s hardware and services on port 427. Because of the OpenSLP RCE chain and the 2023 ESXiArgs ransomware, VMware now recommends disabling it, and current ESXi builds ship with it off. Don’t confuse it with the ESXi management/console service on port 902 — that’s a separate port and service.

How do I secure or close port 427?

Disable SLP if you don’t use it — on ESXi, stop and disable the slpd service and its CIMSLP firewall rule; on other hosts, remove the OpenSLP daemon. If you do need it, patch OpenSLP/ESXi to a fixed build, firewall UDP and TCP 427 so it’s never internet-facing, and restrict it to a management VLAN. Rescan afterward to confirm 427 no longer answers.

TL;DR

• Service: SLP (Service Location Protocol, RFC 2608) — automatic service discovery; reference daemon OpenSLP, famously used by VMware ESXi
• Default port: 427/UDP and 427/TCP
• Biggest risk: OpenSLP RCE on ESXi (CVE-2019-5544 / 2020-3992 / 2021-21974 — the ESXiArgs precondition) and ~2,200× reflective DDoS amplification (CVE-2023-29552)
• Mitigation: disable SLP if unused (especially on ESXi), patch OpenSLP/ESXi, and firewall UDP+TCP 427 off the internet