Ce que les attaquants ciblent vraiment sur PrestaShop : 1,1 million d'attaques réelles analysées

La plupart des conseils de « sécurité PrestaShop » sont écrits depuis l’imagination du défenseur — une liste de choses qui pourraient mal tourner. Nous voulions l’inverse : une mesure de ce qui arrive réellement à une boutique PrestaShop en production, dans la nature, en ce moment même. Nous avons donc instrumenté notre propre flotte et compté.

Nous exploitons et défendons plusieurs boutiques PrestaShop en production, et depuis plus d’une décennie nous avons construit et maintenu un vaste catalogue de modules PrestaShop. Cela nous a donné ce dont manquent la plupart des analyses de sécurité : un ensemble de véritables vitrines actives, et l’autorisation d’observer chaque requête hostile qui les frappe. Pendant six semaines, nous avons enregistré chaque requête malveillante — pas seulement celles qui ont réussi, ni seulement celles visant des logiciels que nous utilisons réellement. Si un bot sondait un module que nous n’avons même pas installé, nous l’avons quand même enregistré, car l’objectif était d’obtenir une image honnête et complète de la pression subie par une boutique ordinaire.

Le total s’est élevé à environ 1,1 million de requêtes malveillantes provenant de plus de 13 300 adresses IP distinctes. Voici ce que les attaquants cherchaient réellement — et, pour chaque constat, exactement quoi faire.

Première vérité : environ 99 % de ce trafic est du bruit

La chose la plus importante à comprendre est la forme du trafic. L’écrasante majorité — bien plus d’un million de requêtes — est de la reconnaissance automatisée : des scanners de masse qui parcourent Internet, envoyant les mêmes charges utiles toutes prêtes à chaque IP qu’ils peuvent atteindre, indifférents au fait que vous utilisiez PrestaShop, WordPress ou une application Java.

C’est à la fois rassurant et dangereux. Rassurant, parce que presque tout cela rebondit sur une boutique à jour et bien configurée. Dangereux, parce que ce mur de bruit est exactement là où se cache une tentative ciblée. La pointe véritablement acérée est réelle mais réduite — de l’ordre de 34 000 sondes d’injection SQL et de quelques milliers de tentatives d’exécuter du code directement sur le serveur — une fine tranche enfouie dans un million de requêtes de bruit de fond. Si vous scrutez des journaux d’accès bruts à l’œil, vous ne repérerez jamais de façon fiable la seule requête qui compte. C’est tout l’argument en faveur d’une détection structurée plutôt que du « je vérifierai les journaux si quelque chose me paraît anormal ».

Voici la même image, ventilée par objectif.

Ils s’en prennent d’abord à vos secrets

En pur volume, l’objectif le plus bruyant n’était pas du tout l’exploitation. C’était le vol d’identifiants à la pelle : plus de 220 000 requêtes tentant de télécharger des fichiers secrets — .env et sa dizaine de variantes (.env.local, .env.production, .env.backup, /api/.env, et ainsi de suite), ainsi que .git/config, des fichiers de configuration de framework et des identifiants mis en cache.

La logique est d’une efficacité brutale. Pourquoi écrire un exploit quand un serveur mal configuré va tout simplement livrer le mot de passe de la base de données, la clé d’API de paiement et les identifiants de messagerie dans un fichier en clair ? Un seul .env qui fuite suffit souvent à tout perdre — aucune vulnérabilité requise, juste un répertoire qui n’était jamais censé être public mais qui l’est.

Quoi faire : assurez-vous absolument que votre serveur web refuse de servir les fichiers cachés (dotfiles) et de configuration. Ils doivent renvoyer un 403 ou un 404 depuis la périphérie, et non leur contenu. C’est un changement de cinq minutes qui neutralise l’objectif le plus courant que nous ayons enregistré :

# Place these ABOVE your generic PHP handler - nginx matches location blocks in order
# Never serve dotfiles (except ACME) or config/secret files
location ~ /\.(?!well-known/) { deny all; }

location ~* \.(env|git|bak|old|dist|sql|log|lock)$ { deny all; }

location ~* /(composer\.(json|lock)|package(-lock)?\.json|yarn\.lock)$ { deny all; }

# PrestaShop config/credential files (all supported versions)
location ~* /(settings\.inc\.php|parameters\.(php|ya?ml))$ { deny all; }

# Block dotfiles and config/secret files
RedirectMatch 404 /\.(?!well-known)

<FilesMatch "\.(env|git|bak|old|dist|sql|log|lock)$">
    Require all denied
</FilesMatch>

<FilesMatch "^(composer\.(json|lock)|package(-lock)?\.json|yarn\.lock)$">
    Require all denied
</FilesMatch>

# PrestaShop config/credential files (all supported versions)
<FilesMatch "^(settings\.inc\.php|parameters\.(php|ya?ml))$">
    Require all denied
</FilesMatch>

Le composant le plus ciblé : un module abandonné

Lorsque nous avons filtré les attaques visant spécifiquement PrestaShop, une cible écrasait toutes les autres : une faille d’inclusion de fichier local (LFI) dans un ancien module de blog qui n’est plus maintenu — environ 32 000 tentatives, plus que toutes les autres vulnérabilités de modules réunies.

C’est le schéma qui détruit silencieusement les boutiques. Ce n’est presque jamais le cœur de PrestaShop qui laisse entrer les attaquants. C’est le module tiers que vous avez installé il y a trois ans, que vous avez cessé de mettre à jour et dont vous aviez oublié l’existence. Les attaquants tiennent à jour des listes soignées de ces modules — nom du module, chemin vulnérable, exploit prêt à l’emploi — et les diffusent en boucle sur tout Internet.

Plus bas dans la liste figuraient les suspects habituels : des sondes d’injection SQL contre des modules de formulaire de contact et de newsletter, une vulnérabilité connue dans un module de liste de souhaits, et une poignée de modules de slider et de recherche. Tous tiers. Tous du genre à s’accumuler dans une boutique au fil des ans, puis à rester là, non corrigés, longtemps après que quiconque se souvienne les avoir installés.

Quoi faire : faites l’inventaire de vos modules et supprimez ceux que vous n’utilisez pas — un module installé mais inutilisé n’est que de la surface d’attaque, sans aucun bénéfice. Corrigez ceux que vous gardez, et si le développeur a disparu, remplacez le module plutôt que d’espérer. Si vous êtes bloqué sur une version que vous ne pouvez pas mettre à niveau en toute sécurité, notre guide sur le durcissement d’une boutique que vous ne pouvez pas mettre à niveau explique comment corriger virtuellement exactement ce type de faille.

Le kit d’effraction : webshells et backdoors

Au-delà de la reconnaissance et de la chasse aux secrets se trouve la pointe acérée. Les attaquants ont tenté à plusieurs reprises de déposer ou de localiser des webshells — les outils qui transforment une simple vulnérabilité en contrôle total à distance. Les noms de fichiers sont presque une signature en eux-mêmes : adminer.php, alfa.php, wso.php, des sondes phpinfo éparses, et des scripts de gestion de base de données laissés par une compromission antérieure.

Nous avons aussi surpris quelque chose de plus ciblé que le scan générique. Lorsqu’une boutique d’un groupe est compromise, les attaquants reprennent la charge utile exacte qui a fonctionné là-bas et la diffusent sur chaque boutique liée qu’ils peuvent trouver, pariant que la même backdoor est encore présente sur une autre. La persistance paie : une backdoor enfouie dans un fichier rarement inspecté peut survivre à plusieurs « nettoyages » superficiels et continuer à réinfecter une boutique pendant des semaines. Si vous avez déjà nettoyé une compromission en ne supprimant que le JavaScript malveillant visible et qu’elle est revenue, c’est pourquoi — nous avons détaillé exactement cet échec dans notre anatomie d’un skimmer de type Magecart.

Quoi faire : interdisez l’exécution de PHP dans chaque répertoire qui ne devrait jamais contenir que des téléversements, des images, du cache ou des outils. Si un bot parvient à écrire shell.php dans votre dossier d’images, la différence entre une mauvaise journée et une compromission totale tient simplement au fait que le serveur va ou non l’exécuter :

# Put this ABOVE your existing "location ~ \.php$" block - nginx is first-match-wins
# A bot that writes shell.php into an image folder must never get it executed
location ~* ^/(img|upload|uploads|cache|var|download)/.*\.(php|phar|phtml|php[0-9])$ {
    deny all;
}

# Drop this .htaccess inside an uploads folder: turn PHP off for the whole tree
<FilesMatch "\.(php|phar|phtml|php[0-9])$">
    Require all denied
</FilesMatch>

Ils ne vérifient même pas ce que vous utilisez

Une illustration révélatrice du degré d’automatisation de tout cela : nous avons enregistré des dizaines de milliers de tentatives d’exploit visant des stacks technologiques totalement différentes — des charges utiles Java et JSF, des exploits de plugins WordPress, des astuces ASP.NET — toutes envoyées à l’aveugle sur des boutiques PHP qui ne pourraient jamais y être vulnérables.

La leçon n’est pas « ha, ils se sont trompés ». C’est l’inverse : vous êtes attaqué en permanence, par des attaquants qui ne savent ni ne se soucient de ce que vous utilisez. Vous n’avez pas besoin d’être une cible pour être une victime. Il suffit d’être joignable et obsolète.

Vérifiez votre propre boutique dès maintenant

En lire la théorie est une chose ; voici quatre vérifications que vous pouvez lancer sur votre propre boutique dans les cinq prochaines minutes. Elles correspondent exactement à ce que les attaquants ci-dessus recherchent.

1. Vos secrets sont-ils réellement accessibles ? Depuis votre propre machine, demandez les fichiers que les scanners réclament. Chaque ligne devrait renvoyer 403 ou 404 — jamais 200 avec du contenu :

# From your own machine: 403/404 = safe, 200 = exposed, 000 or 3xx = check by hand
for f in .env .git/config app/config/parameters.php composer.json; do
  printf '%s -> ' "$f"
  curl -s -o /dev/null --connect-timeout 5 --max-time 15 -w '%{http_code}\n' "https://your-store.com/$f"
done

2. Y a-t-il du PHP caché là où seuls des fichiers statiques devraient se trouver ? En SSH, depuis la racine de votre boutique, cherchez les fichiers exécutables dans des dossiers censés ne contenir que des envois et des images. Cela ne devrait rien afficher :

# PHP hiding in folders that should only hold assets (a clean store prints nothing)
find img upload uploads download -type f \
  \( -iname '*.php' -o -iname '*.php[0-9]' -o -iname '*.phtml' -o -iname '*.phar' \) \
  ! -iname index.php 2>/dev/null

3. Qu’est-ce qui a changé récemment ? Une porte dérobée fraîchement déposée est un fichier PHP récemment modifié que vous n’avez pas touché. Listez les modifications de la dernière semaine et examinez tout ce qui vous semble inconnu :

# PHP changed in the last 7 days, cache excluded (GNU/Linux find) - review anything unfamiliar
find . \( -path ./var/cache -o -path ./cache \) -prune -o \
  -type f -iname '*.php' -mtime -7 -printf '%TY-%Tm-%Td  %p\n' | sort

4. Qui peut se connecter à votre back-office ? Chaque compte est une clé de votre porte d’entrée. Enquêtez sur tout employé que vous ne reconnaissez pas, ainsi que sur tout compte qui ne s’est pas connecté depuis des mois :

-- Back-office accounts: investigate any you do not recognise
-- Run in phpMyAdmin or the mysql client; change the ps_ prefix if yours differs
SELECT id_employee, email, active, last_connection_date
FROM ps_employee
ORDER BY last_connection_date DESC;

Ce que nous faisons réellement sur nos propres boutiques

Parce que ce sont aussi nos vitrines, la liste défensive ci-dessus n’a rien de théorique. Sur les boutiques de cette étude, nous bloquons les dotfiles et les fichiers de configuration à la périphérie, nous interdisons l’exécution de PHP sur chaque chemin accessible en écriture, nous maintenons une empreinte de modules délibérément réduite et supprimons tout ce qui est inutilisé, nous imposons l’authentification à deux facteurs sur l’admin, et nous plaçons l’ensemble derrière une couche périphérique qui limite le débit des scanners et rejette les charges utiles d’injection évidentes. Et nous gardons l’enregistreur en marche — la même journalisation au niveau des requêtes qui a produit cet article — pour qu’une tentative véritablement ciblée émerge au lieu de se noyer dans les 99 % de bruit. Rien de tout cela n’est exotique. Tout est ennuyeux, et l’ennuyeux, c’est ce qui marche.

• Bloquez les fichiers secrets à la périphérie. .env, .git, composer.json et les fichiers de configuration doivent renvoyer un 403/404 — jamais leur contenu.
• Élaguez vos modules. Supprimez tout ce que vous n’utilisez pas ; un module inutilisé n’est que de la surface d’attaque.
• Corrigez ou remplacez ce que vous gardez. En particulier les modules tiers de blog, de slider, de formulaire et de recherche.
• Interdisez PHP dans les dossiers accessibles en écriture. Les téléversements, images, cache et tmp ne doivent jamais exécuter de code.
• Verrouillez la connexion admin. Des identifiants forts et uniques, et l’authentification à deux facteurs.
• Restez sur une version prise en charge. Une plateforme en fin de vie est livrée avec un jeu permanent de clés connues.
• Placez une détection entre vous et le bruit pour que le 1 % qui compte ne puisse pas se cacher dans les 99 % qui ne comptent pas.

Questions fréquentes

En résumé

Une fois le volume écarté, l’image est simple. Les attaques qui réussissent ne reposent presque jamais sur un exotique zero-day. Elles reposent sur l’ennuyeux : un fichier secret resté lisible, un module tiers non corrigé ou abandonné, un répertoire qui exécutera un fichier PHP téléversé, une connexion admin avec un mot de passe faible ou réutilisé, une plateforme obsolète. Rien de tout cela n’est difficile à corriger. Tout cela relève de ce qu’une boutique maintenue fait bien et qu’une boutique négligée fait mal. Les attaquants ont automatisé la recherche de la négligence — un million de fois en six semaines. La seule véritable défense est de ne pas être négligé : corrigez, élaguez, verrouillez les portes évidentes, et placez une véritable détection entre vous et ce mur de bruit.

Note méthodologique : les chiffres sont agrégés à partir d’une journalisation des attaques au niveau des requêtes, sur plusieurs boutiques en production, pendant une fenêtre d’environ six semaines s’achevant en juillet 2026. Toutes les données sont anonymisées ; aucun détail de boutique, de client ou d’identifiant n’est inclus, et aucune spécificité d’exploit n’est publiée.