Your store is being attacked right now. Not "maybe", not "someday" - at this very moment, automated scripts are scanning every Polish domain looking for vulnerabilities. Bots don't need a human at the keyboard. They run 24/7 and are far more patient than any e-commerce store administrator.
In this article I'll show you exactly what an attacker sees within the first minutes of targeting your store. No panic, no scaremongering. Just technical facts that will help you make concrete decisions.
What does an automated store scan look like - step by step
Before an attacker makes their first move, their script already knows more about your store than you think. The entire fingerprinting process - identifying the technical environment - takes anywhere from a few to several dozen seconds and happens without logging in, without any credentials, completely passively.
Step 1: Platform identification
The bot sends GET requests to several characteristic paths. If just one returns a response other than "404 Not Found", the script knows it's dealing with PrestaShop. The most commonly checked files and directories are:
/modules//themes//img//INSTALL.txt/CHANGELOG.txt
The CHANGELOG.txt file is particularly valuable for an attacker. In older PrestaShop installations it contains the full version history - meaning the attacker learns your exact engine version without any break-in.
Step 2: HTTP headers reveal more than you think
Every response from your server contains HTTP headers. An improperly configured server exposes the PHP version, the web server name (Apache/Nginx) with its version, and sometimes even the framework being used.
You can check this yourself: open DevTools in your browser (F12), go to the Network tab, refresh your store's homepage, and look at the response Headers section.
Step 3: Map of installed modules
This is information attackers are willing to pay for. PrestaShop modules load their assets (CSS, JS, images) from dedicated directories, e.g. /modules/module_name/. These paths are visible in the page source code for anyone who clicks "View Page Source".
In under a minute, a script builds a list of dozens of modules installed in your store, then automatically compares it against a database of known vulnerabilities (CVE).
Step 4: Checking the admin panel URL
The default admin login URL in PrestaShop is the /admin directory with a random suffix generated during installation - for example /admin4x7k2/. The problem is that many installations, especially those migrated from older versions or copied between environments by less experienced developers, retain predictable names. A bot checks hundreds of the most popular combinations in a fraction of a second.
What does an attacker see in 30 seconds?
After performing a basic, completely passive scan, the script generates a ready report on your store:
PrestaShop version: extracted from changelog files or meta tags.
PHP version: read from the X-Powered-By header (if not disabled).
Module list: extracted from the page's source code.
Admin URL status: whether it's default or custom.
SSL status: whether HTTPS is strictly enforced.
Debug mode: whether the store is running in developer mode (a critical error that exposes server file paths and error details).
None of this information requires breaking in. All of it is publicly available.
Most common vulnerabilities in PrestaShop modules - what CVE data shows
The Friends of Presta Security project regularly collects and publishes vulnerabilities specific to this ecosystem. Looking through their database, a clear pattern emerges: the vast majority of critical flaws don't affect the PrestaShop core, but third-party modules.
The most common attack types are:
SQL Injection: the ability to execute arbitrary database queries through a crafted URL or malicious form.
XSS (Cross-Site Scripting): injecting malicious JavaScript code visible to store users.
Path Traversal: unauthorized access to files outside the public web directory.
CSRF: forcing a logged-in administrator to perform unwanted actions in the background.
Key observation: module vulnerabilities often remain active for months or even years after discovery. Why? Because store owners simply don't know that the plugin they paid for two years ago now has an official status of "critical vulnerability".
💡 Not sure whether your store's modules have publicly known CVE vulnerabilities? Run the free scanner and check in minutes.
What happens after a successful attack?
E-commerce owners often picture an attack as a dramatic event - a sudden security alarm, a big red "site hacked" message on the homepage, and an immediate halt to sales. The reality is far more insidious, because successful attacks go unnoticed for weeks.
Phishing and spam redirects. Malicious code in the background redirects only mobile users or traffic coming from Google to completely different, external sites. You see the store normally because you log in from a fixed IP address the script skips. The result? A drastic drop in organic traffic, a Google penalty, and frustrated customers.
Bank account number substitution. For traditional bank transfer payments, a malicious script replaces your bank account number directly on the order summary screen. The customer pays - but to the attacker's account. You find out only when impatient customers start calling about orders they've paid for.
Customer database theft. A database containing email addresses, phone numbers, passwords, and purchase history ends up on the black market. Under GDPR you are the data controller and bear full responsibility for the leak, even as a victim.
Cryptocurrency mining. Your server gets conscripted into mining cryptocurrency for the attacker. The effects include a dramatic spike in CPU usage, severe slowdown of the store, massive cloud bills, and in extreme cases - account suspension by the hosting provider.
7 things you can do today
Change the admin panel URL. If your back-office is at a predictable path, change it immediately. In PrestaShop this is done by renaming the /admin directory on the server and a minor configuration update.
Enforce HTTPS across the entire domain. Encryption must work not just at checkout and login, but on every single page. Go to: Preferences > General and enable SSL enforcement.
Remove informational files. Files like CHANGELOG.txt, INSTALL.txt and the entire /install/ directory must not be publicly accessible. Block access via .htaccess or physically delete them from the production server.
Hide the PHP version in headers. In your php.ini configuration file set
expose_php = Off. In your web server settings (Apache/Nginx), disable the ServerTokens and ServerSignature options.Update all modules. It sounds obvious, but the statistics are brutal: vulnerabilities in outdated plugins are the most common attack vector across the entire PrestaShop ecosystem.
Enable CVE monitoring. Manually checking dozens of modules every month is an unrealistic task. Invest in an automated tool that will alert you immediately when a critical vulnerability is discovered in any add-on you use.
Set up an external backup. If an attacker takes control of your server, local backups stored on the same machine become useless. Your backup must go to a completely isolated cloud location.
Summary
Attackers don't choose their victims manually. Their scripts work at scale, automatically scanning the web for stores with a specific combination of software and known vulnerabilities. Your online store is neither "too small" nor "too obscure" to become a target.
The good news? Most break-ins can be prevented by applying basic technical and architectural hygiene. The bad news is that security is an ongoing process, not a one-time click in the panel.
If you'd rather focus on sales and business growth instead of monitoring logs, tracking CVE databases, and updating modules - check out my SLA technical care offer or contact me directly. I'd be happy to discuss the technical security of your e-commerce store.
FAQ - Frequently Asked Questions
Is my PrestaShop 8 store also at risk?
Yes. Although the PrestaShop 8 core has far more modern security policies than version 1.7, vulnerabilities in third-party modules affect all versions. Every module is a separate product with its own, often imperfect, lifecycle and update cycle.
How can I check if my store has already been scanned or attacked?
Start by carefully reviewing your server access logs. Look for suspicious HTTP requests to non-standard paths (e.g. attempts to access /vendor/, /config/) and an unusually high number of 404 errors from a single IP address in a short time. It's also worth checking the modification dates of .php files on the server for any unauthorized changes.
Is an SSL certificate enough to keep my store secure?
Absolutely not. SSL only protects data in transit - securing the connection between the customer's browser and your server. It does not protect against vulnerabilities in application code, outdated modules, or weak admin panel passwords.
How much does it cost to fix a store after a successful attack?
It all depends on the scale of the breach. Simply removing malicious code and restoring the site typically takes 4 to 16 hours of an experienced developer's time. Add to that a security audit, database integrity analysis, and rotation of all API keys and passwords. If customer data was leaked, add serious legal costs, mandatory reporting to the supervisory authority, and potential financial penalties. Professional, ongoing technical care that prevents such crises is always many times cheaper.
