# Les injections SQL : ce que c’est, comment savoir si vous êtes concerné

> C’est la faille la plus fréquemment exploitée contre les boutiques en ligne, parce qu’elle touche directement la base de données : commandes, clients, mots de passe. Voici ce qu’elle est réellement, sans jargon inutile.

- Source canonique : [https://allaux.fr/securite/injections-sql-expliquees](https://allaux.fr/securite/injections-sql-expliquees)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Commencez par un inventaire de versions plutôt que par un test : version du cœur, puis version de chaque module qui affiche des filtres, une recherche ou une liste paramétrée par l’adresse. Comparez-les aux avis publiés par l’éditeur. Regardez ensuite le journal d’accès de l’hébergeur : des requêtes répétées vers la même adresse, à un rythme qu’aucun visiteur ne produit, méritent d’être conservées.

## Le principe, sans jargon

Un site e-commerce construit en permanence des requêtes vers sa base de données : afficher une fiche produit, valider une connexion, enregistrer une commande. Ces requêtes intègrent souvent une information saisie par le visiteur, comme un identifiant de produit dans l’adresse, un terme recherché ou un champ de formulaire.

Une injection SQL survient quand cette information n’est pas suffisamment filtrée avant d’être intégrée à la requête. Le contenu saisi ne reste alors plus une simple donnée : il peut modifier le sens de la requête elle-même, et faire dire à la base de données autre chose que ce qui était prévu par le développeur du site ou du module.

C’est pour cette raison que cette faille est prise très au sérieux : elle touche directement la base de données, c’est-à-dire les commandes, les fiches clients et, selon la configuration, les mots de passe stockés.

## Ce que cette page n’explique pas

> Vous ne trouverez ici aucune syntaxe d’attaque, aucun exemple de requête détournée et aucune méthode pour tester une injection sur un site. L’objectif est de comprendre le principe et de vérifier une exposition, pas de fournir un outil d’intrusion.

## Trois failles réelles pour comprendre le mécanisme

CVE-2022-36408 (référencée aussi sous CVE-2022-31181), divulguée le 22 juillet 2022, concernait le cœur de PrestaShop des versions 1.6.0.10 à 1.7.8.6 incluses, et est corrigée depuis la 1.7.8.7. Elle ne s’exploitait qu’en la chaînant à une injection SQL présente ailleurs sur la boutique, dans le cœur ou dans un module : le module de liste de souhaits blockwishlist en versions 2.0.0 à 2.1.0 en fournissait une (CVE-2022-31101, corrigée en 2.1.1).

CVE-2024-36680 touchait pkfacebook, un module tiers premium d’intégration Facebook pour PrestaShop. Les analystes de TouchWeb l’ont identifiée le 3 mars 2024 : elle pouvait être exploitée par un simple visiteur non connecté, et a servi à déployer des « skimmers » de paiement, c’est-à-dire du code destiné à intercepter les données de carte bancaire saisies sur le site.

CVE-2024-27956 concernait l’extension WordPress « WordPress Automatic » de l’éditeur ValvePress, publiée le 21 mars 2024. L’injection se situait dans le processus d’authentification lui-même et a été exploitée activement dès sa divulgation pour prendre le contrôle de sites.

## Comment savoir si vous êtes concerné

1. **Identifier votre version de cœur** — Sur PrestaShop, la version s’affiche dans le back-office. Une boutique restée sur une version antérieure à 1.7.8.7 sans avoir vérifié ses modules mérite un contrôle, en particulier si le module blockwishlist est installé.
2. **Vérifier les modules premium installés** — Les modules tiers, notamment ceux liés à des intégrations comme Facebook, doivent être vérifiés individuellement : leur version, leur éditeur, et si une faille connue les concerne, indépendamment de la version du cœur PrestaShop.
3. **Vérifier les extensions WordPress d’automatisation** — Si votre site WordPress utilise WordPress Automatic ou une extension similaire qui manipule le contenu automatiquement, vérifiez sa version auprès de l’éditeur avant de considérer le site comme à jour.
4. **Chercher les conséquences, pas seulement la cause** — Un compte administrateur inconnu, des commandes ou des comptes clients créés en série, ou des données de paiement suspectes peuvent être la conséquence visible d’une injection SQL déjà exploitée.

## Pour aller plus loin

- **Modules et extensions abandonnés** — Pourquoi un module non mis à jour reste souvent la porte d’entrée, même après la publication d’un correctif. ([/securite/modules-et-extensions-abandonnes](/securite/modules-et-extensions-abandonnes))
- **Vérifier si mon site est compromis** — Les vérifications gratuites à faire avant d’envisager un audit payant. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Sécurité et nettoyage de site piraté** — Le service complet si une injection SQL a déjà été exploitée sur votre boutique. ([/services/securite](/services/securite))

## Réduire l’exposition

> Maintenir le cœur et les modules à jour, limiter les privilèges du compte de base de données utilisé par le site au strict nécessaire, et n’installer que des modules provenant d’éditeurs identifiables restent les mesures les plus efficaces contre ce type de faille.

## FAQ

### Une injection SQL peut-elle exposer les mots de passe de mes clients ?

Oui si les mots de passe sont mal protégés dans la base, mais la plupart des CMS récents les stockent sous forme hachée, ce qui limite l’usage direct des données récupérées. Le risque reste réel pour les autres informations : commandes, adresses, données de paiement selon la configuration.

### Comment savoir si mon site a déjà été touché par une de ces failles ?

Je vérifie les traces dans les journaux d’accès au serveur, la présence de comptes administrateur ou de commandes créés en dehors de toute activité normale, et je compare les versions installées aux failles publiquement connues.

### Un module payant est-il plus sûr qu’un module gratuit ?

Pas automatiquement. CVE-2024-36680 concernait un module premium. Ce qui compte est la rapidité de correction de l’éditeur et la rapidité avec laquelle la mise à jour est appliquée sur votre boutique.

### Faut-il un pare-feu applicatif pour se protéger de ce type de faille ?

Un pare-feu applicatif peut filtrer une partie des tentatives, mais il ne remplace jamais la mise à jour du code vulnérable lui-même : c’est une protection complémentaire, pas une solution en soi.

### Que faire si je découvre que je suis concerné par une des failles citées ?

Mettre à jour immédiatement le module ou le cœur concerné, puis vérifier si une exploitation a déjà eu lieu avant la mise à jour, ce qui nécessite un contrôle de la base de données et des fichiers du serveur.