This article is a part of our Vulnerability Database (back to index)
Cross-site Scripting occurrences in Prestashop
File upload vulnerability in the Catalog feature in Prestashop 1.7.6.7 allows remote attackers to run arbitrary code via the add new file page. (2022-07-13, CVE-2020-21967)
PrestaShop is a fully scalable open source e-commerce solution. In PrestaShop before version 1.7.7.3, an attacker can inject HTML when the Grid Column Type DataColumn is badly used. The problem is fixed in 1.7.7.3 (2021-03-30, CVE-2021-21398)
In PrestaShop from version 1.5.0.0 and before version 1.7.6.8, users are allowed to send compromised files. These attachments allowed people to input malicious JavaScript which triggered an XSS payload. The problem is fixed in version 1.7.6.8. (2020-09-24, CVE-2020-15162)
In PrestaShop from version 1.6.0.4 and before version 1.7.6.8 an attacker is able to inject javascript while using the contact form. The problem is fixed in 1.7.6.8 (2020-09-24, CVE-2020-15161)
In PrestaShop from version 1.5.3.0 and before version 1.7.6.6, there is a stored XSS when using the name of a quick access item. The problem is fixed in 1.7.6.6. (2020-07-02, CVE-2020-11074)
In PrestaShop from version 1.7.0.0 and before version 1.7.6.6, if a target sends a corrupted file, it leads to a reflected XSS. The problem is fixed in 1.7.6.6 (2020-07-02, CVE-2020-15083)
In PrestaShop before version 1.7.6.5, there is a reflected XSS while running the security compromised page. It allows anyone to execute arbitrary action. The problem is patched in the 1.7.6.5. (2020-04-20, CVE-2020-5264)
In PrestaShop between versions 1.5.4.0 and 1.7.6.5, there is a reflected XSS on Exception page The problem is fixed in 1.7.6.5 (2020-04-20, CVE-2020-5278)
In PrestaShop between versions 1.5.5.0 and 1.7.6.5, there is a reflected XSS on Search page with `alias` and `search` parameters. The problem is patched in 1.7.6.5 (2020-04-20, CVE-2020-5272)
In PrestaShop between versions 1.6.0.0 and 1.7.6.5, there is a reflected XSS with `date_from` and `date_to` parameters in the dashboard page This problem is fixed in 1.7.6.5 (2020-04-20, CVE-2020-5271)
In PrestaShop between versions 1.7.1.0 and 1.7.6.5, there is a reflected XSS on AdminCarts page with `cartBox` parameter The problem is fixed in 1.7.6.5 (2020-04-20, CVE-2020-5276)
In PrestaShop between versions 1.7.4.0 and 1.7.6.5, there is a reflected XSS when uploading a wrong file. The problem is fixed in 1.7.6.5 (2020-04-20, CVE-2020-5286)
In PrestaShop between versions 1.7.6.0 and 1.7.6.5, there is a reflected XSS with `back` parameter. The problem is fixed in 1.7.6.5 (2020-04-20, CVE-2020-5285)
In PrestaShop between versions 1.7.6.1 and 1.7.6.5, there is a reflected XSS on AdminAttributesGroups page. The problem is patched in 1.7.6.5. (2020-04-20, CVE-2020-5265)
In PrestaShop between versions 1.7.6.1 and 1.7.6.5, there is a reflected XSS on AdminFeatures page by using the `id_feature` parameter. The problem is fixed in 1.7.6.5 (2020-04-20, CVE-2020-5269)
In PrestaShop 1.7.6.2, XSS can occur during addition or removal of a QuickAccess link. This is related to AdminQuickAccessesController.php, themes/default/template/header.tpl, and themes/new-theme/js/header.js. (2020-01-09, CVE-2020-6632)
In PrestaShop 1.7.5.2, the shop_country parameter in the install/index.php installation script/component is affected by Reflected XSS. Exploitation by a malicious actor requires the user to follow the initial stages of the setup (accepting terms and conditions) before executing the malicious link. (2019-05-24, CVE-2019-11876)
PrestaShop 1.7.2.4 has XSS via source-code editing on the "Pages > Edit page" screen. (2018-01-13, CVE-2018-5681)
Why Cross-site Scripting can be dangerous
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>