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 February 12 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 February 13 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 February 13 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 February 13 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.

[venditdevs]

If the leak is true, it's indeed really concerning that they are not clearly communicating. But evenly concerning in that case is the fact that they attend us on the fact of some regulations about making a notification to the proper instances (GPRD) whithin 72 hours after discovery of your store has been comprimized.

Note that if they didn't knew it in august, i pointed them out in begin november 2025, thats 4 months ago now.. So if the leak is true they deliberately conceal this and try to keep it quiet. That will cost them probably millions (up to 20 million of 4% of the yearly income if the security was bad) not even talking about the reputation damage.

[AGuyTryingToCode]

I've now come to the conclusion that what @venditdevs saw happen to his client is now more widespread. I've already advised people I know who use presatshop to act accordingly. If this was a coding issue either with the core code or modules, prestashop could have given more information (e.g. module to remove or temp fixes to block until a patch is made, or even just clarifying what it is). The fact they :

1. Haven't posted anything on https://build.prestashop-project.org/ is telling and feels like it is being hidden.
2. Are advising customers change FTP and SSH details (which again backs up it not being a coding issue).

If prestashop read this, please note that as you have not provided any other information, the lack of clarity leads to people coming to their own conclusions. You have left us in limbo constantly checking _partials/head.tpl plus other files to see if we are affected. This is stressful and could easily have been avoided. If you have been compromised, tell us and be transparent about it. I personally would have been fine with you telling us right at the beginning (hacks have and always will happen, its how you help prevent them and how you deal with it that counts. Even more so when people rely on you). You could always update us afterwards stating its not as bad as you thought etc if that's the case.  Transparency and timely updates are key to something like this being a nightmare or just an annoying inconvenience.

Edited February 16 by AGuyTryingToCode (see edit history)

[venditdevs]

On 2/16/2026 at 10:50 AM, AGuyTryingToCode said:

I've now come to the conclusion that what @venditdevs saw happen to his client is now more widespread. I've already advised people I know who use presatshop to act accordingly. If this was a coding issue either with the core code or modules, prestashop could have given more information (e.g. module to remove or temp fixes to block until a patch is made, or even just clarifying what it is). The fact they :

1. Haven't posted anything on https://build.prestashop-project.org/ is telling and feels like it is being hidden.
2. Are advising customers change FTP and SSH details (which again backs up it not being a coding issue).

If prestashop read this, please note that as you have not provided any other information, the lack of clarity leads to people coming to their own conclusions. You have left us in limbo constantly checking _partials/head.tpl plus other files to see if we are affected. This is stressful and could easily have been avoided. If you have been compromised, tell us and be transparent about it. I personally would have been fine with you telling us right at the beginning (hacks have and always will happen, its how you help prevent them and how you deal with it that counts. Even more so when people rely on you). You could always update us afterwards stating its not as bad as you thought etc if that's the case.  Transparency and timely updates are key to something like this being a nightmare or just an annoying inconvenience.

They have updated the original post with the information regarding the mloader module i've mentioned before. This is the next confirmation that i'm probably right about the data breach... but still no confirmation about that.

Even official instances, my case "Autoriteit Persoonsgevevens" (the Dutch GPDR office) are taking it lightly, because i opened a case there in november but still no action or reaction from them... that's also a bad thing.. 

https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores

[AGuyTryingToCode]

@venditdevs "simplefilemanager", looks like someone else must have also reported the compromise with them using a different module. 

It's horrific that Prestashop didn't appear to take your report seriously in November 2025. I suspect this is possible down to a failing of there support quality (whenever I have contacted them in the past it has been pointless). Either way, something this serious should be very clearly communicated (fully explaining how it may have happened (even if it turns out that's not the case).

It's clear it hasn't been clearly communicated as if it had, this forum would be flooded with people asking what to do and how it happened.

Edited February 19 by AGuyTryingToCode (see edit history)

[AGuyTryingToCode]

I'm assuming no one has heard anything else regarding the cause of this? Any developers on here been contacted by Prestashop? I would have though by now Prestashop would have known how it happened. 

[Doopiempd]

1 minute ago, AGuyTryingToCode said:

I'm assuming no one has heard anything else regarding the cause of this? Any developers on here been contacted by Prestashop? I would have though by now Prestashop would have known how it happened. 

No, Venditdevs and i still haven't received anything from them. Ignoring this won't make it go away.  
Maybe we will have to file a report to the proper instances, just because of this behaviour.
Like Venditdevs said, it will cost them millions. I think that's the reason why they are keeping their mouth shut.

BTW Do you all know Prestashop has been sold to cyberFolks.pl Group. Maybe that is another reason why they are quiet on this.

It's bad ...really really really bad. And even in this topic, no response from them.

[Doopiempd]

If you have linkedin. Please post the link to this topic under every post of Prestashop. Even on the linkedin of Prestashop managment ( CEO and stuff )

It's time for the world to know.

[Thierry L]

Hi everyone,

Just to clarify the official PrestaShop security alert (Feb 2026 skimmer campaign):
Official PrestaShop page (EN): https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores
Official PrestaShop page (FR): https://help-center.prestashop.com/hc/fr/articles/33259937046034-Alerte-de-sécurité-Vérification-recommandée-de-vos-boutiques

What it says:

• Digital skimmer injecting script in checkout templates (head.tpl, themes) to steal payment data via fake payment forms.
• Check for suspicious scripts (e.g., atob patterns, external domains) and unknown modules.
• Change all credentials (BO, FTP, DB, SSH).
• Report if data breach (RGPD obligations).

You’re right, the alert is vague on the initial attack vector (likely old modules/SQLi, as usual). But the remediation steps are solid.
More context from security firms:

• Sansec analysis: https://sansec.io/research/global-retailer-prestashop-hacked
• FOP Security advisories: https://security.friendsofpresta.org

Quick checklist for hosts/merchants:

1.  Grep your store for  atob(  or known skimmer domains in .tpl files.
2.  List recent module installs (logs or PS_Module table).
3.  Force update core + all modules.
4.  can with Sucuri/Malcare if possible.

Hope this helps! PrestaShop could indeed share IOCs (indicators of compromise) publicly for faster cleanup.
Best, 😉

[Doopiempd]

3 minutes ago, Thierry L said:

....(likely old modules/SQLi, as usual).....

No, hack of Prestashop support. There is proof.

[Thierry L]

Il y a 3 heures, Doopiempd a dit :

No, hack of Prestashop support. There is proof.

i understand, on my side I have not stated anything because I have no more proof than the writings coming from Prestashop on the given link. Maybe I mistranslated the word "Likely". I apologize for that. Do you have evidence? Can you share them?

[Doopiempd]

On 2/13/2026 at 10:43 AM, venditdevs said:

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.

This post has all the information. I was the one who investigated this incident on the Prestashop shop side. With my findings Venditdevs investigated it on their side and that's where things made sense and everything became clear.

Prestashops lack in everything on this is a real concern. 


 

[Thierry L]

il y a 43 minutes, Doopiempd a dit :

This post has all the information. I was the one who investigated this incident on the Prestashop shop side. With my findings Venditdevs investigated it on their side and that's where things made sense and everything became clear.
Prestashops lack in everything on this is a real concern. 

Hi Vincent,
Have you filed a complaint with CNIL? Your logs + Venditdevs investigation make solid evidence.

[Krystian Podemski]

Hello everyone,

We would like to state clearly that there has been no data breach, hacking incident, or any security compromise related to the PrestaShop Marketplace, the Help Center system, or any other PrestaShop services or products.

If there had been any confirmed security incident or data breach, PrestaShop SA would have taken all necessary and legally required actions, including appropriate communication. Transparency and compliance are fundamental to how we operate.

We did not engage earlier in this thread because we do not publicly speculate about security matters. Some of the theories shared here are not aligned with the facts and have been presented in a way that suggests conclusions that are not supported by the evidence. For example: no developer blog post was published because no vulnerability was identified and no code changes were required.

The page with all the publicly available findings is here in the Help Center.

The security of our merchants and ecosystem remains a top priority. We won’t comment on that matter any further.

[Doopiempd]

I'm done posting in this thread. I'm getting angrier by the minute because of their behavior.

Good luck to everyone and hopefully they will come clean in the end. 

[AGuyTryingToCode]

@Krystian Podemski

Thank you for taking the time to reply.

I would greatly appreciate it if you could provide further information on how the compromises have occurred (even if it is just a very brief summary so not to give away any active security vulnerability that is not yet patched). I appreciate the page at https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores?utm_campaign=26061922-Security explains how to check if your site is compromised but as with any compromise, the key is to make sure it can't happen again (and also for GDPR users need to compile a report for the ICO on how it occurred). Without any further information on how the compromise occurs, I am struggling to see how a user who was compromised could stop this re-occurring.

On the page https://help-center.prestashop.com/hc/en-us/articles/33259937046034-Security-Alert-Recommended-Check-of-Your-Stores it says to:

Quote

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).

Whilst I agree this is good practice after any compromise, this would not stop the compromise from re-occurring unless the compromise has occurred by directly logging in using these details (since if this was a code vulnerability would still exist / not be patched).

You state above that

Quote

that there has been no data breach, hacking incident, or any security compromise related to the PrestaShop Marketplace, the Help Center system, or any other PrestaShop services or products. 

If you could clarify how the compromise like @venditdevs experienced occurs (even if its just a brief statement like "its a module with a security weakness but we cant say which one for now due to security reasons"), it would go a long way to helping Prestashop users relax. Ideally, if it is a module that allows the site to be compromised, letting us know which one would be a great help so we can completely remove it for now until a patch is released etc. If there is a weakness in the Prestashop user system, please do let us know so we can take steps to remove all the non-superadmin / default users temporarily .

I appreciate that I do not have all the facts. However, its been 8 days since Prestashop released the information on how to check if your site is compromised but no details on how this is occurring. I think it is important for the Prestashop team to understand that issues like this can cause sleepless nights and worries for users that potentially could be avoided. Please remember that a lot of people use Prestashop as their main ecommerce platform and for many it is their only source of income. If they have been compromised, they are currently in a state of limbo with the only real solution being to take their site offline (which would cause significant sales damage / SEO issues etc).

Again, thank you for your reply and if you could provide additional data on the above, it would be greatly appreciated. 

 

[AGuyTryingToCode]

@venditdevs Did your client use the "Advanced Popup Creator" module (https://security.friendsofpresta.org/modules/2026/02/16/advancedpopupcreator-cve-2025-69633.html) ?

Edited Wednesday at 05:34 PM by AGuyTryingToCode (see edit history)

[fmoreira86]

1 hour ago, Krystian Podemski said:

Hello everyone,

We would like to state clearly that there has been no data breach, hacking incident, or any security compromise related to the PrestaShop Marketplace, the Help Center system, or any other PrestaShop services or products.

If there had been any confirmed security incident or data breach, PrestaShop SA would have taken all necessary and legally required actions, including appropriate communication. Transparency and compliance are fundamental to how we operate.

We did not engage earlier in this thread because we do not publicly speculate about security matters. Some of the theories shared here are not aligned with the facts and have been presented in a way that suggests conclusions that are not supported by the evidence. For example: no developer blog post was published because no vulnerability was identified and no code changes were required.

The page with all the publicly available findings is here in the Help Center.

The security of our merchants and ecosystem remains a top priority. We won’t comment on that matter any further.

Hello Krystian,

Thank you for your response.

I would like to highlight a simple logical point, not a theory.

You state that no code vulnerability was identified. I accept that.

If the root cause is not in PrestaShop's code, and not in third-party modules, then by elimination the common denominator has to be leaked credentials. There is no other explanation for how attackers gained authenticated access to multiple independent stores..

The question then becomes simple: where did those credentials leak from?

I am not speculating. I am reading PrestaShop's own official security alert, which states:

"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)."

This recommendation comes from PrestaShop itself, not from this thread. And it only makes sense in the context of a credential compromise. If the attack vector were a code vulnerability, rotating FTP and SSH passwords would be irrelevant advice.

I am not accusing. I am following the logic that PrestaShop's own official communication leads to.

If the leak did not originate from PrestaShop's systems, please help the community understand what the common vector was. That is the only information merchants actually need right now.

[AGuyTryingToCode]

1 hour ago, Doopiempd said:

You are full of sh*t in this post and you know it. We provided all evidence on a silver plate. And now you are denying and still NOT give people information.

Pathetic attempt to brush it off.

I think it is important for us to get all the information first before accusing Prestashop. I understand your frustration but as @Thierry L posted earlier, CVE-2025-69633 does allow SQL Injection and in turn "Retrieve administrator credentials and ultimately obtain admin access to BackOffice". If this is how they are getting in, upgrading the module code:

- OR FIND_IN_SET("' . $controller . '", `controller_exceptions`))';
+ OR FIND_IN_SET("' . pSQL($controller) . '", `controller_exceptions`))';

Line ~371
Line ~986

would fix the issue and stop the compromise re-occurring (assuming this is how the site was compromised).

If @venditdevs confirms the client had the "Advanced Popup Creator" module installed, this may explain how the compromise occurred.

Edited Wednesday at 05:48 PM by AGuyTryingToCode (see edit history)

[Doopiempd]

39 minutes ago, AGuyTryingToCode said:

I think it is important for us to get all the information first before accusing Prestashop. I understand your frustration but as @Thierry L posted earlier, CVE-2025-69633 does allow SQL Injection and in turn "Retrieve administrator credentials and ultimately obtain admin access to BackOffice". If this is how they are getting in, upgrading the module code:

- OR FIND_IN_SET("' . $controller . '", `controller_exceptions`))';
+ OR FIND_IN_SET("' . pSQL($controller) . '", `controller_exceptions`))';

Line ~371
Line ~986

would fix the issue and stop the compromise re-occurring (assuming this is how the site was compromised).

If @venditdevs confirms the client had the "Advanced Popup Creator" module installed, this may explain how the compromise occurred.

No, the client did not have that module.

There was a direct hit on the not obvious admin page. Logged in with a username and password only shared on the Prestahop support site. The admin url was also shared there.

From there they installed the module and did their thing.

No sql injection of any kind! Just walked into the backdoor with credentials only known by Prestashop support!

[Yabber]

@venditdevs  Report this incident to "Commission Nationale de l’Informatique et des Libertés". This is the office that deals with investigating such matters.

[Doopiempd]

7 hours ago, Yabber said:

@venditdevs  Report this incident to "Commission Nationale de l’Informatique et des Libertés". This is the office that deals with investigating such matters.

In this case we've reported it to the dutch 'Autoriteit Persoonsgegevens'. We had to report it there otherwise WE and/or the shop owner could get very high fines for sweeping it under the carpet.( What Prestashop is doing now). I hope they will get after Prestashop on this.

[venditdevs]

7 hours ago, Yabber said:

@venditdevs  Report this incident to "Commission Nationale de l’Informatique et des Libertés". This is the office that deals with investigating such matters.

I already did this in our country, they are obliged to pass it through the French department. It;s much easier that way, the French department is unnecessarily difficult to reach.

[Krystian Podemski]

I feel there are a few points that have to be raised. Please consider this my personal comment, not a statement from PrestaShop SA.

First of all: I heard about such an attack in the community, where the victim never contacted PrestaShop SA for support. The attack was also a direct login to the back office. This is to debunk the theory that 100% PrestaShop Support credentials were leaked. If you think that's the case, instead of making public accusations here on the forum, the evidence should be shared with the proper authorities. I must say making such public accusations is bold.

Information about 21 million marketplace accounts stolen? It's hard to even comment on that. Think about 250.000 stores PrestaShop has across the globe, and then try to map it to the alleged 21.000.000 accounts on the Marketplace. Of course, such a database may leak directly from merchants' PrestaShop instances: most of the time, because of third-party module vulnerability. It's a thing the community is dealing with, not only in the PrestaShop world but also on other platforms. That's why it's important to follow security best practices that are often mentioned. Security is a shared responsibility.

Attackers regularly scan PrestaShop websites, especially those that have historically been vulnerable to SQL injection. Addresses to the back office are often shared with databases on the dark web, and such stores are scanned even after the original SQLi vulnerability is fixed...

Quote

"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)."

This is a normal recommendation. As someone experienced in this ecosystem and in open source, I can tell you that if your store has ever been hacked, you have to check everything. I've seen attacks where backdoors were left on the server with SSH access, and others where the crontab was modified to keep a backdoor available for an attacker.

If your server allows running `exec` commands, then the attacker can also sometimes create an FTP account. Not to say that there's always a human factor: those who create such credentials could've been hacked as well. It's all speculation.

Quote

If you could clarify how the compromise like @venditdevs experienced occurs (even if its just a brief statement like "its a module with a security weakness but we cant say which one for now due to security reasons"), it would go a long way to helping Prestashop users relax.

Again, that would be speculation. As stated above in the official PrestaShop SA response, PrestaShop SA does not publicly speculate on security matters, and hence, the company did not comment on that.

Quote

If there is a weakness in the Prestashop user system, please do let us know so we can take steps to remove all the non-superadmin / default users temporarily .

All the security advisories are available here. Full transparency. There is also a great initiative by Friends of Presta, which maintains this website: https://security.friendsofpresta.org/

Quote

 

If the leak did not originate from PrestaShop's systems, please help the community understand what the common vector was. That is the only information merchants actually need right now.

 

While I cannot give you the reasons A, B, C, D, etc., I can tell you that, in my opinion, it appears to be a lack of security hygiene. Some vulnerability that allowed credentials to be retrieved. Outdated, vulnerable module? Weak BO URL/password combination? Historical SQLi? Speculation.

I can tell you that PrestaShop SA chose to communicate because, based on the information available, it was the responsible approach. There was a growing trend on a day-to-day basis since the end of the previous week before the communication.

I will not comment further on this matter, even privately. Please, let’s keep the discussion in this thread respectful. I believe one of the users slightly overreacted...

There are established processes and authorities within EU countries that deal with such issues. Making public accusations will not help.

I can promise you that I will make every effort to ensure that any future communication is more precise.

Wishing everyone a great day.

[Doopiempd]

Quote

While I cannot give you the reasons A, B, C, D, etc., I can tell you that, in my opinion, it appears to be a lack of security hygiene. Some vulnerability that allowed credentials to be retrieved. Outdated, vulnerable module? Weak BO URL/password combination? Historical SQLi? Speculation.

Direct hit because of leaked credentials.I hesitated to post some log files, but since some people are very stubborn, here they are. On the first visit, they went straight to the admin page and logged in.

<IPADDRESS> - - [30/Oct/2025:10:46:08 +0100] "GET /<ADMINURL>/index.php HTTP/1.0" 302 1741 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7 HTTP/1.0" 200 3818 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /js/jquery/plugins/validate/localization/messages_nl.js HTTP/1.0" 200 3520 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /js/vendor/spin.js HTTP/1.0" 200 3481 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /<ADMINURL>/themes/default/public/theme.css HTTP/1.0" 200 3491 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /js/jquery/jquery-3.4.1.min.js HTTP/1.0" 200 3494 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /<ADMINURL>/themes/default/css/overrides.css HTTP/1.0" 200 3740 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /js/vendor/ladda.js HTTP/1.0" 200 3482 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /js/jquery/plugins/jquery.validate.js HTTP/1.0" 200 3501 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"
<IPADDRESS> - - [30/Oct/2025:10:46:09 +0100] "GET /js/admin/login.js?v=8.2.3 HTTP/1.0" 200 3481 "https://<DOMAIN>/<ADMINURL>/index.php?controller=AdminLogin&token=1b07d9e72e7f972dbc659d36c6a017d7%22 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/141.0.0.0 Safari/537.36"

Prior in the logs NO scans, no sql injection or any other stuff. Just straight to the door with the key.
It was an account for Prestashop support, with sql injection or any other method you cannot retreive the plain text password!
The account was made specially for Prestashop support and credentials were only communicated through Prestashop support forum. It's never been saved or communicated anywhere else.
Speculation: Maybe it was an inside job? <-- even more worrying
 

Quote

First of all: I heard about such an attack in the community, where the victim never contacted PrestaShop SA for support. The attack was also a direct login to the back office. This is to debunk the theory that 100% PrestaShop Support credentials were leaked. If you think that's the case, instead of making public accusations here on the forum, the evidence should be shared with the proper authorities. I must say making such public accusations is bold.

We informed and contacted Prestashop. After that we've informed the national authorities.

Last email we've received from Prestashop on 4-11-2025:

We provided all information .....Prestashop never gave a response or took any action....
 

Edited 17 hours ago by Doopiempd
grammar (see edit history)