When you plug an unmanaged laptop into an open network jack, Cisco Discovery Protocol (CDP) helps determine what it is connected to. It doesn’t require a login, credentials, or even a handshake.
CDP attacks take advantage of this. Because CDP multicasts, or advertisements, are not authenticated, attackers use those to build a target list, and sometimes they hijack the devices sending the multicast traffic.
In this article, we’ll break down what information gets leaked during CDP attacks, how bad actors exploit and use that data, and what mitigations exist to prevent these attacks from happening in the first place.
What Is a CDP Attack?
A CDP attack is a technique that abuses the behaviors of Cisco Discovery Protocol. Cisco introduced this data link protocol in 1994 to allow connected Cisco equipment to automatically identify one another and configure themselves to communicate.
When clients (or devices) send advertisements over the network via CDP, attackers take advantage of the unauthenticated frames by doing one (or both) of the following:
- Reconnaissance: Passively collect information to create target lists
- Spoofing or denial of service (DoS): Actively send forged CDP frames to a device
CDP was designed for use on trusted, wired enterprise networks. Every device on the network is supposed to be legitimate, so the protocol doesn’t involve authentication or encryption. Because of this, anything that connects to that segment of the network can potentially send and receive CDP frames.
Info: Cisco Discovery Protocol is not a vulnerability on its own; it is doing what it was designed to do. The risks come in when an unauthenticated device that was never supposed to be there enters the network.
How Cisco Discovery Protocol Works
Cisco devices with CDP enabled periodically send CDP frames. These go out as multicast traffic to a reserved MAC address (01:00:0c:cc:cc:cc), and every CDP-enabled device can read and store the packets.
By default, these packets go out every 60 seconds and will discard a neighbor’s entry if they are silent for 180 seconds.
Every advertisement contains type-length-value (TLV) fields. Those fields can carry information such as:
- Device’s hostname
- Cisco Internetwork Operating System (IOS) version
- Hardware platform
- IP address
- Which port it is speaking on
- Duplex setting
- Trunk’s native virtual local area network (VLAN)
Devices don’t have to request this information. Because the advertisement is recurring, any device on the wire will receive the information, whether it’s legitimate or not.
Note: In isolation, any one of these data points may appear harmless. But together they start to paint a picture of an organization’s device inventory.
CDP Reconnaissance: Mapping the Attack Surface
CDP reconnaissance is a Layer 2 attack that assumes a trusted wire, like ARP spoofing and CAM table overflows. It allows attackers to start mapping the attack surface. During this passive phase of a CDP attack, the attacker simply listens.
Reconnaissance typically plays out like this:
- Connect and listen: An attacker plugs an unauthenticated device into an open port to silently capture CDP frames.
- Catalog neighboring devices: While connected, the attacker can gather data (like the TLV fields list above) on the neighboring devices, allowing them to catalog the network segment.
- Match models to firmware: Once the attacker has the software version for each device, they can identify specific vulnerabilities that affect that specific platform and release.
- Read the native VLAN: CDP can reveal the native VLAN, giving an attacker additional information about network segmentation that may help assess techniques such as VLAN hopping.
- Choose an exploit or pivot: All of this information gives the attacker a map to choose where they want to attack. Instead of guessing, they can choose a specific point within the network to exploit.
CDP spoofing and CDP-based DoS may be better known among CDP attacks, but it’s this reconnaissance that makes those attacks efficient.
See your security gap before attackers do.
See continuous trust in action on a platform that includes RADIUS, PKI and AI security.
Reconnaissance, Spoofing, and Denial of Service: Three Distinct CDP Risks
Each CDP risk works a little differently, so mitigation should be handled differently at each phase. The table below explains the differences between each CDP attack type:
| Attack Type | What the Attacker Does | Requires Sending Forged Frames? |
| CDP reconnaissance | Passively captures legitimate CDP multicasts to map devices, firmware, and VLANs | No |
| CDP spoofing | Sends forged CDP announcements to trick a neighbor into false topology or device data | Yes |
| CDP denial of service | Sends malformed or oversized CDP packets to crash a vulnerable parser | Yes |
Info: Reconnaissance doesn’t compromise a device by itself. But it does tell attackers where to aim, so organizations should handle mitigation separately from spoofing or DoS.
Known CDP Vulnerabilities: The CDPwn Case Study
Unauthenticated multicasts within CDP are a design tradeoff, but the way the protocol functions has also resulted in exploitable bugs.
In February 2020, researchers disclosed the following:
- Five vulnerabilities in CDP parsing implementations
- Four remote code execution flaws
- One denial-of-service flaw
These security concerns span the Cisco NX-OS, IOS XR, and FXOS operating system families, also impacting IP phone and IP camera firmware. Exposure was estimated to have impacted tens of millions of devices.
This set of vulnerabilities became known as CDPwn. It is tracked across the following CVEs:
- CVE-2020-3110
- CVE-2020-3111
- CVE-2020-3118
- CVE-2020-3119
- CVE-2020-3120
Note: CDPwn is important to understand when it comes to CDP attacks, because attackers who have done CDP reconnaissance can match a device’s model and software version to unpatched CVEs. This is where reconnaissance connects to targeting known vulnerabilities.
Blanket CDP Disabling or Per-Interface Control?
The standard advice in security-focused guidance is to disable CDP outright. However, not everyone agrees. A Packet Pushers analysis argues that CDP can provide useful network discovery, troubleshooting, and auto-configuration benefits when selectively enabled on trusted infrastructure links.
A practical approach is to disable CDP on untrusted or exposed interfaces and keep it enabled where operational benefits could outweigh disclosure risks. Here’s the middle ground many teams land on:
- Edge and access ports: Disable CDP on interfaces that connect to end-user devices, guest connections, or other unmanaged equipment.
- Trusted infrastructure links: Consider keeping CDP enabled between managed network devices and known Cisco endpoints where it provides operational value.
- Global disable as a last resort: Use “no cdp run” to turn CDP off everywhere when the network has no operational need for CDP and eliminating the protocol entirely is preferable.
Using an approach like this treats CDP as one part of a broader security strategy rather than assuming that disabling it alone provides network security.
Is LLDP a Safer Alternative to CDP?
Link Layer Discovery Protocol (LLDP), standardized as IEEE 802.1AB, is a vendor-neutral discovery protocol that serves a similar purpose to CDP across Cisco and non-Cisco equipment. Like CDP, it can advertise device, interface, and capabilities information without authenticating the receiving device.
While it may be tempting to switch from CDP to LLDP, this doesn’t fix the problem.
Devices that are listening for LLDP frames can gather the same inventory of data on your network segment that a CDP attacker could gather. Disabling CDP and moving to LLDP only moves the problem to a different protocol; it doesn’t solve it.
From CDP Disclosure to Denying Unauthenticated Access
It’s important to reduce what CDP can disclose, but doing this only treats a symptom of the problem. The real gap is that under this protocol alone, unauthenticated devices can plug into ports and potentially receive Layer 2 traffic, including CDP advertisements.
Port-based network access control (PNAC) addresses the broader access problem by authenticating devices and users before allowing normal network access. 802.1X provides the standard framework for this authentication, allowing a switch to verify a device or user before granting access to the network.
Warning: 802.1X does not necessarily prevent CDP traffic from being exchanged before authentication. Disabling CDP on untrusted interfaces is still important when the goal is to prevent CDP information from being disclosed to unauthenticated devices.
802.1X adds a separate layer of protection by preventing an unauthorized device from gaining normal network access after the authentication process.
Moving to certificate-based authentication, backed by a secure public key infrastructure (PKI), provides a stronger way to authenticate devices and users without relying on shared passwords or static credentials. Together, CDP controls and authenticated network access reduce both the information available to an attacker and the network access they can gain from an unauthorized device.
Reduce Your CDP Attack Surface With JoinNow Cloud RADIUS and JoinNow Dynamic PKI
CDP attacks are a symptom of a larger problem: ports that trust any connected device.
JoinNow Cloud RADIUS offers a solution by authenticating every device against your identity provider before granting network access.
JoinNow Dynamic PKI provides the certificates used for that authentication, replacing shared secrets and static credentials with certificate-based authentication.
Cloud RADIUS and Dynamic PKI do not prevent CDP from disclosing information to an authorized device, but they can close the door that makes CDP reconnaissance possible: an open, unauthenticated port where an unknown device can connect to the network.
See how Cloud RADIUS and Dynamic PKI work together to authenticate network connections, or schedule a demo to discuss your current network access controls with our team.
Key Takeaways
- CDP advertisements can disclose device models, software versions, IP addresses, and VLAN information to any device connected to the same network segment.
- Attackers can use this information to map the network, identify potential vulnerabilities, and choose specific targets instead of relying on guesswork.
- Disabling CDP on untrusted interfaces and requiring device authentication with 802.1X can limit both what attackers can discover and where they can gain network access.
Frequently Asked Questions
Should I disable CDP entirely?
Not necessarily. Consider disabling it on user-facing and guest ports where connected devices don’t need to discover neighbor information. Many teams leave it enabled between trusted switches, routers, and Cisco IP phones, where it provides useful troubleshooting and auto-configuration benefits. If CDP is still needed on some interfaces, disable it selectively rather than globally.
Is LLDP more secure than CDP?
No, Link Layer Discovery Protocol functions similarly to Cisco Discovery Protocol and shares the same design weakness: neither protocol authenticates the frames it sends or receives. It broadcasts similar device and network information via unauthenticated channels, so using LLDP instead of CDP only moves the problem. The fix is to authenticate the port and connected devices.
Can CDP and LLDP run at the same time?
Yes. CDP and LLDP operate independently and can run simultaneously on the same interface. However, both protocols can disclose information about connected devices, so running both may increase the amount of network information available to an unauthorized device. An attacker only needs one discovery protocol to gather information and begin building a device inventory.
Does disabling CDP on an interface fully stop the information leak?
Not completely. Disabling CDP on an interface stops that port from sending and receiving CDP frames, although existing neighbor information may remain in the CDP table until its hold time expires. CDP information from other enabled interfaces may also remain accessible through authorized management methods such as SNMP. To eliminate CDP across the device, disable it globally or restrict access to the device's management interfaces.
