Cisco Access Point Software Intermittent IPv6 Gateway Change Vulnerability

🚨SEVERITY: MEDIUM — CVSS 4.3Security Advisory

TL;DR 📌

  • A vulnerability in the IPv6 Router Advertisement (RA) packet processing of Cisco Access Point Software could allow an unauthenticated, adjacent attacker to modify the IPv6 gateway on an affected device. This vulnerability is due to a logic error in the processing of IPv6 RA packets that are received from wireless clients. An attacker could exploit…
  • Highest CVSS: 4.3 (Medium).
  • Fix available — see the first fixed release below.
  • CVEs: CVE-2025-20365.

What it is

CVE-2025-20365 is a logic error in how Cisco Access Point Software processes IPv6 Router Advertisement (RA) packets received from wireless clients. It affects APs that are configured for CAPWAP over IPv6 to their wireless LAN controller.

An attacker needs to be adjacent — associated to the wireless network the AP serves — and unauthenticated beyond that. By sending a series of crafted IPv6 RA packets, they can trigger the AP to temporarily change its IPv6 gateway. This is a data-plane issue rather than a management-plane compromise: there’s no indication of credential theft or code execution. The practical effect is intermittent packet loss for wireless clients associated with the affected AP while the gateway is incorrect.

Affected hardware includes 6300 Series Embedded Services APs, Aironet 1540/1560/1800/2800/3800 Series, Aironet 4800, Catalyst 9100 APs, Catalyst IW6300 Heavy Duty Series, and integrated APs on 1100 Series ISRs — but only when those APs are configured for CAPWAP over IPv6. APs using IPv4 CAPWAP are not exposed.

Cisco’s PSIRT states it is not aware of any public announcements or malicious use of this vulnerability.

What to do

  • Check whether your APs are configured for CAPWAP over IPv6: run show ap summary on the wireless LAN controller and look for any AP with an IPv6 address in the IP Address column. If none show IPv6, this vulnerability does not apply to those devices.
  • For Catalyst 9800 Wireless Controller or EWC-managed APs, upgrade the controller’s IOS XE release: 17.9 to 17.9.7, 17.12 to 17.12.5, or 17.15 to 17.15.2. Releases 17.16, 17.17 and 17.18 are not vulnerable. Any release 17.8 or earlier, or 17.10, 17.11, 17.13, or 17.14, has no fix in-branch — migrate to one of the fixed releases listed above.
  • Remember the AP itself doesn’t get patched directly — the fix ships via the wireless controller the AP registers to, so plan the controller upgrade as the remediation step.
  • There are no workarounds. If IPv6 CAPWAP can’t be upgraded promptly, consider switching affected APs to IPv4 CAPWAP as an interim measure, bearing in mind this isn’t a Cisco-documented mitigation.
  • For controllers or platforms not covered by a fixed release in this advisory (including end-of-life wireless controller software), consult the relevant end-of-life notices for migration guidance rather than expecting a patch.

Fixed releases

Affected release First fixed release
17.9 17.9.7
17.12 17.12.5
17.15 17.15.2

For leadership 🧭

Executive summary. Any wireless client on networks served by affected Cisco APs configured for CAPWAP over IPv6 can disrupt connectivity by forcing a temporary gateway change, with no credentials required beyond network association. There’s no known exploitation yet and no data-plane compromise beyond packet loss, so this can be scheduled through a normal controller upgrade rather than an emergency change.

Why it matters:

  • An unauthenticated attacker only needs to associate to the wireless network served by the AP — no controller or admin credentials are needed to send the crafted IPv6 RA packets.
  • Affected hardware spans a wide fleet: 6300 Series, Aironet 1540/1560/1800/2800/3800/4800, Catalyst 9100, Catalyst IW6300, and integrated APs on 1100 ISRs, but only when CAPWAP is running over IPv6.
  • The fix isn’t applied to the AP directly — it requires upgrading the Catalyst 9800 or EWC controller the AP registers to, so remediation depends on controller maintenance windows.
  • There are no workarounds; the only interim option is switching affected APs to IPv4 CAPWAP, which Cisco has not documented as a mitigation.

Now / Next / Later:

  • Now: Run show ap summary on each wireless LAN controller and note any AP listed with an IPv6 address — those are exposed to this issue.
  • Next: Upgrade the affected Catalyst 9800/EWC controllers to a fixed IOS XE release (17.9.7, 17.12.5, or 17.15.2) during the next change window, or migrate off 17.8-and-earlier, 17.10, 17.11, 17.13, or 17.14 to a fixed train.
  • Later: Standardise on IPv4 CAPWAP where IPv6 isn’t operationally required, and track wireless controller software against Cisco’s fixed-release table as part of routine patch cycles.

Source