Cisco Catalyst Center Insufficient Access Control Vulnerability

TL;DR 📌

A medium-severity vulnerability has been identified in Cisco Catalyst Center, allowing authenticated remote attackers to read and modify data due to insufficient access control on HTTP requests. No workarounds are available, and affected users are advised to upgrade to fixed software versions.

What happened 🕵️‍♂️

Cisco has disclosed a vulnerability in the Cisco Catalyst Center, formerly known as Cisco DNA Center. This flaw stems from insufficient enforcement of access control on HTTP requests, enabling an authenticated remote attacker to exploit the vulnerability by sending a crafted HTTP request. A successful exploit could allow attackers to read and modify data managed by an internal service on the affected device.

Affected products 🖥️

The vulnerability specifically affects Cisco Catalyst Center deployments that have Disaster Recovery enabled. It’s important to note that Disaster Recovery is not enabled by default. To determine if your deployment is affected, check the status of Disaster Recovery in the Cisco Catalyst Center GUI under System > Disaster Recovery.

Fixed software 🔧

Upgrade to at least the first fixed release in your train (or later):

Workarounds 🧯

There are no workarounds available to mitigate this vulnerability.

Risk in context 🎯

With a CVSS score of 4.7, this vulnerability is classified as medium severity. While it requires authentication to exploit, the potential for data manipulation poses a significant risk to the integrity of data within the affected systems.

Fast facts ⚡

• Vulnerability ID: CVE-2025-20223
• Severity: Medium (CVSS 4.7)
• Exploitation: Requires authenticated access
• No workarounds available

For leadership 🧭

Executive summary. Any Catalyst Center deployment running Disaster Recovery has a gap in access control that lets a logged-in user reach and change data an internal service should be protecting. There’s no workaround, so this needs to go into the next patch cycle rather than being deferred indefinitely.

Why it matters:

• Only deployments with Disaster Recovery switched on are exposed, but that feature governs failover data, so tampering there could undermine recovery integrity precisely when it’s needed most.
• Exploitation requires an authenticated session, meaning any legitimate but lower-privileged user account could be the entry point, not just an external attacker.
• The flaw sits in access control enforcement on HTTP requests to an internal service, so the attacker doesn’t need to break authentication, just send a crafted request once inside.
• With no mitigating configuration available, exposure persists unchanged until the software itself is upgraded.

Now / Next / Later:

• Now: Check System > Disaster Recovery in the Catalyst Center GUI to confirm whether the feature is enabled on your deployment; if it is, treat this as exposed today.
• Next: Schedule an upgrade to the fixed software release for your Catalyst Center train during the next maintenance window, since no workaround exists to buy time.
• Later: Review who holds authenticated access to Catalyst Center and tighten account provisioning, given that exploitation here relies solely on having a valid login rather than any external compromise.