SQL injection vulnerability in the Payplug (payplug) module for PrestaShop, in versions 3.6.0, 3.6.1, 3.6.2, 3.6.3, 3.7.0 and 3.7.1, allows remote attackers to execute arbitrary SQL commands via the ajax.php front controller.


  • CVE ID: CVE-2023-30153
  • Published at: 2023-07-18
  • Advisory source: Friends-Of-Presta.org
  • Platform: PrestaShop
  • Product: payplug
  • Impacted release: 3.6.0,3.6.1,3.6.2,3.6.3,3.7.0,3.7.1 (fixed in 3.8.2)
  • Product author: Payplug
  • Weakness: CWE-89
  • Severity: critical (9.8)


In the Payplug (payplug) module for PrestaShop, in versions 3.6.0, 3.6.1, 3.6.2, 3.6.3, 3.7.0 and 3.7.1 (fixed in 3.8.2), an HTTP request can be manipulated using cart_id GET parameter, in the /module/payplug/ajax FrontController endpoint, enabling a remote attacker to perform an SQL injection. The issue is fixed in version 3.8.2, published on July 2022. At our knowledge, there has been no public release between 3.7.1 and 3.8.2.

PayPlug communicated directly with their customers several times, informing them of the vulnerability and requesting that they upgrade the module to the latest known version. They also took action on their side to prevent customers from using a vulnerable version, requiring them to upgrade the version in order to continue using their service.

This exploit uses a PrestaShop front controller and most attackers can conceal the module controller’s path during the exploit so you will never know within your conventional frontend logs that it exploits this vulnerability. You will only see “POST /” inside your conventional frontend logs. Activating the AuditEngine of mod_security (or similar) is the only way to get data to confirm this exploit.

CVSS base metrics

  • Attack vector: network
  • Attack complexity: low
  • Privilege required: none
  • User interaction: none
  • Scope: unchanged
  • Confidentiality: high
  • Integrity: high
  • Availability: high

Vector string: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Possible malicious usage

  • Obtain admin access
  • Remove data from the associated PrestaShop
  • Copy/paste data from sensitive tables to FRONT to expose tokens and unlock admins’ ajax scripts
  • Rewrite SMTP settings to hijack emails


IMPORTANT: PayPlug is now preventing customers using outdated versions from accessing their service. As a result, simply patching the module will not be enough to restore the service for those using older versions. An upgrade of the module is therefore necessary.

--- a/controllers/front/ajax.php
+++ b/controllers/front/ajax.php
@@ -243,7 +243,7 @@ class PayplugAjaxModuleFrontController extends ModuleFrontController
                     ->from(_DB_PREFIX_ . 'payplug_payment')
-                    ->where('id_cart = ' . $cart_id)
+                    ->where('id_cart = ' . (int)$cart_id)
                 if ($payment_id != $current_payment_id) {

Other recommandations

  • It’s highly recommended to upgrade the module to the latest version or to delete the module if unused.
    • To help improve the security of your PrestaShop installation, we recommend upgrading to the latest version. One of the benefits of upgrading is that it will disable the use of multiquery executions (separated by semicolons). However, please be aware that this will not protect your shop against SQL injection attacks that use the UNION clause to steal data. Additionally, it’s important to note that PrestaShop includes a function called pSQL, which includes a strip_tags function. This helps protect your shop against Stored XSS (also known as XSS T2) of Category 1. If a pSQL function is missing, it could potentially expose your project to critical Stored XSS vulnerabilities due to edge cases. Therefore, it’s crucial to ensure that all relevant functions are properly implemented and used consistently throughout your project.
  • Change the default database prefix ps_ by a new longer arbitrary prefix. Nevertheless, be warned that this is useless against blackhats with DBA senior skills because of a design vulnerability in DBMS
  • Activate OWASP 942’s rules on your WAF (Web application firewall), be warned that you will probably break your backoffice and you will need to pre-configure some bypasses against these set of rules.


Date Action
2022-09-10 Discovery of the vulnerability by Profileo
2022-09-10 Contacting the editor to disclose the vulnerability
2022-09-16 The editor confirmed the vulnerability, already fixed in version 3.8.2
2023-04-02 Contacting the editor to suggest a publication of the security advisory on their hand
2023-04-11 Meeting with the editor to discuss process of disclosing the vulnerability (the editor informed impacted clients individually)
2023-04-21 Obtaining the CVE ID from mitre
2023-05-05 Contacting the editor again to suggest the publication of the security advisory on their hand
2023-05-12 Contacting the editor to request an update about publication
2023-05-22 Response from the editor informing us that the publication will not be done on their hand (the editor informed their clients individually and is now blocking old versions of the module from accessing the service)
2023-06-01 Informing the editor of upcoming publication
2023-07-06 Notify Payplug of the upcoming publication on July 18, asking for feedback before publication
2023-07-18 Publication of this security advisory