The words we use when we talk about your store's security, explained without jargon. Every term has its own anchor: the other pages of the site link straight here.
A mistake in some code that lets someone make it do what it should not.
A vulnerability is not a virus: it is a design or programming defect, most often a forgotten check on data received from outside. As long as nobody uses it, it does nothing. The danger appears when someone writes the means to take advantage of it - that is the exploit. On PrestaShop, the vast majority of exploited flaws are not in the core but in third-party modules.
The recipe that turns a flaw into a real intrusion.
The piece of code or the sequence of requests that concretely takes advantage of a vulnerability. It is what turns a theoretical problem into one that costs you money: a flaw with no known exploit stays dormant, a flaw with a public exploit is swept by bots within hours. That is why the delay between a flaw being published and your store being updated matters so much.
A flaw already being exploited while no fix exists yet.
The most uncomfortable case: attacks have started and the module vendor has not published an update - sometimes never will, particularly on an abandoned module. Updating is useless because there is nothing to install. This is precisely what an application firewall covers: it refuses the attacking request upstream, which protects you immediately, without waiting for a fix that does not exist.
A hidden way back in, left behind by the attacker.
A discreet file dropped on your server, often in an ordinary folder such as /upload, /img or /cache, letting the attacker take control of the store again even after you have changed every password. This is why "I changed my admin password" never resolves a hack on its own: as long as the backdoor is there, the door stays open. A serious cleanup starts by finding all of them.
A backdoor driven from a browser, like a pirate admin panel.
A form of backdoor that gives the attacker a real interface: browse your files, upload more, run commands on the server, connect to your database. Webshells are usually disguised — a name that looks like a PrestaShop file, or code hidden at the end of an image.
Code injected into the checkout page that copies your customers' card numbers.
A few lines of JavaScript added to your checkout flow. The customer pays normally, the order goes through normally, and in parallel their card number is sent to the attacker. Nothing is visible to the naked eye, for you or for the buyer — it is usually the bank or a customer who alerts you, weeks later. It is the costliest kind of infection: beyond the fraud itself, your GDPR liability is engaged.
Umbrella term for any code placed on your site without your consent.
The word covers backdoors as much as redirect scripts, cryptocurrency miners or spam relays. On PrestaShop it almost always arrives the same way: a third-party module whose vulnerability was never patched.
Your files or your database made unreadable, and a ransom demanded to get them back.
On a store, the attack rarely takes the spectacular encryption form you see on desktop machines: more often the attacker encrypts or wipes the database and the files, then leaves a note demanding payment. The only defence that actually works is an off-site backup you have already tested by restoring it — not a backup living on the same server, because that one gets encrypted along with everything else. Paying guarantees nothing and funds the next attack.
Hijacking a form or a URL to make your database talk.
The attacker slips a fragment of query into a search field, a filter or a URL parameter. If the module does not properly check what it receives, the database runs it: customer accounts, orders, sometimes the creation of an admin account. It is the most widespread flaw in third-party PrestaShop modules.
Running the attacker's code inside your visitors' browsers.
The attacker plants a script in an area your store displays back as-is — a product review, a name, a URL parameter. The script then runs for every visitor who loads the page: session theft, redirection, or the planting of a skimmer on the checkout page.
Trying thousands of passwords until one works.
Bots loop through username/password combinations on your admin login page. With no rate limiting, a weak password falls within hours. Beyond the intrusion risk, these waves slow the server down and sometimes take the store offline on their own.
A fake message that gets you to type your credentials into a page imitating the real one.
An email or text message pretending to be your host, PrestaShop, your payment provider — or your own back-office — inviting you to "sign in again". The password you type goes to the attacker, who then walks in through the front door: no technical flaw is needed, which is exactly why a firewall alone is not enough. That is what checking sign-ins from unfamiliar addresses is for. Worth knowing: attackers also phish your customers, using data stolen from a compromised store to make the message believable.
Making the site read a file it should never have opened.
By manipulating a parameter that points to a file, the attacker walks up the server tree and displays a sensitive file — typically your parameters.php, which holds the database credentials. In the worst cases the flaw also allows a previously uploaded file to be executed.
Showing a clean page to you and a hacked page to everyone else.
The malicious code checks who is asking for the page. A visitor arriving from Google is redirected to spam or phishing; you, logged in from your usual address, see nothing wrong. That is how a hack can run for weeks without the merchant noticing, until traffic collapses.
Your home page replaced by a message from the attacker.
The most visible form of a hack: the store disappears behind a page claimed by some group. Paradoxically it is the least serious - it is spotted immediately, so it gets handled fast. The infections that cost money are the ones careful to change nothing about how the site looks. A defacement is still a serious signal: if someone could rewrite your home page, they had access to everything else.
Your server hijacked to send email on the attacker's behalf.
A script on the site sends thousands of fraudulent emails from your server. Immediate consequences: your domain gets blacklisted by mail providers (your real order confirmations stop arriving), and your host ends up suspending the account.
Nobody picked you: bots knock on every door, continuously.
"Why my store? I am not Amazon." Because no human targeted you. Networks of compromised machines crawl the internet non-stop and test the list of published flaws against every site, regardless of size or revenue. A small store running an out-of-date module is just as valid a target as a large one - often more, because it is watched less closely. It is also what makes the shared blacklist effective: the same addresses knock everywhere.
A filter that blocks hostile requests before they reach your store.
Where an antivirus looks at your files, the application firewall looks at incoming traffic and refuses anything that looks like an attack: SQL injection, injected script, mass login attempts. Its main value is time: it protects a known flaw immediately, without waiting for the module vendor to publish a fix.
The public identifier of a known security flaw.
When a flaw is found in PrestaShop or in a module, it receives a worldwide reference number, for example CVE-2024-6648. That number is public: attackers use it as a catalogue and scan the internet for stores that have not updated yet. It is a race between the moment the flaw is published and the moment you patch.
The record describing a flaw: affected module, versions, fix.
For every flaw we track, we keep a record: which module, which versions are vulnerable, from which version it is fixed, and what we do in the meantime. Your dashboard cross-references those records with the modules actually installed on your store, so you only see what concerns you.
Comparing each of your files to the official PrestaShop original.
Every file has a unique digital fingerprint. By comparing your files' fingerprints with those of the official files for your PrestaShop version, we pinpoint exactly what was modified, added or removed — even when the injected code is too well written to look like a virus.
An attack blocked at one customer immediately protects all the others.
When an IP address attacks a store on the network, it is added to a list shared by every protected store. The same attacker showing up at your door afterwards is refused before even trying. The more stores on the network, the more current the list.
A second factor on top of the password, so that a stolen password is no longer enough.
A one-time code requested in addition to the password at sign-in. It is the only genuinely effective protection against phishing and credential theft: even with the right password, the attacker is stopped. The same principle applies to checking admin sign-ins from an address the store has never used: extra proof is required before letting anyone in.
A file flagged as suspicious when it is perfectly legitimate.
Some commercial modules ship compressed or encoded code that, from a distance, looks like malicious code. A good antivirus should flag it rather than ignore it, but it must also let you settle the question fast. The dashboard gives you the context and the exact code excerpt to decide — and our team arbitrates the doubtful cases.
Closing the doors you do not need, to limit what an attacker can reach.
The set of settings that make an intrusion harder and less profitable: correct file permissions, a maintained PHP version, restricted admin access, install folders removed. It is not protection against one specific attack; it is what makes an exploited flaw cause less damage.
The red "Dangerous site" screen that cuts your traffic off.
When Google detects malicious content on a store, it shows a full-screen warning before letting the visitor in, and rankings drop. Removal is not automatic: you have to clean up, then request a review in Search Console. Expect 24 to 72 hours after validation.
Closing a flaw without changing the module version.
When a flaw is published, the normal answer is to update the module — provided the vendor released a fixed version, that it is compatible with your store, and that you can install it. A patch works differently: it edits precisely the faulty lines in the version you already run. The flaw closes without a version change, without regression risk on your theme, and the operation is reversible.
Tell the vendor first, publish the detail later — or never.
Publishing the detail of a flaw before the vendor has fixed it arms anyone against every store running the module. Coordinated disclosure means notifying the vendor, giving them time to ship a fix, and only publishing afterwards. That is why we count our own discoveries publicly without ever naming the module until a fix is available to everyone.
A term missing, or a definition that isn't clear? Tell us and we'll add it.
