Shopping Cart
There are no more items in your cart
- Tecnoacquisti.com
- Online Security Blog
Security Advisory - April 2026 - GHSA-w9f3-qc75-qgx9 - CWE-79 - Severity 9.3/10
Critical severity declared, but with significant practical limitations that reduce the real risk in most shops. Read the full analysis before getting alarmed.
Critical severity declared, but with significant practical limitations that reduce the real risk in most shops. Read the full analysis before getting alarmed.
[embed name="PrestaShop XSS Vulnerability Fix"]https://youtu.be/PLs4Fzwlt68[/embed]
At the end of April 2026, PrestaShop confidentially informed its certified partners of the discovery of a Stored XSS vulnerability in the administration panel, specifically in the Customer Service section. The affected versions are PrestaShop 1.7.x, all 8.x prior to 8.2.6, and all 9.x prior to 9.1.1.
We have analyzed the vulnerability in detail, conducted practical tests on real environments, and developed a free and open-source fix module. In this article, we share the results, with particular attention to the concrete limits of this attack - an aspect often overlooked in security communications.
What is a Stored XSS and why it concerns Customer Service
A Stored XSS (Persistent Cross-Site Scripting) vulnerability occurs when data provided by an external user is saved in the database and later displayed on another page without being properly sanitized. In this specific case, the vector is the email field of the "Contact Us" form in the front office.
A visitor sending an email containing special characters typical of HTML/JavaScript code could - under favorable conditions - cause those characters to be interpreted as code when an administrator opens the message in the back office. The theoretical impact is significant: a malicious script executed in the administrator's session could read the session cookie and transmit credentials to third parties.
The declared severity of 9.3/10 reflects this worst-case scenario and the fact that the attack originates from an unauthenticated user (anyone can fill out the "Contact Us" form).
Practical limits: why many shops are already protected
During our tests on real installations, we found that in the vast majority of cases the vulnerability is already mitigated by pre-existing measures.
1. PrestaShop 8.x email validation
On PrestaShop 8.x, the isEmail() function in default mode already rejects emails containing the " (double quote) character, which is the main vector of this attack. In our tests, the payload was rejected before even reaching the database, with an "Invalid email" error returned to the sender.
On PrestaShop 8.x, the isEmail() function in default mode already rejects emails containing the " (double quote) character, which is the main vector of this attack. In our tests, the payload was rejected before even reaching the database, with an "Invalid email" error returned to the sender.
2. reCAPTCHA modules and email validation
The presence of a reCAPTCHA module or an advanced email validation system on the contact form blocks the automatic sending of payloads. Without being able to bypass the CAPTCHA, the attack cannot be automated and requires manual interaction - drastically reducing its scalability.
The presence of a reCAPTCHA module or an advanced email validation system on the contact form blocks the automatic sending of payloads. Without being able to bypass the CAPTCHA, the attack cannot be automated and requires manual interaction - drastically reducing its scalability.
3. Customer Service not used or rarely opened
If the back office is not used to manage Customer Service messages, the exposure window is further reduced. The script only executes when an admin opens the specific ticket.
If the back office is not used to manage Customer Service messages, the exposure window is further reduced. The script only executes when an admin opens the specific ticket.
4. PrestaShop 1.7 with additional protection modules
On PrestaShop 1.7, where email validation is more permissive, the presence of reCAPTCHA or email pattern blacklists (blocking emails containing <, >, ") is sufficient to prevent the payload from reaching the database.
On PrestaShop 1.7, where email validation is more permissive, the presence of reCAPTCHA or email pattern blacklists (blocking emails containing <, >, ") is sufficient to prevent the payload from reaching the database.
Risk scenarios by configuration
| PS Version | reCAPTCHA / email validation | Real Risk | Recommended Action |
|---|---|---|---|
| 8.x ≥ 8.2.5 | Any | Low | Update to 8.2.6 when available |
| 8.x < 8.2.5 | Present | Low | Apply the hotfix module |
| 8.x < 8.2.5 | Absent | Medium | Apply the hotfix module |
| 1.7.x | Present | Low | Apply the hotfix module |
| 1.7.x | Absent | High | Apply the hotfix module urgently |
What the hotfix module fixes
The module acts on two distinct levels, both permanent and independent of its installation:
Fix 1 - BO template sanitization (all versions)
The Customer Service page template in the back office is modified to correctly apply HTML escape on all fields displaying data from the database. Even if a payload were to reach the DB, it would be displayed as text and never executed.
The Customer Service page template in the back office is modified to correctly apply HTML escape on all fields displaying data from the database. Even if a payload were to reach the DB, it would be displayed as text and never executed.
Fix 2 - Strengthened email validation (PS 8.0.2+)
On PrestaShop 8.0.2 and above, the email validation mode is changed from loose to strict. On PrestaShop 1.7, a specific guard is injected to block the " character.
On PrestaShop 8.0.2 and above, the email validation mode is changed from loose to strict. On PrestaShop 1.7, a specific guard is injected to block the " character.
Forensic database scan
The module includes a database analysis function that searches for suspicious patterns in customer and message tables, providing immediate indications of any previous exploitation attempts and corrective actions to be taken.
The module includes a database analysis function that searches for suspicious patterns in customer and message tables, providing immediate indications of any previous exploitation attempts and corrective actions to be taken.
Override detection
Before applying the fix on Validate.php, the module checks if there is an override of the isEmail() method. If so, the automatic modification is skipped, and the code to be applied manually is shown, avoiding conflicts with existing customizations.
Before applying the fix on Validate.php, the module checks if there is an override of the isEmail() method. If so, the automatic modification is skipped, and the code to be applied manually is shown, avoiding conflicts with existing customizations.
What to do now - in order of priority
- Check the PrestaShop version of each shop you manage (BO - Advanced Parameters - Information).
- Install the hotfix module on all shops with versions 1.7.x, 8.x < 8.2.6, and 9.x < 9.1.1.
- Perform the forensic scan from the module panel to check for any previous attempts.
- Add forbidden email patterns in your validation module: blocking emails containing <, >, and " adds an additional layer of protection.
- Plan the update to versions 8.2.6 / 9.1.1 as soon as they are officially released by PrestaShop.
Free and open-source hotfix module
The tecno_xss_hotfix module is available for free on GitHub. It supports PrestaShop from version 1.7.0.0 to 9.x, includes forensic database scanning, and override detection. The code is public and verifiable.
Download from GitHubNote: This article is written by Tecnoacquisti.com, a PrestaShop partner agency that received the early confidential communication of the vulnerability. The technical information is based on direct code analysis and tests conducted in controlled environments. No details on attack techniques are provided to prevent misuse. For more information on the vulnerability, refer to the official PrestaShop bulletin at the time of the release of versions 8.2.6 and 9.1.1.