Critical PrestaShop 1.6 & 1.7 Vulnerabilities: Why You Should Upgrade Now

PrestaShop is a popular open-source e-commerce platform used by nearly 300,000 merchants worldwide. However, older PrestaShop 1.6 and 1.7 releases have numerous known security flaws (CVEs) – unique identifiers for publicly disclosed vulnerabilities. Attackers actively exploit these weaknesses to steal customer data, hijack stores, and plant malicious code. In this article, we outline the main CVEs affecting PrestaShop 1.6 and 1.7 (in both the core platform and official modules), along with their severity, implications, and real-world examples. The goal is to alert merchants to the risks of running an outdated PrestaShop and underscore the urgent need to upgrade to a secure version.

CVE-2018-13784 – Session Cookie Vulnerability Allows Privilege Escalation (Critical)

Severity: Critical (CVSS 3.0 score 9.8 – Network exploitable, no login required).
Affected Versions: PrestaShop 1.6.x up to 1.6.1.19 and 1.7.x up to 1.7.3.3 (fixed in 1.6.1.20 and 1.7.3.4). This vulnerability exists in the core Cookie handling mechanism of PrestaShop.

Description: PrestaShop 1.6 introduced a custom way of storing session data in a client-side cookie (instead of standard server sessions). To protect this cookie from tampering, PrestaShop added a checksum and encrypted the cookie data. Unfortunately, the implementation was flawed, allowing attackers to decrypt and forge cookies. In essence, a malicious actor could manipulate their own PrestaShop cookie (or a victim’s cookie) to read or write arbitrary session data This means an attacker could impersonate other users or even employees on the shop.

Implications: By exploiting this cookie vulnerability, an attacker could effectively hijack customer accounts or even employee (back-office) sessions. The consequences include:

• Account Takeover: Stealing any customer’s login session and performing actions as that customer (view personal details, place fraudulent orders, etc.).
• Data Theft: Reading sensitive business data stored in the session, such as customer information, order history, discount codes, and other private stats.
• Admin Access & Code Execution: In the worst case, elevating privileges to an administrator session (e.g. via forged cookies combined with other tricks like CSRF). Full admin access means the attacker can control the shop, install malicious modules, or inject code – essentially executing arbitrary code on the server.

In summary, this flaw enables partial or complete control over the website. Notably, security researchers demonstrated the exploit and released proof-of-concept code on GitHub meaning the attack method is public. Unpatched PrestaShop sites have been at risk since 2018, and skilled attackers could easily abuse this to take over stores. Merchants running 1.6.1.19 or older should assume their site is vulnerable and update immediately, as no authentication is needed for this attack (even an unregistered visitor could potentially escalate privileges).

CVE-2018-19125 – Arbitrary File Deletion (High)

Severity: High (CVSS 3.0 score ~7.5–8.0 – high impact on integrity).
Affected Versions: PrestaShop 1.6.x before 1.6.1.23 and 1.7.x before 1.7.4.4. This issue was fixed in PrestaShop 1.6.1.23 and 1.7.4.4.

Description: This is a vulnerability in the PrestaShop core that allows a remote attacker to delete files or directories on the server without authorization. Specifically, known exploits target the product images directory. An attacker can send a crafted request which tricks PrestaShop into wiping the /img folder (where product images are stored) or other critical image directories.

Implications: The ability to delete the image folder is devastating for a live shop’s integrity. All product images could be deleted by an attacker, resulting in a website full of broken image links. This not only harms the site’s appearance but can also disrupt sales – customers cannot see product photos, severely undermining the shop’s functionality and credibility. While this flaw does not directly leak data, it constitutes a form of denial of service or sabotage. An attacker (or even a malicious competitor) could exploit this to deface the store’s content or extort the owner, knowing that restoring thousands of product images from backup is time-consuming.

Real-World Example: This vulnerability was disclosed alongside a related file-upload bug (CVE-2018-19126, below) and proof-of-concepts were made public. That means attackers have the knowledge needed to automate these file deletion attacks. Even if we haven’t seen high-profile “image wiping” incidents reported, the risk is very real. It’s an easy attack to script – any site still on an affected PrestaShop version could have its product images erased in seconds. Merchants should not assume “nobody would do that”; once a vulnerability is public, opportunistic attackers often build bots to find and exploit it. The cost of being caught on an outdated version here could be days of downtime restoring images, not to mention lost sales and customer trust.

CVE-2018-19126 – Unrestricted File Upload Leading to Remote Code Execution (Critical)

Severity: Critical (allows full remote code execution on the server).
Affected Versions: PrestaShop 1.6.x before 1.6.1.23 and 1.7.x before 1.7.4.4 (fixed in 1.6.1.23 and 1.7.4.4, same release that fixed CVE-2018-19125).

Description: This is a file upload vulnerability in PrestaShop that allows attackers to upload files of dangerous types (like PHP scripts) to the server. In a properly secured shop, file uploads (for example, product images or attachments) should be restricted to safe formats and locations. However, in affected PrestaShop versions, an attacker can bypass these checks – for instance, by uploading a malicious .php file disguised as an image – and the file will be placed in a web-accessible directory. The attacker can then access this file via the browser.

Implications: Remote Code Execution (RCE) – once the malicious script is uploaded and executed, the attacker effectively runs code on your web server with the same permissions as the PrestaShop application. This is one of the most severe outcomes possible. It means the attacker can:

• Take full control of the site and server: They could install a webshell (a control panel for the server), allowing them to issue commands, modify database data, steal credentials, etc.
• Steal sensitive information: The attacker can read configuration files (to get database passwords, for example) or directly query the database, obtaining customer data, order records, and payment info stored on the server.
• Deploy malware or skimmers: They might insert malicious code into the site, such as JavaScript skimmers on checkout pages (to steal credit cards) or redirect customers to phishing pages.
• Use the server for further attacks: A compromised PrestaShop server can be used to host phishing campaigns, send spam, or pivot into the internal network.

In short, with an RCE vulnerability, the attacker “owns” your shop. This particular CVE was demonstrated by researchers using a chain of back-office weaknesses to trigger a Phar deserialization via a file upload, achieving code execution. After disclosure, it didn’t take long for exploit code to appear publicly (e.g., on Exploit-DB). Security analysts also noted active attack signatures leveraging this vulnerability, meaning it has been seen in the wild. If your store is running a version from before mid-2018 without these patches, assume that an attacker can easily plant a backdoor on it. Upgrading and patching is the only way to close this hole – there is no workaround for unrestricted file upload other than applying the official fixes.

CVE-2017-9841 – PHPUnit Library RCE in Modules (Critical, exploited in 2019–2020)

Severity: Critical (arbitrary code execution on the server).
Affected Versions: All PrestaShop versions can be affected if they have a vulnerable module. This is not a flaw in PrestaShop core itself, but in a third-party library (PHPUnit) bundled with many modules. Notably, several official PrestaShop modules included this library in certain versions – for example:

• 1-Click Upgrade (autoupgrade) v4.0.0 (beta) to 4.10.0
• Cart Abandonment Pro (pscartabandonmentpro) v2.0.1 – 2.0.2
• Faceted Search (ps_facetedsearch) v2.2.1 – 3.0.0
• Merchant Expertise (gamification) v2.1.0 – 2.3.1
• PrestaShop Checkout (ps_checkout) v1.0.8 – 1.0.9

All the above module versions included an outdated PHPUnit library which contains a known RCE flaw (CVE-2017-9841). Any PrestaShop installation – 1.6 or 1.7 – with one of these module versions was vulnerable. The issue was widespread around late 2019 and into 2020, when attackers massively exploited it.

Description: PHPUnit is a developer tool (for unit testing in PHP) that should never be present on a production webserver. Unfortunately, some modules inadvertently shipped PHPUnit in their “vendor” folder. The vulnerability in PHPUnit (public since 2017) allows an attacker to remotely execute code by making a web request to the PHPUnit test script (for example, accessing a file like /modules/ps_checkout/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php). If that file is present, the attacker can feed it malicious code to execute on the server. Essentially, a single HTTP request can deliver a payload and get the server to run it.

Implications: This is another path to complete server takeover (RCE), similar in impact to CVE-2018-19126 above. During 2019–2020, attackers actively scanned for PrestaShop sites (and other PHP apps) containing the PHPUnit files. Once found, they would run malicious commands to create backdoors or take control. PrestaShop’s team reported that many attacks either placed new PHP backdoor files or modified core files like AdminLoginController.php to insert trojan code. A common malware associated with this was “XsamXadoo”, a bot/exploit kit that left files with names like XsamXadoo_Bot.php, XsamXadoo_deface.php, 0x666.php, or f.php on infected servers. If you find any such files in your PrestaShop folder, it’s a strong indicator that your site was compromised via this vulnerability in that timeframe.

Real-World Impact: This vulnerability had major real-world impact on PrestaShop sites globally. Because it was so easy to exploit, numerous shops were hacked. In early 2020, PrestaShop issued an urgent public alert and guidance on how to find and delete phpunit folders in modules. They even had to release emergency module updates to remove PHPUnit from those official add-ons. One security firm noted that around 200 PrestaShop stores were hacked via this vector in a few months – mostly with the goal to inject JavaScript skimmers on checkout pages to steal credit cards. This was essentially a supply-chain attack: hackers exploited a vulnerability in third-party code (the modules) to compromise many shops at once.

If you are running PrestaShop 1.6 or 1.7 and have not updated your modules since 2019, there’s a chance those old PHPUnit files are still on your server. Simply upgrading PrestaShop core won’t remove them – you must update the modules or manually delete any phpunit directories. The safest route, of course, is to upgrade to the latest PrestaShop version and ensure all modules are up-to-date. This attack taught many merchants a hard lesson: keeping your store software (and its extensions) updated is critical for security.

CVE-2021-43789 – Blind SQL Injection via Product Sorting (Critical)

Severity: Critical (CVSS 3.1 score 9.8 – Network exploitable, no auth, data compromise likely)nvd.nist.gov.
Affected Versions: PrestaShop 1.7.0.0 through 1.7.8.1 (fixed in 1.7.8.2nvd.nist.gov). PrestaShop 1.6 is not directly listed for this CVE, but older versions could have similar issues or be indirectly affected via modules. This particular flaw was introduced in the 1.7 branch.

Description: The vulnerability is an SQL Injection in PrestaShop’s product listing or search functionality. Specifically, the orderBy and sortOrder parameters in product listing queries were not properly sanitizednvd.nist.gov. In practical terms, this means an attacker could craft a URL or HTTP request that includes malicious SQL code in those parameters, and the application would execute it on the database. This is a blind SQL injection – meaning the attacker might not directly see the output, but can infer success through delays or boolean results (e.g., using time-based injection techniques).

Implications: SQL injection is a very dangerous class of vulnerability because it can give an attacker direct access to your database. For an e-commerce site, the database holds customer personal data, order histories, passwords (hashes), and possibly payment information. With blind SQL injection, an attacker can systematically extract data by asking the database true/false questions or inducing time delays. Potential consequences include:

• Theft of Customer Data: The attacker can dump tables containing names, emails, addresses, and password hashes of your customersnvd.nist.gov. This could lead to fraud or large privacy breaches (and associated GDPR fines, for instance).
• Admin Account Compromise: By extracting the password hash of an employee or admin account and cracking it offline, the attacker could gain back-office access. Even if passwords are strong, the attacker might also use SQLi to directly reset an admin password or create a new admin user in the database.
• Modify Store Data: Depending on the injection, attackers might also alter data – for example, change product prices, modify orders, or even insert a fake admin account. The NVD entry suggests high Confidentiality and Integrity impactnvd.nist.gov, meaning data could be both stolen and changed.

In one scenario, a hacker could combine this flaw with others – for instance, using SQL injection to enable certain unsafe configurations. This is exactly what happened in the next case (2022’s attack) where an SQL injection allowed turning on a hidden feature that led to code execution. While by itself CVE-2021-43789 “only” grants database access, remember that database access can often be a stepping stone to full server control.

Real-World Notes: This vulnerability was discovered and fixed by the PrestaShop team before attackers widely exploited it, as far as public reports indicate. It was patched in version 1.7.8.2 (late 2021)nvd.nist.gov. However, given its critical severity, we must assume that any site running 1.7.8.1 or older could be a target. Tools like sqlmap can automate extraction of data via such blind SQLi. If your store is in this version range, it’s essential to update to 1.7.8.2+ (or the latest 8.x) to close this hole. Even though we don’t have headlines of a breach solely via this CVE, the lack of news doesn’t mean lack of danger – many breaches are never publicly disclosed. The safest approach is to patch proactively.

CVE-2022-36408 (aka “PrestaShop SQL Injection RCE Chain”) – PrestaShop 1.6/1.7 Zero-Day Exploited in 2022 (Critical)

Severity: Critical. This was a zero-day exploit actively used by hackers to perform remote code execution on PrestaShop sites in mid-2022.
Affected Versions: PrestaShop 1.6.0.10 and above, up to 1.7.8.6 are vulnerable if a certain module or combination of vulnerabilities is present. Notably, even PrestaShop 1.7.8.2+ could be exploited if they were running a vulnerable module (the known example is the Wishlist (blockwishlist) module v2.0.0 – 2.1.0). In essence, almost any PrestaShop 1.6 or 1.7 installation not fully up-to-date with patches and module updates could be hit by this chain. The issue was mitigated in PrestaShop 1.7.8.7 with a specific fix to break the attack sequence.

Description: This complex attack combined a SQL injection (likely in a module) with clever abuse of a legacy feature in PrestaShop. Attackers discovered they could inject data into the database in such a way as to enable PrestaShop’s MySQL Smarty cache – a rarely used feature that, when activated, can execute arbitrary code. Here’s how the attack worked, in simplified steps:

1. SQL Injection to plant payload: The attacker finds a vulnerable parameter (for example, the Wishlist module’s unsecured parameter) and sends a specially crafted POST request with malicious SQL. This SQL likely turns on the Smarty cache to use a MySQL table and then injects a rogue template payload into that table.
2. Trigger code execution: Immediately after, the attacker sends a GET request to the homepage (with no parameters). This causes PrestaShop to write a PHP file (the payload) to the web root named blm.php (the name observed in attacks). Essentially, the malicious data from step 1 gets converted into a PHP file on the server – a webshell.
3. Launch the webshell: The attacker then sends a GET request to blm.php. Now they have arbitrary code execution on the server with the privileges of the web user. The chain is complete – from SQL injection to RCE.

PrestaShop’s investigation noted that once attackers have this access, they typically inject a fake payment form into the checkout page (via the webshell). This is a classic Magecart-style skimmer: customers think they are entering their credit card into a normal form, but it’s being sent to the attackers. The legitimate payment may fail or be silently passed through, but the attacker now has the card details. In July 2022, multiple shop owners found their customers’ payment info was stolen in this way.

Implications: This vulnerability chain is as bad as it gets: attackers can execute any code on the server and have full control. The immediate goal observed was credit card theft, but with RCE access attackers could just as easily harvest all customer data, install ransomware, or pivot to attack the hosting server. The fact that this was actively exploited as a zero-day means many stores were hacked before a patch was available. PrestaShop maintainers rushed out version 1.7.8.7 as a security fix and published advisories on how to detect and mitigate the attack pattern. They recommended manually disabling the Smarty cache feature by editing files, as a temporary measure.

Real-World Impact: This was a headline-making incident. Prestashop’s team itself “strongly urged” all users to upgrade as soon as possible, and security news outlets reported on the wave of attacks. Security firms confirmed that cybercriminals were using this exploit to implant payment skimmers on numerous PrestaShop sites. For example, Malwarebytes and SOCRadar noted that shops on versions 1.6.x and 1.7.x (even some fairly recent 1.7.8 builds) were hit, and many victims only realized after customers complained of card fraud. The attack was stealthy too – after injecting their code, attackers would often delete the blm.php file and other traces to evade detection. If your store was running an outdated PrestaShop in 2022 and you haven’t thoroughly audited it, it could have been compromised without your knowledge. Signs of this attack include the presence of blm.php (even briefly), unknown modifications in payment templates, or unusual log patterns (PrestaShop shared an example log snippet to help identify the attack sequence.

In summary, CVE-2022-36408 (and related identifiers like CVE-2022-31101) represent a critical wake-up call. Even a fully patched PrestaShop core (1.7.8.5 or .6 at the time) was not safe if a module was vulnerable – illustrating the importance of keeping modules updated too. This exploit chain being a zero-day meant attackers were one step ahead until the emergency patch. Merchants who upgraded promptly were able to secure their shops, but those who delayed may have unknowingly exposed their customers to theft.

Other Notable Vulnerabilities (XSS, CSRF, etc.)

While the CVEs above are some of the most severe, it’s worth noting that dozens of other vulnerabilities have affected PrestaShop 1.6 and 1.7 over the years. Many were less critical (or easier to mitigate) but still pose risks, especially if chained with other attacks or used for fraud. For example:

• Cross-Site Scripting (XSS) vulnerabilities: PrestaShop had multiple XSS flaws in both core and modules. One early example was CVE-2015-1175, an XSS in the blocklayered module (layered navigation) for PrestaShop 1.6.0.9 and earliernvd.nist.gov. It allowed attackers to inject malicious JavaScript via blocklayered-ajax.php. More recently, CVE-2020-15161 disclosed an XSS in the contact form affecting versions 1.6.0.4 through 1.7.6.8. XSS bugs let attackers hijack customer sessions or perform actions on behalf of users/admins by tricking them into clicking a link. While XSS generally requires some user interaction (hence often rated moderate severity), it can be a stepping stone to full compromise (for instance, stealing an admin’s cookie to take over their account).
• CSV Formula Injection: A peculiar bug (CVE-2021-21302) was found in PrestaShop <1.7.2 where exported CSV files could contain malicious formulas. If an admin opened such CSV in Excel, it could run code on their machinenvd.nist.gov. This is a more niche vulnerability (requiring social engineering of the admin), but it highlights the breadth of issues patched in newer versions.
• Brute-force / Authentication issues: Some patches addressed weaknesses in password handling and admin login. For instance, PrestaShop 1.7.6.5 fixed an issue where the admin login page behaved differently for existing vs. non-existing usernames (making user enumeration possible). While not as dangerous as RCE, such issues could aid an attacker’s reconnaissance.

The key takeaway is that security holes range from critical RCEs to minor info leaks, and attackers often combine them. A less-severe bug (like an XSS or CSRF) can become critical if used in tandem with another vulnerability. Therefore, it’s important not to ignore “medium” severity issues in your shop – patching everything is the best policy.

Conclusion: Upgrade Your PrestaShop – Your Business Depends on It

As we have seen, PrestaShop 1.6 and 1.7 have been the target of numerous serious CVEs over the past several years. Some allowed attackers to completely take over stores and servers, leading to stolen customer data, financial loss, and reputational damage. The real-world attacks – from mass credit card skimming in 2022 to widespread bot exploits in 2020 – underscore that these are not just theoretical risks. If you are running an outdated PrestaShop, it’s not a question of “if” but “when” a malicious actor will attempt to exploit your site.

Upgrading your store to the latest version is not just a technical preference, but a business necessity. PrestaShop 1.6 reached end-of-life years ago – it no longer receives any security updates. PrestaShop 1.7, while more recent, must be kept at its latest patch level (1.7.8.x) to be safe; better yet, consider moving to the new 8.x branch, which continues where 1.7 left off and receives active support. Each new release fixes known vulnerabilities – for example, 1.7.8.7 was released solely to address the 2022 attack chainsocradar.io. By staying on old versions, you are effectively leaving open doors for hackers that are well-documented in the CVE databases.

What should merchants do? First and foremost, plan and execute an upgrade of your PrestaShop to a secure version. This might involve a significant update (especially from 1.6 to 8.x, which is a major migration), but the cost of not doing it can be far higher (consider the fallout of a breach – lost sales, fines, lawsuits, and rebuilding trust). Alongside the core update, update all your modules to their latest versions, especially official modules – as we saw, outdated modules can introduce critical holes. Remove any modules or code components you no longer use, especially if they’re not maintained.

It’s also wise to implement some defense-in-depth measures:

• Install a web application firewall (WAF) or security module to filter malicious requests (this can block common exploit payloads for SQLi, XSS, etc.).
• Use strong, unique passwords for your admin accounts and enable two-factor authentication if possible. Many attacks start by exploiting weak creds or known default URLs – don’t make it easy.
• Regularly back up your site and database. In case of a compromise like image deletion or defacement, a recent backup can drastically cut down recovery time.
• Monitor your files and logs. If you suddenly see unknown PHP files (like blm.php or `XsamXadoo_*.php) or unusual log entries (e.g. strange POST requests followed by GET to root), investigate immediately. Early detection can limit damage.

In conclusion, running an outdated PrestaShop is a high-stakes gamble. The CVEs we’ve discussed show that attackers have a variety of tools to breach a vulnerable shop – from cookie forgery and SQL injection to full remote code execution. Upgrading your PrestaShop installation is the single most effective way to protect your business and customers. It might be an investment of time and resources, but it pays off immensely in security, stability, and peace of mind. Don’t wait for your store to make headlines as the next victim of a breach – act now and keep your PrestaShop updated. Your customers trust you with their data and payments; ensuring your platform is secure is a crucial part of upholding that trust. Stay safe and successful by staying current!