CSOs are being urged to quickly patch multiple vulnerabilities in Cisco Systems Identity Services Engine (ISE) and Cisco ISE Passive Identity Connector (ISE-PIC) that could allow an unauthenticated, remote attacker to issue commands on the underlying operating system as the root user.
The fault behind both vulnerabilities: Holes in application programming interfaces (APIs).
“Take this vulnerability seriously,” said Moses Frost, senior course instructor on cloud penetration testing at the SANS Institute. “In my experience assessing networks, I have found through testing that many lack essential patches and security hardening on their core network devices. I have seen Cisco ISE deployments where regular users can freely access all ports on ISE, including Administrative pages. Assume threat actors would also have lateral access from inside the network. Although this is not best practice from Cisco, many production deployments make these APIs accessible. If you are running ISE, patch this now.”
How big is the risk? Cisco ISE is often used as a wireless authentication system, Frost pointed out, which frequently includes guest network portals, and it’s also likely integrated into Microsoft Active Directory as a highly trusted system. It is also used to authenticate access to the administration layers of routers, switches, firewalls, and other network devices — and it can be used as a network access control (NAC) product.
‘One of the worst I’ve seen’
“This is probably one of the worst [flaws] I have seen in terms of impact,” said Kellman Meghu, principal security architect at DeepCove Cybersecurity. “It is a path for an unauthenticated, remote attacker to gain the highest-level privilege possible, so I am not even sure how it gets much worse that this, and then it does.”
“This is most serious for companies that are failing to perform the proper security hygiene,” said Robert Beggs, CEO of Canadian incident response firm Digital Defence.
By that he means those that don’t have a hardware inventory that includes network components, who don’t monitor vendor or media announcements of recent vulnerabilities, or who lack the licensing that facilitates system upgrades and patches.
Cisco has patches for these issues, but they aren’t delivered automatically, he pointed out, and admins have to follow Cisco’s process to obtain the patch.
Because ISE is the gatekeeper for network access (wired, wireless, VPN, or guest access), he warned, root access will allow attackers to gain the credentials for full movement through all network segments.
“At present, there are no reports that these are being exploited in the wild,” he said in an email to CSO. “However, they are zero-interaction exploits, so it is possible for attacks to go undetected. Because there is no need to authenticate, it is critical to apply the patches as soon as possible, as exploits will likely be available soon — if they are not already in use.”
Rated critical
The vulnerabilities — rated by Cisco as critical — are:
CVE-2025-20281 affects Cisco ISE and ISE-PIC releases 3.3 and later, regardless of device configuration. An attacker does not require any valid credentials to exploit this vulnerability.
This vulnerability in a specific API is due to insufficient validation of user-supplied input. An attacker could exploit this vulnerability by submitting a crafted API request and then gain root privileges on an affected device;
CVE-2025-20282 affects only Cisco ISE and ISE-PIC Release 3.4, regardless of device configuration.
This API vulnerability is due a lack of file validation checks that would prevent uploaded files from being placed in privileged directories on an affected system. An attacker could exploit this vulnerability by uploading a crafted file to the device. A successful exploit could allow the attacker to store malicious files on the affected system and then execute arbitrary code or obtain root privileges on the system.
No workarounds
Patches must be installed for both vulnerabilities; there are no workarounds.
Furthermore, the vulnerabilities are not dependent on one another, Cisco stresses in its advisory. Exploitation of one of the vulnerabilities is not required to exploit the other vulnerability. In addition, a software release that is affected by one of the vulnerabilities may not be affected by the other one.
While APIs in general are great, said Frost, “the unfortunate part of them is that many of the standard Web application vulnerabilities also apply. What is actually worse than that is that the bugs we had 10 or more years ago, which were solved by frameworks, are all reappearing in APIs.”
He added, “If I were running a development team around this today, I would look back at older OWASP bugs [identified by the Open Web Application Security Project] to ensure that certain bug classes that had been eliminated, such as vulnerabilities related to unauthenticated endpoints or mass assignment issues, are still addressed.”
Common API vulnerabilities
As a key way of linking applications and sharing data, APIs are a vital part of mobile, SaaS, and web applications. As OWASP notes, by nature, APIs expose application logic and sensitive data such as personally identifiable information (PII), so are targets for threat actors if they aren’t written with secure code. OWASP’s API Security Project outlines best practices for developers to avoid API problems like:
broken object level authorization. To prevent this, object level authorization checks should be considered in every function that accesses a data source using an ID from the user;
broken authorization due to incorrectly implemented authorization mechanisms. This allows attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities. CSOs should make sure developers know all the possible flows to authenticate to the API.
API keys should not be used for user authentication, stresses OWASP. They should only be used for API clients authentication. OAuth is not authentication, OWASP adds, and neither are API keys;
unrestricted resource consumption of APIs, which can lead to denial of service attacks;
unrestricted access to sensitive business flows;
server side request forgery (SSRF), caused by an API fetching a remote resource without validating the user supplied URI (uniform resource identifier). This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN;
security misconfigurations. APIs and the systems supporting them typically contain complex configurations. That, says OWASP, is meant to make the APIs more customizable. However, software and DevOps engineers can miss these configurations, or don’t follow security best practices when it comes to configuration, opening the door for different types of attacks.
OWASP says the API life cycle should include a repeatable hardening process leading to fast and easy deployment of a properly locked down environment; a task to review and update configurations across the entire API stack. The review should include: orchestration files, API components, and cloud services (for example, S3 bucket permissions); and an automated process to continuously assess the effectiveness of the configuration and settings in all environments.
In addition, application development leaders should ensure that all API communications from the client to the API server and any downstream/upstream components happen over an encrypted communication channel (TLS), regardless of whether it is an internal or public-facing API.
For more advice to CSOs on securing API operations, check out The CISO’s 5-step guide to securing AI operations.
And those thinking AI-generated code will be safer may find that they actually are more likely to expose API keys and other secrets, according to this study.
Multiple layer of defense needed
As cooler and slicker automations are added to existing IT systems, coding errors are inevitable, Meghu noted.
For defense, CSOs should ensure their networks use multiple layers of validation whenever possible, he said, for example, a web application firewall (WAF) that inspects and only allows API calls from specific sources. But, he added, these protections can be impaired as partners introduce more and more third party SaaS services “and all the API goodness that comes with it.”
No Responses