CVE-2023-29552

What it actually does

The flaw is a network-accessible denial-of-service condition in the Service Location Protocol (SLP). Because SLP permits unauthenticated remote service registration over UDP, an attacker can send crafted SLP traffic using a spoofed source IP address and cause exposed SLP services to send much larger responses to a third-party victim. This creates a UDP reflection/amplification vector: vulnerable systems may be abused as amplifiers, while targets of the reflected traffic may experience bandwidth exhaustion, packet loss, service instability, or outage. The issue requires no authentication, no user interaction, and is exploitable remotely wherever SLP is reachable, commonly on UDP port 427.

Why it matters to the business

Organizations exposing SLP to untrusted networks risk having infrastructure abused in distributed denial-of-service attacks or becoming the direct victim of amplified traffic. Business consequences can include service outages, degraded virtualization or management-plane availability, upstream ISP rate limiting, incident response costs, reputational impact, and potential abuse complaints. This vulnerability is listed in CISA KEV with a remediation deadline of 2023-11-29, has active exploitation in the wild, and has a high EPSS score, so internet-exposed instances should be treated as urgent even if they are not business-critical services themselves.

How an attack unfolds

An attacker first identifies systems exposing SLP, typically by scanning for UDP port 427. They then send unauthenticated SLP service registration or query traffic designed to cause a large response. By spoofing the packet source address as the intended victim, the vulnerable SLP service sends amplified UDP responses to that victim instead of the attacker. At scale, the attacker repeats this across many exposed SLP servers, turning them into reflectors in a distributed denial-of-service campaign. The abused SLP hosts may not be compromised in the traditional sense, but they can generate high outbound traffic and may be reported as participating in attacks. If the organization is the target rather than the reflector, network links and exposed services may be overwhelmed by large volumes of inbound UDP/427-related reflected traffic.

How to fix it

Disable SLP wherever it is not explicitly required. If SLP is required, restrict it to trusted management networks only and block exposure to the internet. Filter UDP and TCP port 427 at network boundaries, host firewalls, hypervisor management interfaces, and cloud/security-group controls. Apply vendor-provided updates or hardening guidance for affected products, including VMware ESXi, SUSE Linux Enterprise Server, SUSE Manager Server, NetApp SMI-S Provider, and OpenSLP/service-location-protocol implementations. For VMware ESXi environments, follow VMware guidance to disable or restrict the SLP service where applicable. For Linux systems using OpenSLP/slpd, stop and disable the SLP daemon if not needed and ensure packages are updated from the vendor-supported repository. Where disabling is not possible, use ACLs, rate limiting, anti-spoofing controls such as BCP38/uRPF, and DDoS protection to reduce abuse potential. Because this vulnerability is in CISA KEV and actively exploited, prioritize remediation of any externally reachable SLP service immediately.

How to confirm the fix worked

Confirm that SLP is not reachable from untrusted networks by scanning for UDP/TCP port 427 from an external vantage point. Validate host-level state by checking whether SLP services such as slpd, OpenSLP, or vendor-specific SLP daemons are stopped, disabled, or bound only to trusted interfaces. Review firewall, router, security group, and hypervisor management network rules to ensure UDP/TCP 427 is blocked from the internet. Where vendor patches or configuration changes were applied, verify installed package or product versions against current vendor advisories. Use packet captures or flow records to confirm there is no unexpected inbound or outbound UDP/427 traffic after remediation. For environments where SLP must remain enabled, test that only approved source networks can query or register services and that rate limiting is active.

Typical attack path

1. Scan the internet or target address ranges for systems responding on UDP port 427/SLC Service Location Protocol.
2. Identify SLP implementations that allow unauthenticated service registration or produce large UDP responses.
3. Craft SLP packets that trigger amplified responses.
4. Spoof the source IP address of the intended denial-of-service victim.
5. Send traffic to many vulnerable SLP servers, causing them to reflect amplified responses toward the victim.
6. Sustain or vary the traffic volume to exhaust bandwidth, degrade service availability, or trigger upstream filtering.

How to detect it

To determine whether exploitation has already occurred, review network telemetry rather than relying only on host logs, because SLP reflection attacks often leave minimal application-level evidence. Examine firewall logs, router ACL logs, NetFlow/IPFIX, IDS/IPS events, packet captures, and DDoS-provider alerts for unusual UDP/427 traffic, especially high outbound packet counts from SLP-enabled systems to unfamiliar external IP addresses or high inbound UDP/427 traffic from many sources. Look for asymmetric patterns where small inbound SLP requests are followed by much larger outbound responses, repeated SLP service registration/query activity, or traffic bursts consistent with reflection/amplification. On Linux/OpenSLP systems, review syslog/journal logs for slpd activity, unexpected service registrations, daemon restarts, or errors around the same time as network spikes. On virtualization or appliance platforms, review management-plane logs and vendor service logs for SLP activity if available. Indicators that a host was abused as a reflector include large outbound UDP/427 flows to a single external destination, abuse complaints naming the host as a DDoS participant, and perimeter logs showing repeated SLP requests from spoofed or unusual source networks. Indicators that an organization was the victim include large inbound UDP traffic with source port 427 from many unrelated external systems and concurrent service degradation or link saturation.

• UDP/427
• TCP/427
• port 427
• slpd
• openslp
• OpenSLP
• service:service-agent
• service:directory-agent
• service:service-location
• SrvRqst
• SrvRply
• SrvReg
• SrvAck
• DAAdvert
• SAAdvert
• systemctl status slpd
• journalctl -u slpd
• /var/log/slpd.log
• /var/log/messages
• /var/log/syslog
• /etc/slp.conf
• /etc/slp.reg
• /etc/slp.spi

What your security team should do

• Immediately inventory all assets exposing UDP or TCP port 427, prioritizing internet-facing systems and virtualization or storage management interfaces.
• Disable SLP on all systems where it is not required; if required, restrict access to trusted management networks only.
• Apply relevant vendor patches and hardening guidance for VMware ESXi, SUSE, NetApp SMI-S Provider, and OpenSLP-based deployments.
• Block UDP/TCP 427 at internet perimeters and enforce anti-spoofing controls to prevent infrastructure from being used as a DDoS reflector.
• Review NetFlow, firewall, IDS, and packet-capture data for spikes in UDP/427 traffic indicating prior abuse as a reflector or victim.
• Create SIEM detections for unexpected inbound or outbound SLP traffic, especially high-volume responses to external destinations.
• Coordinate with network providers or DDoS mitigation vendors if large reflected traffic volumes are observed.
• Treat any externally exposed instance as overdue for remediation because the KEV due date has passed and exploitation is active in the wild.