Un avis de sécurité a été publié concernant un module complémentaire WordPress pour Contact Form 7, révélant qu’un attaquant non authentifié peut **facilement** provoquer une exécution de code à distance (RCE). Sur l’échelle de gravité CVSS, cette vulnérabilité obtient un score élevé de 8,8/10.
Screenshot from Wordfence advisory showing 8.8 CVSS severity ratingVulnérabilité dans Redirection for Contact Form 7
Le problème concerne le plugin Redirection for Contact Form 7, qui est utilisé par plus de 300 000 sites WordPress. Ce module étend les possibilités du populaire plugin Contact Form 7 en permettant, entre autres, de rediriger un utilisateur après l’envoi d’un formulaire, d’enregistrer les données dans une base de données, d’envoyer des notifications par e‑mail et de filtrer des soumissions indésirables.
La faille se situe dans une fonction interne du plugin. Dans l’écosystème WordPress, une fonction PHP permet d’exécuter une tâche précise ; la fonction vulnérable se nomme delete_associated_files. Elle présente une validation insuffisante des chemins de fichiers, ce qui signifie qu’elle ne vérifie pas correctement les entrées fournies par l’utilisateur avant de supprimer un fichier sur le serveur.
Concrètement, un attaquant peut indiquer un chemin relatif ou absolu (par exemple ../../wp-config.php) pour ordonner la suppression d’un fichier critique comme wp-config.php. La suppression d’un fichier essentiel ouvre la voie à une attaque d’exécution de code à distance (RCE), qui permet à un tiers d’exécuter du code malveillant sur le serveur depuis n’importe quel endroit sur Internet et ainsi de prendre le contrôle du site.
L’avis de Wordfence détaille :
“This makes it possible for unauthenticated attackers to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php).”
La vulnérabilité concerne toutes les versions du plugin jusqu’à la version 3.2.4 incluse. Les administrateurs de sites utilisant ce module sont invités à appliquer les correctifs disponibles afin de réduire le risque d’exploitation.
Featured Image by Shutterstock/Everyonephoto Studio
Pourquoi la suppression d’un fichier peut mener à une exécution de code
Pour comprendre le risque, il est utile d’expliquer le rôle de certains fichiers critiques. Le fichier wp-config.php contient les paramètres de connexion à la base de données, les clés de sécurité et d’autres configurations essentielles à WordPress. Si ce fichier est supprimé ou corrompu :
- WordPress peut se retrouver en mode d’installation ou afficher des erreurs critiques.
- Un attaquant peut exploiter l’état dégradé du site pour injecter des scripts, créer des comptes administrateurs ou uploader des portes dérobées.
- La suppression d’autres fichiers sensibles (plugins, thèmes, fichiers de configuration) peut également être mise à profit pour obtenir un accès persistant au serveur.
La chaîne d’exploitation typique ressemble à ceci : exploitation de la vulnérabilité de suppression de fichiers → suppression ou altération d’un fichier critique → création d’un point d’entrée (upload, modification de fichiers exécutables) → exécution de code arbitraire. Parce que l’attaque peut commencer sans authentification, elle est particulièrement dangereuse sur des sites exposés publiquement.
Technique sous-jacente : traversal de chemin et validation insuffisante
La faille relève d’un problème classique : la validation insuffisante des chemins de fichiers, souvent appelée path traversal ou « traversée de répertoires ». Lorsqu’une application accepte un nom de fichier ou un chemin fourni par l’utilisateur et qu’elle s’en sert directement dans une opération de suppression (unlink, unlink function, etc.), un attaquant peut tenter d’échapper au répertoire autorisé en insérant des séquences comme ../.
Si le code ne normalise pas le chemin (par exemple via realpath()) et ne vérifie pas que le chemin résultant reste dans un répertoire autorisé, l’attaquant peut cibler des fichiers situés en dehors de l’espace prévu par le développeur. Dans ce cas précis, la fonction delete_associated_files n’empêche pas qu’un tel chemin soit fourni et traité, ce qui permet la suppression arbitraire.
Évaluation de la gravité (CVSS)
Un score CVSS de 8,8 indique une vulnérabilité de niveau « élevé ». Ce score tient compte de plusieurs facteurs : la facilité d’exploitation (aucune authentification requise), l’impact sur l’intégrité et la disponibilité (suppression de fichiers critiques), et la possibilité d’enchaîner sur une exécution de code. Dans la pratique, cela signifie que l’exploitation est réaliste et peut avoir des conséquences sévères pour les sites vulnérables.
Mesures recommandées pour les administrateurs de sites
Voici une série d’actions concrètes pour limiter l’exposition et corriger le problème sur les sites affectés. Il est conseillé d’appliquer plusieurs couches de protection plutôt que de se reposer sur une seule.
1. Mettre à jour ou corriger le plugin
La première mesure consiste à installer la version corrigée du plugin dès qu’elle est disponible. Les mainteneurs publient généralement une mise à jour qui corrige la validation des chemins ou retire la fonctionnalité problématique. Après la mise à jour, vérifiez que la version installée est bien postérieure à la dernière version affectée (supérieure à 3.2.4 dans ce cas).
2. Désactiver temporairement le plugin si la mise à jour n’est pas possible
Si une mise à jour immédiate n’est pas envisageable (contraintes techniques, tests en préproduction, etc.), envisagez de désactiver le plugin pour prévenir toute exploitation. La désactivation supprime l’accès à la fonctionnalité vulnérable et réduit le risque d’attaque automatisée.
3. Restreindre les permissions de fichiers
Limitez les permissions sur les fichiers sensibles. Veillez à ce que les fichiers de configuration, notamment wp-config.php, aient des permissions restrictives (par exemple 600 ou 640 selon la configuration du serveur) et appartiennent à l’utilisateur approprié. Les bonnes permissions réduisent l’impact d’une tentative de suppression via le code PHP si l’utilisateur système exécutant PHP n’a pas les droits nécessaires.
4. Sauvegardes et plan de restauration
Maintenez des sauvegardes régulières et testez votre procédure de restauration. Si un fichier critique est supprimé, une sauvegarde récente permettra de restaurer le site rapidement et d’éviter des interruptions prolongées. Conservez plusieurs points de restauration et archivez-les hors site.
5. Surveillance et détection d’intrusion
Déployez des systèmes de surveillance pour détecter des suppressions de fichiers ou des modifications inattendues. Des outils de détection d’intégrité (par exemple, en comparant des sommes de contrôle) et des solutions WAF peuvent alerter en cas d’activité suspecte. Analysez régulièrement les journaux d’accès (access logs) et d’erreurs pour repérer des requêtes anormales ciblant le plugin.
6. Filtrage d’URL et WAF
Un pare‑feu applicatif web (WAF) peut bloquer des motifs d’attaque connus comme les tentatives de traversal (« ../ ») ou les requêtes malformées visant les endpoints du plugin. Certains WAF proposent des règles prêtes à l’emploi pour protéger WordPress et ses extensions populaires.
7. Restreindre l’accès aux endpoints sensibles
Si la logique du plugin est exposée via des endpoints REST ou admin-ajax, limitez l’accès à ces endpoints par IP, authentification ou autres contrôles d’accès. Protégez l’interface d’administration (wp-admin) en ajoutant une couche d’authentification ou en limitant l’accès par adresse IP si possible.
Conseils pour les développeurs WordPress
La vulnérabilité illustre des erreurs fréquentes dans la gestion des fichiers et des entrées utilisateur. Voici des bonnes pratiques à suivre pour éviter ce type de faille :
Validation stricte des chemins
Ne jamais utiliser directement un chemin fourni par l’utilisateur pour effectuer des opérations de fichier. Au minimum :
- Normaliser le chemin avec
realpath()et vérifier qu’il réside bien dans un répertoire autorisé. - Utiliser des listes blanches de fichiers ou d’extensions autorisées.
- Appliquer
basename()ousanitize_file_name()pour réduire les caractères spéciaux et les séquences de traversée.
Utiliser les API WordPress
Préférer les fonctions et API fournies par WordPress, comme le WP Filesystem API, qui encapsulent des opérations de fichiers avec des contrôles supplémentaires et une meilleure portabilité entre environnements d’hébergement.
Vérifier les permissions et les capacités
Avant d’exécuter une action qui modifie l’état du site (suppression de fichier, modification de settings), vérifier que l’appel provient d’un utilisateur autorisé :
- Contrôler les capabilities via
current_user_can(). - Utiliser des nonces pour s’assurer que la requête provient d’un formulaire ou d’une source légitime.
Principe du moindre privilège
Le code serveur devrait être conçu pour agir avec le minimum de permissions nécessaires. Éviter que le processus PHP ait des droits globaux d’écriture sur l’ensemble du système de fichiers. Sur les serveurs bien configurés, PHP ne doit pouvoir écrire que dans les répertoires nécessaires (uploads, cache temporaire, etc.).
Journalisation et reporting
Ajoutez des traces et des logs lorsque des opérations sensibles sont exécutées (suppression, écriture, changement de permissions). Ces logs facilitent l’analyse post‑incident et la détection d’anomalies.
Comment vérifier si votre site a été compromis
Après publication d’une vulnérabilité de ce type, il est essentiel de vérifier l’intégrité de votre site. Voici des étapes d’investigation :
1. Examiner les journaux d’accès
Recherchez des requêtes suspectes vers des endpoints liés au plugin ou contenant des séquences de traversal (../). Notez les adresses IP, les horaires et la fréquence des requêtes.
2. Scanner les fichiers modifiés
Comparez l’arborescence et les sommes de contrôle (SHA1/MD5) des fichiers actuels avec une sauvegarde fiable. Recherchez des fichiers PHP récemment modifiés, surtout dans les répertoires wp-content (plugins, thèmes, uploads).
3. Rechercher des comptes utilisateurs suspects
Vérifiez la liste des utilisateurs WordPress : un attaquant peut créer un compte avec des privilèges élevés. Contrôlez aussi les métadonnées utilisateurs à la recherche d’anomalies.
4. Inspecter la base de données
Examinez les tables liées aux options et aux plugins pour détecter des modifications inattendues. Cherchez des injections de code dans les champs stockés (par exemple dans wp_options ou des contenus HTML stockés).
5. Analyser les webshells et portes dérobées
Scannez le site à la recherche de webshells (fichiers PHP contenant fonctions d’exécution comme system(), exec(), passthru(), ou des eval base64).
Scénarios d’exploitation et exemples concrets
Pour mieux visualiser le risque, voici quelques scénarios plausibles :
Scénario A — suppression de wp-config.php puis injection
L’attaquant supprime wp-config.php. Le site bascule en mode d’installation ou renvoie des erreurs. L’attaquant exploite ce contournement pour uploader un script malveillant via un endpoint accessible (upload d’images, import CSV mal filtré) et exécute du code arbitraire.
Scénario B — suppression de fichiers d’un plugin critique
En supprimant un fichier d’authentification ou d’un plugin de sécurité, l’attaquant peut causer un dysfonctionnement, forcer la réinstallation ou exploiter un comportement par défaut qui facilite le remplacement ou la modification des fichiers du site.
Scénario C — suppression de sauvegardes locales
Certains sites conservent des sauvegardes dans des répertoires accessibles par le web. Un attaquant supprime ces sauvegardes pour éviter la restauration, augmentant ainsi l’impact de l’attaque et la dépendance à des actions manuelles pour la remise en état.
Communication et gestion d’incident
Si vous découvrez une compromission, documentez chaque étape prise : sauvegardes effectuées, fichiers restaurés, comptes modifiés, adresses IP suspectes. Communiquez de façon transparente aux parties prenantes concernées (équipe IT, hébergeur, clients si nécessaire) et collaborez avec des spécialistes en réponse aux incidents si la gravité l’exige.
Contenir, éradiquer, restaurer
Procédez selon le cycle classique :
- Contenir : isoler le site si nécessaire (mode maintenance, suspension d’accès) et couper les vecteurs d’attaque immédiats (désactivation du plugin vulnérable).
- Éradiquer : supprimer les backdoors, corriger les failles et rétablir les permissions.
- Restaurer : revenir à une version saine depuis des sauvegardes et appliquer les mises à jour.
Alternatives et solutions complémentaires
Pour limiter la dépendance à des plugins tiers, évaluez des alternatives robustes ou des solutions natives :
- Utiliser des plugins contact form bien maintenus et audités régulièrement.
- Privilégier des solutions dont le code est ouvertement audité par la communauté.
- Limiter le nombre de plugins actifs et supprimer ceux qui ne sont plus maintenus.
Conclusion
La vulnérabilité découverte dans Redirection for Contact Form 7 met en lumière une faiblesse fréquente : la mauvaise validation des chemins de fichiers. Étant donné la large diffusion de ce plugin (plus de 300 000 installations) et la possibilité d’exploitation sans authentification, le risque est réel et significatif. Les administrateurs doivent vérifier les versions installées, appliquer les correctifs disponibles, renforcer la sécurité de leur infrastructure et surveiller activement leurs sites.
Pour les développeurs, l’incident rappelle l’importance de règles strictes : validation des entrées, utilisation des APIs WordPress, vérification des capacités et permissions, et journalisation. Ces bonnes pratiques réduisent considérablement la probabilité d’introduire des vulnérabilités équivalentes à l’avenir.
