Cisco IOS XE Software for Catalyst 9800 Series Wireless Controller for Cloud Unauthenticated Access to Certificate Enrollment Service Vulnerability

🚨SEVERITY: MEDIUM β€” CVSS 5.3Security Advisory

TL;DR πŸ“Œ

  • A vulnerability in the Day One setup process of Cisco IOS XE Software for Catalyst 9800 Series Wireless Controllers for Cloud (9800-CL) could allow an unauthenticated, remote attacker to access the public-key infrastructure (PKI) server that is running on an affected device. This vulnerability is due to incomplete cleanup upon completion of the Day One…
  • Highest CVSS: 5.3 (Medium).
  • Check the advisory for fixed releases β€” remediation detail is in the vendor link below.
  • CVEs: CVE-2025-20293.

What it is

CVE-2025-20293 affects the Day One setup process on Cisco Catalyst 9800 Series Wireless Controllers for Cloud (9800-CL). Cisco confirms the hardware-based 9800 controllers are not affected β€” this is specific to the virtual appliance.

The problem is incomplete cleanup once Day One setup finishes. This leaves a PKI server reachable via Simple Certificate Enrollment Protocol (SCEP) exposed on the device. An unauthenticated, remote attacker with network reach to the controller can send SCEP requests to this server and obtain a valid certificate from the virtual WLC β€” no credentials or prior access required.

With that certificate in hand, the attacker can join an attacker-controlled device to the wireless LAN controller as if it were a legitimate access point or peer. The vulnerability doesn’t grant direct read or write access to controller data (Cisco’s own scoring shows no confidentiality, integrity or availability impact beyond this), but it does allow an untrusted device to register itself against the WLC’s control plane.

Cisco says this affects the Catalyst 9800-CL “regardless of device configuration,” meaning the exposure isn’t tied to a particular feature being enabled β€” any 9800-CL instance that has been through Day One setup is potentially reachable.

What to do

  • Identify any Catalyst 9800-CL (cloud/virtual) instances in your estate β€” hardware 9800 controllers are not affected by this issue.
  • Apply the workaround now if you can’t patch immediately: shut down the <hostname>_WLC_CA PKI server on the WLC. On a controller named vewlc, this is:
    conf t
    crypto pki server vewlc_WLC_CA
    shutdown
    exit
    write memory
    
    Test this in your own environment first β€” Cisco notes it worked in their test setup but results may vary depending on your deployment.
  • Use the Cisco Software Checker against your current release to identify the “First Fixed” version for this advisory; Cisco hasn’t published a fixed-release table with explicit version numbers in the advisory text, so run your release through the tool rather than guessing.
  • Treat this as reachable from the network and unauthenticated β€” if the 9800-CL’s management or SCEP-facing interface is exposed beyond a trusted segment, restrict access to it while you plan remediation.
  • This isn’t listed in CISA’s Known Exploited Vulnerabilities catalogue, and Cisco PSIRT states it isn’t aware of public exploitation, so there’s no urgency signal from that angle β€” but the workaround costs little to apply while you schedule the upgrade.

For leadership 🧭

Executive summary. Any Catalyst 9800-CL virtual wireless controller that has completed Day One setup is running an exposed certificate server that unauthenticated attackers can query over the network to obtain a valid device certificate. There’s no known exploitation yet, so this can go through a normal change window, but the workaround is cheap enough to apply immediately if the controller is reachable outside a trusted segment.

Why it matters:

  • The flaw is specific to the 9800-CL virtual appliance β€” hardware-based Catalyst 9800 controllers are confirmed unaffected, so scoping should focus only on cloud/virtual instances.
  • Incomplete cleanup after Day One setup leaves the SCEP-based PKI server reachable, letting an unauthenticated remote attacker request a certificate without credentials.
  • That certificate lets an attacker-controlled device join the wireless LAN controller’s control plane as if it were a legitimate access point or peer.
  • Exposure isn’t tied to any optional feature β€” Cisco states it affects the 9800-CL regardless of configuration, so every instance that has run Day One setup is a candidate.

Now / Next / Later:

  • Now: Inventory all Catalyst 9800-CL (virtual) instances and check whether their SCEP-facing or management interface is reachable from untrusted networks.
  • Next: In the next change window, either apply the fixed IOS XE release identified via Cisco’s Software Checker, or shut down the hostname_WLC_CA PKI server on each affected controller as an interim workaround, after testing it in a non-production environment.
  • Later: Build Day One setup completion into a standard post-deployment checklist that includes disabling or restricting the PKI/SCEP server once enrolment is finished, so leftover services aren’t left reachable on future 9800-CL deployments.

Source