CVE-2023-29552: Service Location Protocol (SLP) Denial-of-Service Vulnerability

CVE-2023-29552 is a denial-of-service vulnerability in the IETF Service Location Protocol (SLP). An unauthenticated remote attacker can register services and abuse spoofed UDP traffic to generate a DoS attack with a significant amplification factor. This matters because SLP is often enabled by default on systems that perform service discovery, and exposure of the protocol on untrusted networks can turn ordinary hosts into amplifiers that disrupt availability for others or for the target itself.

Defenders should treat any internet-facing or untrusted-network instance of SLP as high priority until the service is disabled or the vendor-recommended mitigations are confirmed in place.

How it works

The vulnerability class is a denial-of-service condition that arises from the way SLP handles service registration and UDP-based traffic. According to the public description, an unauthenticated remote attacker can register services and then use spoofed UDP packets to produce amplified traffic directed at a victim. Because the protocol relies on UDP and does not require authentication for these operations, the attacker can generate a large volume of responses relative to the size of the original request. Exact packet formats, amplification ratios, and implementation-specific triggers are not detailed here; teams must consult the relevant vendor advisory for the precise mechanics that apply to their products.

In practical terms, the attack does not require prior access or credentials. Any system that accepts SLP traffic on the network can be leveraged, making open port 427/UDP a primary risk indicator.

Am I affected? How to find it in your systems

SLP is used for service discovery and may be present on servers, workstations, network appliances, or embedded devices that advertise or locate network services. It commonly listens on UDP port 427. Inventory efforts should therefore focus on identifying hosts that have the SLP service running or that accept traffic on that port.

• Scan internal and external networks for open UDP/427 and for processes or services named SLP or related to service location.
• Check host configurations and package inventories for SLP-related components; confirm exact product versions and patch levels against the vendor advisory, because no specific version ranges are provided in the public summary.
• Review firewall and network-device logs for unexpected UDP/427 traffic, especially large volumes of responses or registrations originating from untrusted sources.
• On systems that support it, examine SLP service logs or system event logs for anomalous registration activity.

If SLP is not required for business functions, treat its presence on any untrusted network interface as an exposure that needs immediate attention.

How to remediate

The primary remediation path is to follow the vendor’s instructions for the affected product. Where a software update is available, apply it promptly and verify that the SLP service no longer exhibits the vulnerable behavior. The CISA-required action states that organizations should apply mitigations per vendor instructions or disable the SLP service or port 427/UDP on all systems running on untrusted networks, including those directly connected to the Internet.

• Disable the SLP service entirely if it is not needed.
• Block or filter UDP/427 at network boundaries and host firewalls for any system that must remain reachable from untrusted networks.
• Confirm that any remaining SLP instances are restricted to trusted internal segments only.

After changes, re-scan to ensure the port is closed and the service is no longer listening where it should not be.

If you can't patch immediately

When an immediate vendor update or full disable is not feasible, apply compensating controls that reduce the attack surface and limit amplification potential.

• Segment systems that still require SLP so they cannot be reached from the Internet or other untrusted networks.
• Implement network-level filtering or virtual patching that drops unsolicited SLP registration and response traffic, especially spoofed UDP packets destined for port 427.
• Disable the SLP feature or service on every host where it is not operationally required.
• Increase monitoring for UDP/427 traffic volume, unexpected source addresses, and spikes that could indicate amplification activity; alert on anomalies and be prepared to isolate affected hosts.

These measures buy time but do not replace the need to apply the permanent vendor mitigation or to remove the service from untrusted exposure.

If your data may have been exposed

This vulnerability is a denial-of-service issue; the public description does not document ransomware use or direct data exfiltration. Nevertheless, any actively exploited vulnerability can be a foothold for broader compromise. If systems running SLP were internet-facing or otherwise exposed, review logs for signs of abuse and treat the incident as a potential availability and lateral-movement risk. Organizations can also run a free exposure scan of their email addresses against known breach data sets to determine whether credentials or other information associated with their domain have appeared in prior incidents.