What's new

On PrestaShop 8 and 9, the code typed on the verification screen did not reach our service from some back-office pages: the employee landed back on the entry screen believing the code was wrong. This is fixed. An address approved from your customer area or by our team is now applied within a minute instead of waiting for your shop's scheduled task; the same goes for switching the protection off. Finally, when a code cannot be issued, the door stays closed and the screen shows how long to wait: no more access without verification.

A sign-in to your administration from an address your shop has never used can now be held until a code sent by e-mail is entered. The protection starts in observation mode: for the first few days it simply records the addresses your team actually uses, without ever blocking anyone or sending anything. You then decide when to switch it on, once the list is complete. Advance plan and above.

Behind Cloudflare or a load balancer, every connection appeared to come from the same address, which made any distinction impossible. We now read the originating address, but only when the request comes from an intermediary we recognise: a header forged by an attacker therefore cannot impersonate a trusted address.

When a security fix could not find the file it targets, we concluded the flaw was gone. That is usually true, but not always: the file may simply sit somewhere other than where we looked, with the flaw still in place. We now tell the two cases apart, and no shop is considered safe without evidence.

Our security fixes replace a block of code byte for byte, so that nothing but the intended part is ever touched. Yet the same file is not written the same way depending on whether it was saved from Windows or from a server: line endings differ, invisibly. On those shops the fix no longer recognised the targeted block and held back, out of caution. The engine now re-expresses the pattern in the style of the file in front of it: the protection applies everywhere, without ever rewriting anything blindly.

Hiding malicious code in a file that presents itself as an image is a proven technique: the file carries a photo extension, but the server finds instructions inside. We looked for them where files arrive from outside — the upload and download folders. The difficulty is not looking elsewhere, it is doing so without re-reading the hundreds of thousands of legitimate images in your catalogue on every scan. We now sniff the header of every image everywhere, including under your themes, modules and libraries, and only examine in depth those that genuinely contain code. The scan stays just as fast, and no longer leaves that corner aside.

As soon as a file is flagged, our system studies it in depth. You now see in your dashboard which way that analysis leans, likely false alarm or real threat, along with its confidence level, without waiting for us to step in behind the scenes. So you know right away what deserves your attention.

Some merchants also run a WordPress inside their PrestaShop store. It is not advisable, but it happens, and its core sometimes set off alerts by mistake. The same went for the test libraries shipped with certain modules and for compressed JavaScript files. The scanner now recognises these ordinary components and sets them aside, without easing off on the files that genuinely carry risk. Your scan reports become easier to read.

Some attackers graft an invisible script onto your back-office login page to capture your username and password every time you sign in, then reinstall themselves after a simple password change. That is how they keep coming back day after day. We now spot this kind of graft: a script quietly loaded into the admin and a hidden browser marker, even when the attacker renames the files to cover their tracks. Found on a real store, this trap used to go unnoticed and now triggers a critical alert.

On stores with a very large number of files, or with heavy activity logs, the analysis could stop midway because it ran out of memory. It now keeps its usage in check as it goes and runs all the way through, whatever the size of the site.

We hardened detection of card skimmers (Magecart-style) that hide their collection address in encoded form inside a script or a fake image, as well as loaders that run a backdoor downloaded from an external server, even when the code is deliberately disguised. Spotted on real stores, these patterns now surface as a critical alert instead of slipping under the radar.

We now hunt down backdoors that camouflage themselves, by disguising their code (for instance playing with letter case to fool antiviruses) or by reinstalling on their own through a file downloaded from outside. Found on real stores, often hidden inside pirated modules, these traps used to stay "quiet": they now trigger a critical alert.

No more abrupt “Access denied” page. After repeated attempts, the customer sees the store's usual login form with a clear message: too many attempts, remaining wait time and a direct link to reset their password. The threshold has been relaxed so a customer who simply mistypes their password isn't penalised, while automated attacks are still blocked instantly.

View the content of a flagged file, or its comparison with the official PrestaShop version, straight from your PrestaSecure dashboard, no SSH or FTP needed. Read-only access, strictly limited to your store and to safe file types.

The scanner now inspects the configuration and the editorial content displayed on your store, not just the files. This closes a blind spot exploited by some attackers to inject a card-skimming script outside the site's files, a vector seen in a real customer incident.

Catalogues of several million files, multistore: the scan now analyses the entire estate, with no truncation or memory overflow, chaining several automatic passes if needed. No part of the site is left out.

Recurring scans now only analyse the files actually modified since the last run, instead of re-scanning everything. The time saving is considerable on large stores, with no loss of coverage: a single changed byte is still detected.

The report builds before your eyes: threats appear as the scan progresses, with their severity and grouping, instead of waiting until the very end.

The module scans your store's PHP error log for known attack signatures (template injection, attempts to read sensitive configuration files, remote file inclusion, etc.). Attackers often leave months of failed attempts before succeeding: you're alerted from the very first signals.

No folder is skipped during the scan anymore (dependencies, themes, back office, upload folders, etc.). Malicious code can hide anywhere, including in a dependency or a webshell dropped into the admin. The analysis now covers the whole site.

Fix things in a few clicks: applying validated security patches, cleaning infected files, removing phantom modules (present on disk but unknown to PrestaShop) and updating vulnerable modules, all with automatic backup and rollback.

A badge shows, for every detected vulnerability, whether it's already neutralised by the PrestaSecure application firewall. You can tell at a glance what's protected from what needs action.

Apply patches for known vulnerabilities in the PrestaShop core and modules straight from your dashboard, with a prior backup, automatic verification after applying and the option to undo at any time.

First release: protection dashboard with a score, antivirus (file and fingerprint scanning), application firewall (SQL injection, XSS, brute force, path traversal), remediation tools, exportable security report and automatic module updates.