On July 22, 2022, a warning from PrestaShop arrived regarding a vulnerability that allows an attacker to take control of your ecommerce based on this CMS, at present all the dynamics of this newly discovered exploit are not yet clear. It should be noted immediately that the vulnerability does not seem to affect version and later versions. But if your version is still a 1.6 or an older 1.7 you need to secure it.

How the attack works

The precise dynamics are still under scrutiny, but the attack requires ecommerce to be vulnerable to SQL injection exploits. Attackers target stores that have non-bypassing modules or already known vulnerabilities. Including the Wishlist module (blockwishlist). It is important to point out that the attack exploits a vulnerability linked to the Smarty Cache saved in MySQL, an option rarely activated as the advantages over the cache on the file system are often minimal if not worse.

You can check if this cache is active by going to Advanced Parameters> Performance

The fact that it is not active does not ensure that it is safe, as it seems that attackers are able to activate it by exploiting other vulnerabilities in third-party modules. However, I do not believe that the attack carried out in the first instance via bot, then goes to erase the traces of its passage. So if you find the entry disabled most likely you have not been compromised, however after a similar exploit a general check is a must.

The procedure detected is the following :

  • A POST attack is sent to check if the target is vulnerable.
  • Immediately afterwards a parameterless GET request is sent to the home, which results in a PHP file called blm.php in the root of our PrestaShop installation.
  • The attacker then sends requests to the created file and perform operations directly on our ecommerce.

One of the activities detected after the criminals took over our shop is the front-end installation of a fake payment form. So as to steal credit card data from our customers. Here it should be emphasized that in Europe with 3D Secure these attacks are less devastating. However, this can only be one of the ways used, attackers can use a name other than blm.php for the file and insert malicious code elsewhere and with different purposes. If the attack is successful, they can also erase their tracks.

The problem is serious, but the mode is only successful in particular situations. However, you need to be safe, to be sure you are not vulnerable.

How to get safe?

First of all, as mentioned, the attack exploits the smarty cache on mysql, if you use this mode go to the cache on the file system, then immediately on Advanced Parameters> Performance , already now that you read this article. Then while waiting for an official PATCH, modify the config / smarty.config.inc.php file as recommended in the PrestaShop notice. It involves removing or commenting on a small piece of code, this piece of code is useless if you do not use the cache on mysql, so the change will not need to restore it in the future.

This code can be found in version 1.6 on line 40-43 and in version 1.7 on line 43-46.

Just comment this block then:

Once done, your ecommerce is safe from this attack, but it is not safe from other attacks and it does not mean that it has not already been compromised.

I go back to recommending to always keep all modules updated, uninstall the unused ones and update PrestaShop, this exploit is not the only one there are more serious and minor ones that afflict many dated versions. Here you can see the known vulnerabilities:


It should be noted that this applies to all CMS and Software, even WordPress, Joomla, Magento etc .. a secure system is an updated one.

How do you check if your PrestaShop is compromised?

This type of attack makes it more difficult to tell if you are a victim, once you have taken control as mentioned, the criminals can erase their tracks leaving a well-hidden backdoor and modifications to module files or the CMS core. The dynamics are similar to the vulnerability affecting PHPUnit (CVE-2017-9841). In this specific case, not finding the blm.php file in the root or in the logs is no guarantee of security that you have not already been hacked.

So yes a check you can do it, but I recommend checking the recently modified or added files, which is possible to do via SSH. A very useful thing is to check if there is any encrypted or encoded code, for example in base64: whose presence is always suspicious. Keep in mind that for modules purchased on Prestashop Addons it is forbidden to use these systems, so a module that uses them would not be present in the catalog.

Some tools present on cPanel and Plesk can be very useful in identifying any infected files, for example ImunifyAV .

However, I remember the SSH access to your Hosting allows you to use the find command to get all the recently modified files, filtering them by extension, then looking for changes mainly to .php and .tpl files in the case of PrestaShop. There are also here Server side tools for cPanel and Plesk that allow you to monitor changes to certain files / folders.

Author: Loris Modena


Per Ind Loris Modena , owner of Arte e Informatica , he began working in the IT sector in 1989 as a system engineer in charge of the maintenance and installation of IT systems. He started programming for the web in 1997 dealing with CGI programming in PERL and then moving on to programming in PHP and JavaScript. In this period he approaches the Open source world and the management of Linux servers.

Product added to wishlist