PrestaShop Stores in Danger: Serious Flaws Exposed in Versions 1.6 and 1.7

Thousands of online stores still operate on outdated versions of PrestaShop 1.6 and 1.7 – and face serious security risks. Documented critical vulnerabilities (CVEs) allow from complete website invasion until customer data theft. This alert exposes the main known flaws in these versions, in clear terms, so that retailers understand the real danger and take urgent action. By continuing to use outdated systems, online merchants risk losing sensitive information, sales, and even their brand reputation.

Main Vulnerabilities (CVEs) in PrestaShop 1.6 and 1.7

Below we list the main officially documented CVEs – in sources such as the NVD (National Vulnerability Database) and PrestaShop announcements – that affect versions 1.6.x and 1.7.x of PrestaShop. We include failures in both platform core as in native or widely used modules. For each vulnerability, we indicate the impacted versions, severity, technical description, forms of exploitation/impact and real examples of attacks (if any):

CVE-2018-19126 – Remote Code Execution via Malicious File Upload

Affected versions: PrestaShop 1.6.x (before 1.6.1.23) and 1.7.x (before 1.7.4.4).
Gravity: Criticism (CVSS 9.8).
Technical description: Fault that allows upload files without type restrictions (CWE-434). An attacker could send a malicious file – for example, disguised as an image – and execute arbitrary code on the server. The vulnerability is related to holes in the back-office file manager, exploiting the lack of adequate validation when dealing with uploads.
Possible exploitation/impact: For being remote and does not require authentication (AC:L/PR:N), any malicious person could take complete control of the store. This includes installing backdoors, stealing databases, or changing the website at will. In practice, the attacker obtains the same privileges as the web server, being able to add administrative accounts, modify orders or insert malware into pages.
Real example: While there is no specific publicly disclosed case of this flaw in 2018, the nature of the vulnerability is similar to other exploits where the hacker sends an embedded PHP file as an image and then runs it on the website. Once the malicious file is installed, the attacker could, for example, display fraudulent content or redirect customers to phishing pages.

CVE-2018-19125 – Image Directory Deletion (Content Destruction)

Affected versions: PrestaShop 1.6.x < 1.6.1.23; 1.7.x < 1.7.4.4.
Gravity: High (CVSS 7.5).
Technical description: A vulnerability that allows a remote attacker delete an entire image directory from the store. This is a path validation flaw (path traversal), where manipulated entries can escape the allowed directory and remove critical files (such as product photos).
Possible exploitation/impact: No login required and it is simple to execute, which means that an attacker can, in a few seconds, delete product images or banners from the website. This causes immediate loss to the operation: the store is visually broken (missing images), damaging the customer experience and trust in the store. Although it does not provide access to confidential data, this destruction of content results in loss of sales (customers cannot see products) and recovery work to restore backups.
Real example: There is no public record of a specific attack using this CVE, but it’s easy to imagine the damage – a rogue competitor or automated attacker could simply “delete” photos of your products. Without images, your virtual storefront remains closed until you restore everything, potentially causing hours or days of disruption.

CVE-2018-19124 – Arbitrary Writing to Image Files (Windows)

Affected versions: PrestaShop 1.6.x < 1.6.1.23; 1.7.x < 1.7.4.4 when hosted on Windows servers.
Gravity: High (CVSS 7.5).
Technical description: Due to a flaw in path sanitization in a Windows environment, PrestaShop allowed remote attackers overwrite arbitrary image files on the server. In summary, through manipulated input, a hacker could write data to files within the store’s images folder, exploiting directory differences in Windows (e.g. use of C:\ or ..\).
Possible exploitation/impact: An attacker could change website images – for example, changing the store logo with another image (even offensive content or malicious advertising) – affecting the visual integrity and credibility of e-commerce. Furthermore, this flaw could be combined with other techniques (such as including code in image metadata) to prepare the ground for more complex attacks. Although do not allow direct code execution in itself, it is an open door for digital vandalism.
Real example: Like the CVE above, an isolated case has not been widely reported, but think about the consequences: a malicious actor could place an inappropriate image instead of product photos or banners – for example, a “Hacked Site” warning or illegal content – causing great reputational damage until the retailer discovers and removes the content.

CVE-2019-13461 – Customer Data Exposure via Insecure Direct Referral

Affected versions: PrestaShop 1.7.x (before 1.7.6.0 RC2, fixed in final 1.7.6.0).
Gravity: High (CVSS 7.5).
Technical description: IDOR-type vulnerability (Insecure Direct Object Reference). The parameters id_address_delivery e id_address_invoice in the checkout process could be manipulated to access address information that do not belong to the authenticated user, due to easy-to-guess values. In other words, by changing an ID in the request, an attacker could view or even select another customer’s delivery/billing address.
Possible exploitation/impact: Personal data (names, addresses, zip code, telephone number) of customers could be leaked. A competitor or criminal could collect this information for malicious purposes – such as targeted phishing campaigns or data sales. Although it does not provide administrative access, this exposure seriously violates customers’ privacy (breach of LGPD/GDPR) and undermines trust in the store.
Real example: This failure was documented in the bug “pull” data from other clients into the API. Imagine a forum where attackers exchange this leaked information – your e-commerce could have customer addresses and contacts circulating without authorization.

CVE-2020-15160 – Blind SQL Injection in Product Registration (Back-office)

Affected versions: PrestaShop 1.7.5.0 to 1.7.6.7 (patched in 1.7.6.8).
Gravity: Criticism (CVSS 9.8).
Technical description: A failure of SQL Injection in the administrative panel, specifically on the product edit page, “location” parameter. Malicious data input not properly filtered allowed arbitrary SQL commands to be executed against the store’s database. This is an injection “blind”, that is, the attacker does not directly see the result, but can infer information through behavior (e.g. response times).
Possible exploitation/impact: Although it occurs in the back-office, the flaw could possibly be exploited without authentication (CVSS indicates PR:N), perhaps through improperly exposed functionality. A remote agent could extract confidential data of the bank (client list, password hashes, prices) or even take down the service running heavy queries (e.g. via SQL Sleep command). In tests, it was demonstrated that it was possible, for example, to obtain sensitive information or interrupt the MySQL database through this breach. Any data integrity is compromised – the attacker could change prices, insert malicious content into the bank, or stealthily create administrative users.
Real example: This vulnerability was revealed in 2020 and fortunately fixed quickly. A hypothetical attack would be someone sending specially crafted requests to the vulnerable endpoint; without giving any visual alert, the store database starts to “leak” information to the attacker or goes into slowdown/suspension. To the retailer, it could appear to be a simple temporary crash, while in fact data was being extracted.

CVE-2020-15161 – Cross-Site Scripting in the Contact Form

Affected versions: PrestaShop 1.6.0.4 to 1.7.6.7 (patched in 1.7.6.8).
Gravity: Average (stored/reflected XSS).
Technical description: XSS (Cross Script Execution) failure in PrestaShop native contact form. Due to insufficient sanitization of form fields, an attacker was able to inject malicious JavaScript code when sending a contact message. This code could then be executed in an administrator or employee’s browser when viewing the message on the dashboard, or even reflected back to the end user in certain circumstances.
Possible exploitation/impact: XSS itself does not give server control, but it does allow hijack sessions or display false content for users. For example, a hacker could send a “Contact Us” message containing a hidden script; When the retailer opened this message in the back-office, the script could steal the admin session cookie or change page views. With the admin cookie, the attacker could then take over administrator account and perform malicious actions (a common attack escalation via XSS). Alternatively, the script could redirect customers to external pages or display phishing pop-ups.
Real example: This vulnerability was widely announced at the time (2020) for retailers to update. A publicized exploit showed the injection of <script> in the subject field of the contact; When the admin read the message, his browser executed the script that, for example, sent his session to the attacker. In short, although less dramatic than an SQLi or RCE, an XSS like this serves as a gateway to completely compromise the store if the attacker is skilled.

CVE-2020-26248 – SQL Injection in the Product Comments Module

Affected versions: Module productcomments PrestaShop official version 4.0.0 to 4.2.0 (fixed in 4.2.1). (This module is often used to allow customer reviews/comments on products.)
Gravity: High (CVSS ~8.2; significant impact on confidentiality and availability).
Technical description: A failure of Blind SQL Injection in the comments module allowed numeric parameters (such as product ID) to be exploited to enter SQL commands. Validation was insufficient – for example, the module expected a number but did not sanitize it properly, allowing query snippets to be injected. The result could be data extraction or changes to the database.
Possible exploitation/impact: Any user (even unauthenticated, as product comments can be public depending on the configuration) could trigger the failure via forged requests. Impacts include information theft (e.g. read user tables, inventory, etc.) or denial of service of the database (the attacker can execute commands that crash MySQL). Ultimately, the vulnerable module acting as a gateway could lead to complete control of the system if combined with other flaws or obtained credentials.
Real example: This loophole was disclosed with proof of concept in 2020/2021. A likely attack vector would be a bot accessing the public URL of the comment module with malicious parameters (as shown in published exploits). In testing, researchers demonstrated extracting data and even bringing down the database service through this vulnerability. Stores that did not update the module after 2020 may have been silently exploited – a possible symptom would be the website becoming unstable for no apparent reason, or confidential information appearing leaked onto the internet.

CVE-2022-31101 – SQL Injection in the Wishlist Module (BlockWishlist)

Affected versions: Module blockwishlist (wish list) official, versions 2.0.0 to 2.1.0 (fixed in 2.1.1).
Gravity: High (CVSS 8.8).
Technical description: SQL injection vulnerability that can be exploited by a authenticated client in the store (you just need to have a common account). When consulting your wish lists, sorting parameters and filters were not properly sanitized, making it possible to inject SQL commands into the module query. This module adds wishlist functionality to the front-end, and requests for this functionality could load malicious SQL code.
Possible exploitation/impact: A malicious user (or an attacker who creates an account on the store) could leak sensitive bank data – for example, information from other customers, hidden prices, etc. – or even corrupt information when modifying queries. Despite requiring login, creating an account is trivial on any store, so essentially the flaw is open to anyone. In addition to data theft, this breach gained notoriety as it served as a initial vector for more complex attacks (see the 2022 exploit chain case below).
Real example: In July 2022, PrestaShop investigations identified that vulnerable versions of blockwishlist were being actively exploited as part of a larger chain attack. Hackers took advantage of stores that did not update this module to inject SQL and prepare the ground for a complete takeover (described in the next vulnerability). Therefore, a simple outdated wish list has become the gateway for attackers to steal payment data.

CVE-2022-31181 (CVE-2022-36408) – Exploit Chain: SQL Injection Leads to Remote Execution (Case XsamXadoo)

Affected versions: PrestaShop 1.6.0.10 to 1.7.8.6 (patched in 1.7.8.7). Note: PrestaShop >= 1.7.8.2 theoretically protected, unless using a vulnerable module, as per advisory.
Gravity: Critical (CVSS 9.8 – remote exploitation without authentication).
Technical description: It is a complex chain vulnerability discovered in 2022, explored as zero-day. The attack combines SQL injection with a PrestaShop feature called MySQL Smarty cache. In simple terms: first the attacker injects data via SQL (taking advantage of some loophole, e.g. a vulnerable module like blockwishlist mentioned) and then, through a specific sequence of requests, you can make PrestaShop generate and save a malicious PHP file on the server. This file (typically called blm.php) is written to the root of the website and is then executed remotely by the attacker. Thus, an initially “only” SQL Injection vulnerability is chained into a complete Remote Code Execution.
Possible exploitation/impact: The consequence is that the attacker takes full control of the store, without needing credentials. With the malicious file deployed, it can carry out any command on the server. In fact, the real case observed was of criminals using this flaw to inject fake payment forms in the committed store. Thus, when customers made purchases, their credit card data was diverted to the attackers, while the legitimate purchase might not even be completed. In addition to direct financial theft from customers (who think they are paying the store while handing over data to fraudsters), the hacker could access personal information, order history and possibly install backdoors to maintain persistent access. Yes, without exaggeration, one of the most serious failures in the history of PrestaShop, due to the ease of exploration and high value of the data obtained.
Real example: This attack was widely reported in July 2022, with PrestaShop releasing urgent advisories. Researchers dubbed it XsamXadoo and observed that several sites were already compromised even before the patch. In a typical attack, in a matter of seconds: (1) the criminal sends a POST request to an endpoint vulnerable to SQL; (2) then accesses the home page to trigger the malicious payload, which generates the file blm.php hiddenly; (3) then when you call this file you get a gateway to execute commands. In affected stores, a code would soon appear inserted at checkout simulating a payment form identical to the original, but controlled by the attacker – every customer who filled in their payment details there was, in fact, sending the information directly to the criminals. This real case vividly illustrates how outdated stores can be attacked en masse, resulting in the loss of customers’ money, the need to refund amounts, damage to the store’s image and possible involvement of authorities (as sensitive data was compromised).

(Note: In addition to those listed, other less critical CVEs were reported during this period – for example, CVE-2020-15080, which improperly exposed configuration files – but we focus here on the flaws with the greatest practical impact.)

Why There Are Still Thousands of Stores on Display

Even with all these vulnerabilities known and fixed in later versions, many stores still operate on vulnerable 1.6 or 1.7 versions. The reasons vary, but include everything from lack of knowledge of the risks until complexity of migrating a store with many modules and customizations. See some factors and consequences:

Lack of Update: PrestaShop 1.6 reached end of life (EOL) years ago, and the 1.7 series has already had several security updates. Retailers who did not apply patches or did not migrate remain with an “open door” for hackers. The above failures are publicly documented – i.e. automated attack tools have already cataloged these breaches and actively explore them. An outdated website can be found by scanning bots within hours of going online.
Outdated Modules: Even those who have kept the core updated sometimes forget to update modules. Many native modules (such as those mentioned Product Comments e Block Wishlist) or popular have had security patches. If the store runs an old version of the module, all it takes is for a malicious client to interact with the functionality (send a comment, move the wishlist) to trigger the attack. It’s literally inviting the thief in.
Migration Costs and Complexity: Some merchants are hesitant to migrate from 1.6/1.7 to PrestaShop 8/9 for fear of incompatible themes or custom functions. However, maintaining an insecure system comes with a huge hidden cost: a single hack can compromise all business data. The financial loss and loss of customer confidence is usually much greater than the investment in updating. Furthermore, the store’s image may never recover from a serious incident (customers are unlikely to buy again from a site that has been hacked and exposed their credit card).
Data and Sales Compromise: Exposed customer data means not only legal violations (in Brazil, the LGPD provides for fines and sanctions for data leaks), but also immediate loss of sales. Imagine hundreds of customers having their cards cloned after purchasing from your store – in addition to complaints and support to help victims, you will probably see an avalanche of cancellations and an impact on reputation that will drive away new buyers. Not to mention that attackers can change the store’s banking details (for example, replacing PIX keys or deposit accounts), diverting payments directly without the retailer noticing immediately.
Unavailability and Damage to Reputation: Many of these vulnerabilities allow you to take down the website or change content. Your e-commerce may be down during important dates (Mother’s Day, Black Friday) because it has been sabotaged, resulting in incalculable revenue losses in that period. Even after regaining control, messages about the hack can spread on social networks, undermining trustworthiness. Regaining consumer and partner trust after a security incident is hard work – sometimes fruitless.

In short, staying on vulnerable versions is equivalent to walking with open doors and an exposed cash register. Hackers don’t need to “invent” new attacks – they simply exploit what is already documented (like the CVEs above). If large companies can suffer from security breaches, imagine a smaller store running antiquated systems; becomes an easy target. This is why we estimate that thousands of PrestaShop stores that have not updated remain at imminent risk, many possibly already unknowingly compromised (e.g. with some silent malware collecting data).

Time to Act: Migration to PrestaShop 8/9 and Good Security Practices

Given this alarming scenario, the only responsible attitude for retailers it is update as soon as possible their platforms. PrestaShop 8 (and soon 9) bring not only new features, but mainly essential security fixes. Here’s why to migrate and how to protect yourself:

PrestaShop 8/9 are Safer: All previously listed flaws have been fixed in the latest versions of the platform. Additionally, the core of PrestaShop has evolved – with newer PHP versions, updated frameworks, and constant audits from the open source community. Migrating to the latest version means close known loopholes. For example, the 2022 critical strike does not work on PrestaShop 1.7.8.7 or higher, and 8.x versions already include this patch by default.
Support and Community: Using maintained versions ensures that if new vulnerabilities are discovered, you will have patches quickly available. The PrestaShop community and team monitor and post security alerts (including via the PrestaShop backend). In obsolete versions, you will not be warned of anything – you will be “in the dark”. When migrating, keep in the habit of updating whenever maintenance comes out. This can be done safely in a test environment first, but do not delay security updates.
Update Modules and Themes: During migration, take advantage of clear unused modules (less code = fewer attack surfaces) and update all essential modules to their secure versions. Only install modules from trusted sources (official store or recognized developers) and follow their release notes. Many attacks exploit neglected extensions. The same goes for custom themes – make sure they don’t introduce loopholes and are compatible with the new PrestaShop without any hassles.
Backup and Contingency Plan: Before migrating or upgrading, make a full backup. And maintain regular backup routines. In the event of an attack, a recent and healthy backup can be the difference between reopen in a few hours or stay closed for days. Test your backups periodically. Also have an incident response plan: what steps to take if you suspect an intrusion (e.g. temporarily taking the website offline, informing customers, seeking specialized help, etc.).
Monitoring and Temporary Patches: Until full migration occurs, don’t sit idly by. Apply all available patches – for example, there were even free community modules to cover the 2022 flaw while the retailer updated. Check your store logs for strange activity (access spikes on unusual endpoints, creation of files you don’t recognize, long SQL queries). Use security scanning tools and keep your server (Apache/Nginx, PHP, MySQL) updated as well, as sometimes the attack comes from adjacent components.
Benefits of Migration Exceed Costs: We understand that migrating from PrestaShop 1.6/1.7 to 8 or 9 requires planning – some old modules may not be directly updated, your theme may need adjustments, and there is an investment of time. However, consider this as investment in the continuity of your business. The new versions improve performance, mobile compatibility, SEO and other areas that can even increase your sales. And, most importantly, you will sleep peacefully knowing that your store is not in the “showcase” of hackers. AGTI is ready to assist in this transition with minimum impact and maximum security.

Conclusion: The PrestaShop 1.6 and 1.7 vulnerabilities are not distant theoretical threats – they are real problems exploited daily on the internetm. If your store is still on these versions, consider yourself under red alert. Every day without updating is a day accumulating the risk of an incident that could compromise years of brand building and customer relationships. Don’t wait for it to happen to take action. Update, migrate, strengthen. Your store (and your customers) will thank you for the protection – and you will be able to focus on what matters: selling safely and growing, without unpleasant surprises along the way.