PrestaShop contains an authenticated PHP code injection vulnerability in the back-office Performance debug-mode configuration. A back-office user with permission to modify debug settings can supply a crafted debugcookiename or debugcookievalue that is written without sufficient escaping into a PHP configuration file. When PrestaShop subsequently loads the generated file, the injected PHP code is executed with the privileges of the web-server process.

Impact Any module can be disabled or uninstalled from back office, even with low user right.

Patches 8.1.2

Workarounds none

References

In PrestaShop Dashboard Productions before version 2.1.0, there is improper authorization which enables an attacker to change the configuration. The problem is fixed in 2.1.0.

In PrestaShop Dashboard Productions before version 2.1.0, there is improper authorization which enables an attacker to change the configuration. The problem is fixed in 2.1.0.

Impact Fix improper use of validation framework

Patches Patched in 8.2.5 and 9.1.0

Workarounds None

References none

Impact Multiple stored Cross-Site Scripting (stored XSS) vulnerabilities in the BO: an attacker who can inject data into the database, via limited back-office access or a previously existing vulnerability, can exploit unprotected variables in back-office templates.

Patches Patched on 8.2.5 and 9.1.0

Workarounds None

References None

Impact An unauthenticated attacker with access to the back-office URL can manipulate the idemployee and resettoken parameters to enumerate valid back-office employee email addresses.

Impacted parties: Store administrators and employees: their email addresses are exposed. Merchants: risk of phishing, social engineering, and brute-force attacks targeting admin accounts.

Patches PrestaShop 8.2.3

Workarounds You must upgrade, or at least apply the changes from the PrestaShop 8.2.3 patch. More information: https://build.prestashop-project.org/news/2025/prestashop-8-2-3-security-release/

PrestaShop psgdpr versions through 1.4.3 fail to validate that GDPR consent log entries are attributed to the authenticated customer. Authenticated attackers can submit arbitrary customer identifiers to create forged consent records for other customers, corrupting audit logs.

PrestaShop psgdpr versions through 1.4.3 fail to validate that GDPR consent log entries are attributed to the authenticated customer. Authenticated attackers can submit arbitrary customer identifiers to create forged consent records for other customers, corrupting audit logs.

In version 8.2.1 of PrestaShop, there is a vulnerability relating to the incorrect sanitisation of elements, caused by inadequate validation of the ‘Alias’ parameter in the ‘Update your address’ function. This flaw allows an attacker to inject malicious expressions that are executed when the information is exported using the ‘Get my data in CSV’ tool. Successful exploitation of this vulnerability could facilitate unauthorised access to the victim’s personal data.

PrestaShop dpdfrance <6.1.3 is vulnerable to SQL Injection via dpdfrance/ajax.php.

Impact Missing validation on Express Checkout feature allows silent log-in

Affected versions

The issue was introduced in PrestaShop Checkout 1.3.0 .

All versions above 1.3.0 are vulnerable except of course the patch versions published on 16/10/2025: 7.4.4.1, 8.4.4.1, 7.5.0.5, 8.5.0.5, 9.5.0.5

Patches The problem has been patched in versions

- v4.4.1 for PrestaShop 1.7 (build number: 7.4.4.1) - v4.4.1 for PrestaShop 8 (build number: 8.4.4.1) - v5.0.5 for PrestaShop 1.7 (build number: 7.5.0.5) - v5.0.5 for PrestaShop 8 (build number: 8.5.0.5) - v5.0.5 for PrestaShop 9 (build number: 9.5.0.5)

Read our Versioning policy to learn more about our build numbers and versions of PrestaShop Checkout

Credits We would like to thank Léo CUNÉAZ for reporting the issue.

Impact Missing validation on input vulnerable to directory traversal.

Patches The problem has been patched in versions:

v4.4.1 for PrestaShop 1.7 (build number: 7.4.4.1) v4.4.1 for PrestaShop 8 (build number: 8.4.4.1) v5.0.5 for PrestaShop 1.7 (build number: 7.5.0.5) v5.0.5 for PrestaShop 8 (build number: 8.5.0.5) v5.0.5 for PrestaShop 9 (build number: 9.5.0.5)

Read the Versioning policy to learn more about the build number.

Credits Léo CUNÉAZ for reportied this issue.

Impact Wrong usage of the PHP arraysearch() allows bypass of validation.

Patches The problem has been patched in versions: - v4.4.1 for PrestaShop 1.7 (build number: 7.4.4.1) - v4.4.1 for PrestaShop 8 (build number: 8.4.4.1) - v5.0.5 for PrestaShop 1.7 (build number: 7.5.0.5) - v5.0.5 for PrestaShop 8 (build number: 8.5.0.5) - v5.0.5 for PrestaShop 9 (build number: 9.5.0.5)

Read the Versioning policy to learn more about the build number.

Credits Léo CUNÉAZ reported this issue.

Google Merchant Center Feed (gmfeed) module for PrestaShop is vulnerable to unauthenticated arbitrary file write in the feed.php endpoint. An unauthenticated attacker can send a crafted request that controls the output file name, path, extension, and content through request parameters. Due to the lack of authentication and input validation, the request is processed successfully, allowing an attacker to write and execute arbitrary PHP code, resulting in remote code execution (RCE).

This issue was fixed in version 2.3.9.

PrestaShop blockwishlist through 3.0.2 fails to validate wishlist ownership in the getUrlByIdWishListAction method, allowing authenticated customers to retrieve share tokens for any wishlist by identifier. Attackers can supply sequential wishlist identifiers to obtain valid share links and read other customers' private wishlist contents.

Vulnerability involving incorrect access control in the Tools::getRemoteAddr() function in PrestaShop, which allows the client’s IP address to be spoofed via the X-Forwarded-For header when the application is running behind a reverse proxy, load balancer or CDN. The application incorrectly processes the IP address string and uses the address controlled by the visitor rather than the one provided by the trusted infrastructure, allowing an unauthenticated remote attacker to cause the application to interpret their connection as originating from an arbitrary IP address. This condition allows IP-based controls, such as the maintenance mode allowlist, to be bypassed, as well as enabling the forgery of security and audit logs and the evasion of third-party mechanisms that rely on the IP address, such as geolocation checks, fraud detection or request throttling.

A PHAR deserialization vulnerability in the component /themes/import of PrestaShop v8.2.0 allows attackers to execute arbitrary code via a crafted POST request.

A PHAR deserialization vulnerability in the getHeaders function of PrestaShop v8.2.0 allows attackers to execute arbitrary code via a crafted POST request.

Impact A time-based user enumeration vulnerability in the user authentication functionality of PrestaShop. This vulnerability allows an attacker to determine whether a customer account exists in the system by measuring response times.

Patches 8.2.4 and 9.0.3

Workarounds none

References Found by Lam Yiu Tung

Impact This can not be exploited in a fresh install of PrestaShop, only shops made vulnerable by third party modules are concerned.

For example, if your shop has a third party module vulnerable to SQL injections, then pscontactinfo might execute a stored XSS in FO.

Patches The long term fix is to have all your modules maintained and updated. The fix on pscontactinfo will keep formatted addresses from displaying an xss stored in the database.

Workarounds none

References none

Impact Only PrestaShops with customer-thread feature flag enabled are impacted, starting from PrestaShop 8.1.0.

The impact is substantial, when the customer thread feature flag is enabled, through the front-office contact form, a hacker can upload a malicious file containing an XSS that will be executed when an admin opens the attached file in back office.

Consequence: the script injected can access the session and the security token, which allows it to perform any authenticated action in the scope of the administrator's right.

Patches This vulnerability is patched in 8.1.6.

Workarounds As long as you have not upgraded to 8.1.6, a simple workaround is to disable the customer-thread feature-flag.

Thank you to Ayoub AIT ELMOKHTAR, who discovered this vulnerability and share it with the PrestaShop team.

Impact Since PrestaShop 8.1.5, any invoice can be downloaded from front-office in anonymous mode, by supplying a random securekey parameter in the url.

Patches Patched in 8.1.6

Workarounds Upgrade to 8.1.6

Thank you to Samuel Bodevin, who found this vulnerability and shared it with the PrestaShop team.

Impact Path disclosure in JavaScript variable

Patches Patch in PrestaShop 8.1.4

References https://owasp.org/www-community/attacks/FullPathDisclosure

Thanks to https://github.com/hugo-fasone

In the module "Product Catalog (CSV, Excel) Import" (simpleimportproduct) <= 6.7.0 from MyPrestaModules for PrestaShop, a guest can upload files with extensions .php.

In the module "Import/Update Bulk Product from any Csv/Excel File Pro" (baimporter) up to version 1.1.28 from Buy Addons for PrestaShop, a guest can perform SQL injection in affected versions.

In the module "So Flexibilite" (soflexibilite) from Common-Services for PrestaShop < 4.1.26, a guest (authenticated customer) can perform Cross Site Scripting (XSS) injection.

In the module "Generate barcode on invoice / delivery slip" (ecgeneratebarcode) from Ether Creation <= 1.2.0 for PrestaShop, a guest can perform SQL injection.

In the module "Survey TMA" (ecomizsurveytma) up to version 2.0.0 from Ecomiz for PrestaShop, a guest can download personal information without restriction.

Description Some event attributes are not detected by the isCleanHTML method

Impact Some modules using the isCleanHTML method could be vulnerable to xss

Patches 8.1.3, 1.7.8.11

Workarounds The best workaround is to use the HTMLPurifier library to sanitize html input coming from users. The library is already available as a dependency in the PrestaShop project. Beware though that in legacy object models, fields of HTML type will call isCleanHTML.

Reporters

Reported by Antonio Russo (@Antonio-R1 on GitHub) and Antonio Rocco Spataro (@antoniospataro on GitHub).