Attackers are using a vulnerability in a popular dependency used by modules to take control of PrestaShop sites. For details, please read the entire article.

What’s happening

It has come to our attention that attackers are exploiting a vulnerability in PHPUnit to perform arbitrary code execution in servers running PrestaShop websites. The issue is fixed in PHPUnit 7.5.19 and 8.5.1. To our knowledge, all previous versions are vulnerable, at least for certain server configurations.

How to tell if you are impacted

Connect to your shop via FTP or shell access, and look at the “vendor” directory in the main prestashop folder and inside each one of your modules:

  • <prestashop_directory>/vendor
  • <prestashop_directory>/modules/<module_name>/vendor

If there’s a directory called “phpunit” inside the aforementioned directories, your shop may be vulnerable.

Warning: don’t touch anything else or you might break your shop Other files and folders (e.g /vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit/ or .xml files) are safe, do not delete them.

What to do if you are impacted

PHPUnit is a development library and is not needed for the normal function of your site, so you can simply delete all the “phpunit” directories found above. This should help close the attack vector.

On a Linux server, this can be performed quickly using the following bash command line from shop’s modules/ folder:

find . -type d -name "phpunit" -exec rm -rf {} \;

This command requires the relevant user rights.

You can also delete “phpunit” folders manually via FTP.

Be aware that even if you perform this cleanup, your shop may have already been compromised.

According to our analysis, most attackers either place new files in the filesystem or modify existing files, like AdminLoginController.php.

Here’s a non-exhaustive list of known malicious files that may indicate a compromised shop:

  • XsamXadoo_Bot.php
  • XsamXadoo_deface.php
  • 0x666.php
  • f.php
  • Xsam_Xadoo.html

You can check if Core PrestaShop files have been modified by looking at the “List of changed files” section at the bottom of the “Advanced Parameters > Information” page in your Back Office. However, this check may not be enough since your site may have been compromised otherwise.

If your shop has been compromised or if you think it has been compromised:

  • Carefully check that the attacker didn’t leave any file on your server, e.g hidden in the middle of your shop files and/or contact an expert to do it for you.
  • Consider asking all users of your shop(s) to change their password, which includes back office users but also customer accounts. Make sure no compromised file is still present in your shop before.

If you think your site has been hacked, contact a security expert.

PrestaShop modules impacted by this vulnerability

Some modules are impacted:

  • 1-Click Upgrade (autoupgrade): versions 4.0 beta and later
  • Cart Abandonment Pro (pscartabandonmentpro): versions 2.0.1~2.0.2
  • Faceted Search (ps_facetedsearch): versions 2.2.1~3.0.0
  • Merchant Expertise (gamification): versions 2.1.0 and later
  • PrestaShop Checkout (ps_checkout): versions 1.0.8~1.0.9

We have released updated versions for these modules which completely remove the related library from their own dependencies:

  • 1-Click upgrade: v4.10.1
  • Cart Abandonment Pro: v2.0.10
  • Faceted Search: v3.4.1
  • Merchant Expertise: v2.3.2
  • PrestaShop Checkout: v1.2.9

Be aware that if you installed in the past an impacted version of those modules, PHPUnit files may still be present on your server. Only these newly released versions make sure PHPUnit is no longer present in their own vendor directory.

Modules and themes by other vendors may be vulnerable as well. Expect updates to follow soon.

Additional information

A very special thank you to Francis Ladeuil who first reported this issue.

We have also published a post incident analysis that you might want to read.

FAQ

You can find answers to some frequent questions asked these past days.

Which PrestaShop versions are affected? All versions.
The security vulnerability impacts modules, so it can affect any version using vulnerable modules.

A shop powered by PS 1.6, for example, can also be vulnerable if you install a module containing the PHPUnit library.
Should I also delete the Symfony related folder /vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit/? No.
Only the folders <prestashop_directory>/vendor and <prestashop_directory>/modules/<module_name>/vendor can contain the vulnerable library PHPUnit. The folder /vendor/symfony/symfony/src/Symfony/Bridge/PhpUnit/ is safe do not delete it.
Do I need to upgrade my 1.6 to 1.7 to be safe? No.
To secure you store follow the instructions.

However, we always recommend using the latest version as each new version includes bug fixes and security improvements. PrestaShop 1.6 is no longer officially maintained since July 2019.
I can't find the vendor directory in PrestaShop 1.6, where is it? On PS 1.6 you do not need to check the folder <prestashop_directory>/vendor but you need to check all modules folders like this: <prestashop_directory>/modules/<module_name>/vendor
Will PrestaShop release a module to fix the problem? No.
Modules cannot replace a security expert. A module can fix this particular vulnerability, but it cannot effectively clean up a site if it has been breached.

Please contact a security expert if you are not sure your shop is safe.
My shop has been hacked, what should I do? Please follow the instructions detailed in the post and contact a security expert.
Are only PrestaShop modules vulnerable? No.
Modules and themes by other vendors may be vulnerable as well. Expect updates to follow soon.
Would it be correct to say, that if <prestashop_directory>/modules/<module_name>/vendor has 700 permissions, then it could not be used to exploit vulnerability described in this article? Changing the permission settings on folders will not change anything: when a visitor comes to your website, the website is executed by the web server user(s).

A possible working protection is to filter the access to those folders from the web with a .htaccess rule, or in a firewall.