Phpmyadmin Cross-site Scripting

An issue was discovered in phpMyAdmin 5.1 before 5.1.2. An attacker can inject malicious code into aspects of the setup script, which can allow XSS or HTML injection. (2022-01-22, CVE-2022-23808)

phpMyAdmin before 4.9.6 and 5.x before 5.0.3 allows XSS through the transformation feature via a crafted link. (2020-10-10, CVE-2020-26934)

In phpMyAdmin 4.x before 4.9.5 and 5.x before 5.0.2, a SQL injection vulnerability was discovered where malicious code could be used to trigger an XSS attack through retrieving and displaying results (in tbl_get_field.php and libraries/classes/Display/Results.php). The attacker must be able to insert crafted data into certain database tables, which when retrieved (for instance, through the Browse tab) can trigger the XSS attack. (2020-03-22, CVE-2020-10803)

In phpMyAdmin before 4.8.4, an XSS vulnerability was found in the navigation tree, where an attacker can deliver a payload to a user through a crafted database/table name. (2018-12-11, CVE-2018-19970)

An issue was discovered in phpMyAdmin before 4.8.3. A Cross-Site Scripting vulnerability has been found where an attacker can use a crafted file to manipulate an authenticated user who loads that file through the import feature. (2018-08-24, CVE-2018-15605)

An issue was discovered in js/designer/move.js in phpMyAdmin before 4.8.2. A Cross-Site Scripting vulnerability has been found where an attacker can use a crafted database name to trigger an XSS attack when that database is referenced from the Designer feature. (2018-06-21, CVE-2018-12581)

Cross-site scripting (XSS) vulnerability in db_central_columns.php in phpMyAdmin before 4.7.8 allows remote authenticated users to inject arbitrary web script or HTML via a crafted URL. (2018-02-21, CVE-2018-7260)

Cross site scripting is an attack where a web page executes code that is injected by an adversary. It usually appears, when users input is presented. This attack can be used to impersonate a user, take over control of the session, or even steal API keys.

The attack can be executed e.g. when you application injects the request parameter directly into the HTML code of the page returned to the user:

https://server.com/confirmation?message=Transaction+Complete

what results in:

<span>Confirmation: Transaction Complete</span>

In that case the message can be modified to become a valid Javascript code, e.g.:

https://server.com/confirmation?message=<script>dangerous javascript code here</script>

and it will be executed locally by the user's browser with full access to the user's personal application/browser data:

<span>Confirmation: <script>dangerous javascript code here</script></span>