Cisco IOS XE Wireless Controller Software Arbitrary File Upload Vulnerability
TL;DR π
- A vulnerability in the Out-of-Band Access Point (AP) Image Download, the Clean Air Spectral Recording, and the client debug bundles features of Cisco IOS XE Software for Wireless LAN Controllers (WLCs) could allow an unauthenticated, remote attacker to upload arbitrary files to an affected system. This vulnerability is due to the presence of a hard-coded JSON Web Token (JWT) onβ¦
- No fixed release listed yet; apply mitigations and monitor.
- Workarounds are documented in the advisory.
- CVEs: CVE-2025-20188.
What happened π΅οΈββοΈ
A vulnerability in the Out-of-Band Access Point (AP) Image Download, the Clean Air Spectral Recording, and the client debug bundles features of Cisco IOS XE Software for Wireless LAN Controllers (WLCs) could allow an unauthenticated, remote attacker to upload arbitrary files to an affected system.
This vulnerability is due to the presence of a hard-coded JSON Web Token (JWT) on an affected system. An attacker could exploit this vulnerability by sending crafted HTTPS requests to the AP file upload interface. A successful exploit could allow the attacker to upload files, perform path traversal, and execute arbitrary commands with root privileges.
Cisco has released software updates that address this vulnerability. There are workarounds that address this vulnerability.
This advisory is part of the May 2025 release of the Cisco IOS and IOS XE Software Security Advisory Bundled Publication. For a complete list of the advisories and links to them, see Cisco Event Response: May 2025 Semiannual Cisco IOS and IOS XE Software Security Advisory Bundled Publication [“https://sec.cloudapps.cisco.com/security/center/viewErp.x?alertId=ERP-75279”].
Affected products π₯οΈ
This vulnerability affects the following Cisco products if they are running a vulnerable release of Cisco IOS XE Software for WLCs, regardless of device configuration.
Catalyst 9800-CL Wireless Controllers for Cloud Catalyst 9800 Embedded Wireless Controller for Catalyst 9300, 9400, and 9500 Series Switches Catalyst 9800 Series Wireless Controllers Embedded Wireless Controller on Catalyst APs
For information about which Cisco software releases are vulnerable, see the Fixed Software ["#fs"] section of this advisory.
Fixed software π§
Upgrade to the first fixed release in your train (or later):
| Release / Product | First Fixed Release | Notes |
|---|---|---|
| 2.2 | Updated the mitigations. | |
| 2.1 | Prioritized the mitigations over the workaround, as the preferred method. | |
| 2.0 | Added two more affected features. Updated the vulnerable configuration conditions. Added a workaround and mitigations. Added the fact that Cisco is aware of proof of concept code. | |
| 1.0 | Initial public release. |
Workarounds π§―
There are two mitigations that are preferred for addressing this vulnerability for the two possible device configurations: Impacted Features Not in Use If the impacted features are not used, apply infrastructure access control lists (iACLs) to all interfaces and block the interface completely, as shown in the following example. This will completely mitigate the vulnerability.
wlc# show ap file-transfer https summary Configured port : 8443 Operational port : 8443 wlc# show ip access-lists CVE-2025-20188 10 deny tcp any any eq 8443 20 permit ip any any Impacted Features in Use If the impacted features are used, to reduce the attack surface, apply iACLs to limit the AP file upload interface to the WLC to allow traffic from expected sources only. The following is an iACL example that can be included as part of the deployed iACL:
wlc# show ap file-transfer https summary Configured port : 8443 Operational port : 8443 wlc# show ip access-lists CVE-2025-20188 10 deny tcp any INFRASTRUCTURE_ADDRESSES WILDCARD eq 8443 20 permit ip any any
For more guidelines and recommendations for deployment techniques for iACLs, see the white paper Protecting Your Core: Infrastructure Protection Access Control Lists [“https://www.cisco.com/c/en/us/support/docs/ip/access-lists/43920-iacl.html”].
There is also a workaround that addresses this vulnerability.
Manually triggering the AP client debug bundle once, as shown in the following example, will protect all affected features that use the AP file upload interface. Note that this workaround does not persist through reload and must be done any time the device is reloaded.
! Check and pick any one client in any AP associated with this WLC wlc# show wireless client summary Number of Clients: 1 MAC Address AP Name Type ID State Protocol Method Role ——————————————————————————————- 5eef.1000.0001 AP5EEF.1000.0003 WLAN 1 Run 11n(5) None Local Number of Excluded Clients: 0 ! Manually trigger the debug bundle once wlc# debug wireless bundle client mac 0100.5eef.1000.0001 Wireless Client debug bundle add event ! Get the site-tag wlc# show ap tag summary | inc AP5EEF.1000.0003|AP Name
AP Name AP Mac Site Tag Name Policy Tag Name RF Tag Name Misconfigured Tag Source AP5EEF.1000.0003 5eef.1000.0003 ST1 policy-tag rf-tag No Static
! Be sure to change the monitor-time to 60 so this process will take 60 seconds and not longer wlc# debug wireless bundle client start ap-archive site-tag ST1 level debug monitor-time 60 ! Stop debug bundle after 60 seconds wlc# debug wireless bundle client stop-all collect all ! A debug bundle should be generated and the workaround was successfully executed wlc# dir bootflash:completeCDB/* 2883591 -rw- 383488 Jan 6 2025 11:18:25 +00:00 wireless_bundle_0100.5eef.1000.0001.tar 96739794944 bytes total (75825774592 bytes free)
While these workarounds and mitigations have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.
Risk in context π―
Use vendor CVSS for prioritization. Consider exposure and asset criticality.
Fast facts β‘
- Advisory: cisco-sa-wlc-file-uplpd-rHZG9UfC
- Initial release: 2025-05-07T16:00:00 UTC
- Last updated: 2025-06-06T20:02:48 UTC
For leadership π§
Executive summary. Risk is Critical (CVSS 10.0) for 17.11, 17.11.1. Vendor fixes are available; prioritize upgrade within 48β72 hours based on environment risk.
Why it matters (exposure drivers):
- Potential service impact and security exposure depend on deployment topology and access paths.
- Treat internet-exposed or multi-tenant management nodes as higher risk.
- Ensure monitoring for abnormal auth/config events until upgrades complete.
Remediation & timing:
- Upgrade to the first fixed release per the table above; schedule an approved change window within 48β72 hours.
- Change risk: low-to-moderate (standard vendor patch). Validate backups and rollback plan.
Now / Next / Later:
- Now: Confirm exposure, identify affected versions, and enable monitoring/alerts.
- Next: Patch according to the fixed software table; verify service health post-change.
- Later: Add control checks to build pipeline/CMDB to block drift to vulnerable trains.