How to Fix CVE-2018-0175: LLDP format string flaw in Cisco IOS, IOS XE, and IOS XR

WARNING: This vulnerability is on the CISA Known Exploited Vulnerabilities catalog (added 2022-03-03). Federal civilian agencies must remediate by 2022-03-17. Treat it as active exploitation, not theoretical.

What is CVE-2018-0175?

CVE-2018-0175 is a format string vulnerability in the Link Layer Discovery Protocol (LLDP) subsystem of Cisco IOS Software, Cisco IOS XE Software, and Cisco IOS XR Software. LLDP is the protocol switches and routers use to advertise their identity and capabilities to directly connected neighbours. The parser that reads incoming LLDP frames passes attacker-controlled data into a format function without sanitising it. By sending a crafted LLDP frame, an unauthenticated attacker can corrupt memory in that process.

The result has two possible outcomes. The common one is a denial of service: the affected process or the whole device crashes and reloads, dropping every link it was carrying. The worst case is remote code execution with elevated privileges on the device. Cisco classifies the underlying weakness as CWE-119 (improper restriction of operations within the bounds of a memory buffer) and tracks the defect internally as bug ID CSCvd73664.

This is not a buffer overflow in user input fields or a web vulnerability. It lives in the control-plane code that processes Layer 2 management frames, which is why the patch is a full Cisco software image upgrade rather than a config tweak.

How bad is it, really?

The CVSS 3.1 base score is 8.0 (High) with the vector AV:A/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Two parts of that vector matter most for how you prioritise it:

• AV:A (adjacent network), the attacker must be Layer 2 adjacent. LLDP frames use a multicast destination and are not forwarded by routers, so an attacker has to be on the same broadcast segment as a vulnerable, LLDP-enabled interface. This is not an internet-facing, sprayable bug. The realistic threat model is a compromised host, a rogue device in a wiring closet, or an untrusted port in a shared facility.
• C:H/I:H/A:H. if the code-execution path lands, the impact is total: full compromise of the device that forwards your traffic.

Despite needing adjacency, CISA added this to its Known Exploited Vulnerabilities catalog on 2022-03-03, so working attack code is confirmed in the wild. The exploitation status detail sits in the threat-intelligence box above.

How to confirm you are exposed

Two things make a device vulnerable: it runs an affected IOS, IOS XE, or IOS XR build, and it has LLDP enabled on at least one interface. Check both from the device CLI.

1. Check the running version:

# Cisco IOS / IOS XE
show version | include Version

# Cisco IOS XR
show version | include "Version|IOS XR"

2. Check whether LLDP is actually running. If LLDP is globally off, the attack surface for this CVE is not present:

# IOS / IOS XE: is LLDP enabled, and on which interfaces?
show lldp
show lldp interface

# IOS XR
show lldp

If show lldp reports that LLDP is not enabled, the immediate risk is contained, but you should still plan the upgrade because any future lldp run re-exposes the flaw. Take the version string from step 1 to the Cisco advisory below to determine whether your specific train is affected.

How to fix CVE-2018-0175

The fix is to upgrade to a Cisco software release that Cisco has patched for this defect. There is no single fixed version that applies to every platform, IOS, IOS XE, and IOS XR each have their own affected trains and their own first-fixed builds. The authoritative source for the exact build is the Fixed Software table in advisory cisco-sa-20180328-lldp and the Cisco Software Checker.

Step 1: Find your fixed build

Open the Cisco Software Checker, enter your platform and current release (the string from show version), and it returns the first fixed release for your train. Do not guess a target build from a forum or aggregator, Cisco's tooling is the only source that maps your exact train to a patched image.

Step 2. Back up, stage, and upgrade

The exact commands differ between IOS/IOS XE and IOS XR. The pattern below is for classic IOS / IOS XE running from a bootflash image. Always back up the running config first and verify the image hash Cisco publishes before booting it.

! On the device (IOS / IOS XE)
enable
show version | include Version
copy running-config startup-config

! Copy the verified fixed image to flash (SCP shown; TFTP/FTP also work)
copy scp: flash:
verify /md5 flash:<fixed-image>.bin <published-md5-from-cisco>

! Point the boot loader at the fixed image and reload during a maintenance window
configure terminal
 no boot system
 boot system flash:<fixed-image>.bin
end
write memory
reload

On IOS XR, you install the upgrade as a package/SMU instead, using install add, install activate, and install commit, then verify with show install active. Follow the install procedure in the advisory for your specific XR release.

Step 3, Verify the patch landed

# IOS / IOS XE
show version | include Version
# Confirm the reported release matches the fixed build from the Software Checker

# IOS XR
show install active

If you can't patch immediately

Cisco's documented workaround is to remove the attack surface by turning LLDP off where it is not required. This stops the vulnerable parser from processing frames. It is a mitigation, not a fix: the flaw remains in the image until you upgrade.

Disable LLDP globally (IOS / IOS XE)

configure terminal
no lldp run
end
write memory

Disable LLDP on untrusted interfaces only

If some links genuinely need LLDP (for example IP phones using LLDP-MED), leave it on those and disable it on user-facing or untrusted ports:

configure terminal
interface GigabitEthernet0/1
 no lldp transmit
 no lldp receive
end
write memory

On IOS XR, disable LLDP with no lldp under the relevant configuration scope and commit. After any of these changes, confirm with show lldp interface that the protocol is no longer active on the ports you intended to lock down. Pair this with strict physical and port security on access ports, since the attacker has to reach a vulnerable segment to send the frame at all.

Disabling LLDP is the only meaningful interim control here. Management-plane ACLs and VTY restrictions do not help, because LLDP is processed on the data-link layer before any IP-layer filtering applies.

References

• Official vendor advisory: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180328-lldp
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2018-0175
• CISA KEV catalog entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://ics-cert.us-cert.gov/advisories/ICSA-18-107-03
• https://ics-cert.us-cert.gov/advisories/ICSA-18-107-04
• http://www.securitytracker.com/id/1040586
• https://ics-cert.us-cert.gov/advisories/ICSA-18-107-05

Written by Sai Kiran Pandrala on 2026-05-25. Always confirm against the vendor's advisory before applying changes in production.

Operational notes for fleets of Cisco gear

A few specifics about this CVE change how you should roll the fix out across a large estate of switches and routers.

Inventory by LLDP state, not just by version

Because the exposure depends on LLDP being enabled, your patch-priority list should be sorted by which devices actually run LLDP on untrusted segments. A core router with LLDP only on trusted uplinks is lower risk than an access switch advertising LLDP on user ports. If you manage configs centrally, grep your config backups for lldp run and the absence of per-interface no lldp to build that list before you schedule reloads.

The reload is the real cost

The image upgrade itself is routine, but it requires a reload, and a reload drops traffic. For redundant pairs, upgrade and reload one member at a time and confirm convergence before touching the second. For standalone access switches, this is a maintenance-window job. There is no hot-patch for an IOS control-plane defect like this one.

Match the train, not just the train number

The most common mistake on Cisco upgrades is jumping to a higher release that drops a feature you depend on, or that is not the recommended rebuild for your platform. Use the Cisco Software Checker output for your exact model and train rather than picking the newest available image. The advisory lists first-fixed releases per train precisely so you can stay on a supported, feature-compatible line.

Confirm the fix on the wire if you can

After upgrading, the version string is your primary proof. If you want a second signal, a controlled test from a lab port that sends a malformed LLDP frame should now be handled gracefully rather than crashing the process. Only do this in a lab against a device you can afford to reload, never against production gear.

Related fixes

Other flaws in this area worth reviewing while you patch this one:

• How to Fix CVE-2018-0180: Cwe-399 in Cisco IOS
• How to Fix CVE-2018-0179: Cwe-399 in Cisco IOS
• How to Fix CVE-2018-0161: Cwe-399 in Cisco IOS
• How to Fix CVE-2018-0156: Cwe-399 in Cisco IOS and IOS XE
• How to Fix CVE-2018-0171: Improper Input Validation in Cisco IOS and IOS XE