Un simple formulaire de mon site a servi de porte d’entrée
Un formulaire de contact, de devis ou de calcul de prix reste une zone où n’importe qui écrit ce qu’il veut, sans compte et sans mot de passe : c’est pour cette raison qu’il figure parmi les composants les plus attaqués de l’écosystème WordPress.
Un champ de formulaire est une entrée non authentifiée par nature
Un formulaire public est le seul endroit du site où n’importe qui, sans compte et sans mot de passe, écrit des données que votre serveur va traiter. Le back-office est protégé par une authentification, l’API demande une clé, l’accès FTP demande des identifiants. Le formulaire de contact, lui, est ouvert par définition : c’est sa fonction même. Le marchand le range mentalement du côté du contenu, à côté d’un bloc de texte ou d’une image, alors qu’il appartient au code exécuté.
Ce classement mental explique la suite. Le formulaire n’apparaît pas dans la liste des composants sensibles, il n’est pas mis à jour en priorité, sa version n’est pas suivie. Or les chiffres publiés par Patchstack pour 2025 attribuent 91 % des vulnérabilités de l’écosystème WordPress aux extensions, contre 9 % aux thèmes et six seulement au cœur. Et le rapport annuel de Wordfence sur 2024 indique que les défauts d’autorisation manquante représentent 73 % des vulnérabilités exploitables sans authentification. Autrement dit : l’essentiel de ce qui s’exploite sans compte tient à un contrôle d’accès absent, exactement le type de contrôle qu’un formulaire public n’a pas par construction.
Ce qui doit vous alerter autour d’un formulaire
- Un compte administrateur que vous n’avez pas créé apparaît dans la liste des utilisateurs.
- Des fichiers PHP inconnus apparaissent dans le dossier des envois ou dans celui de l’extension de formulaires.
- Le site envoie des e-mails que vous n’avez pas écrits.
- Les journaux montrent des requêtes répétées vers le point de traitement du formulaire, à un rythme qu’aucun visiteur humain ne produit.
- Une fonctionnalité avancée du formulaire — un calcul, une condition — se comporte différemment d’avant.
- Le formulaire renvoie des erreurs ou des pages blanches sans qu’aucune modification n’ait été faite.
Formulaire simple, formulaire à logique : ce qui change
Un formulaire simple collecte des chaînes de caractères, les envoie par e-mail et les enregistre. Un formulaire à logique fait davantage : il calcule un total, applique des conditions, affiche ou masque des champs selon les réponses, construit un devis à la volée. Pour cela, il doit interpréter ce que le visiteur a saisi, et c’est cette interprétation qui crée le risque. Plus une extension évalue la saisie au lieu de simplement la stocker, plus la surface exposée est large.
Le cas d’Everest Forms Pro l’illustre exactement. CVE-2026-3300, score CVSS 9,8 : exécution de code PHP arbitraire sans authentification, via la fonctionnalité de calcul complexe des formulaires. Les données du formulaire étaient nettoyées avec sanitize_text_field(), qui n’échappe pas les caractères ayant un sens pour la syntaxe PHP ; le résultat était ensuite évalué par eval(). Les versions 1.9.12 et antérieures sont concernées.
La chronologie est aussi instructive que la faille. Signalement par le chercheur h0xilo en février 2026. Correctif publié le 18 mars 2026. Exploitation active à partir du 13 avril 2026. Wordfence a bloqué plus de 29 300 tentatives d’exploitation, et un indicateur de compromission a été publié : un compte administrateur nommé diksimarina. Près d’un mois sépare donc le correctif de l’exploitation de masse. C’est du temps offert à un marchand qui suit ses mises à jour — à condition de savoir quelle version tourne réellement sur son site.
Ce que je vérifie sur un site après ce type de publication
-
Identifier l’extension de formulaires et sa version
Le nom exact et le numéro de version, pas « le formulaire de contact ». Beaucoup de sites hébergent deux extensions de formulaires, dont une installée par le thème et jamais utilisée : c’est celle-là qui pose problème, parce que personne ne la met à jour.
-
Confirmer que la version installée est postérieure au correctif
Sur Everest Forms Pro, la ligne de partage est nette : les versions 1.9.12 et antérieures sont concernées, le correctif date du 18 mars 2026. Attention aux éditions Pro, qui se mettent à jour par un canal séparé souvent lié à une licence expirée : l’extension peut afficher « à jour » sans l’être.
-
Lister les fonctionnalités avancées réellement utilisées
Calculs, champs conditionnels, envoi de fichiers, logique dynamique. Ce qui n’est pas utilisé peut presque toujours être désactivé, et une fonctionnalité désactivée réduit la surface exposée même quand une faille la concerne directement.
-
Relire les journaux sur la période d’exposition
Je prends comme borne la date du correctif et je remonte plus loin si l’extension avait déjà du retard. Je cherche des requêtes répétées vers le point de traitement du formulaire, des créations de comptes, et des écritures de fichiers dans les dossiers d’envoi.
-
Vérifier les comptes à privilèges et les fichiers déposés
Je compare la liste des administrateurs à ce qui est attendu, puis je cherche les fichiers PHP récents dans les dossiers d’envoi et d’extension. Un correctif appliqué après une exploitation ne retire jamais ce qui a été déposé avant : la mise à jour ferme la porte, elle ne fait pas le ménage.
Pour aller plus loin
-
Surveiller les failles qui concernent ma boutique
Où suivre les publications de failles pour repérer celles qui touchent vos extensions.
-
Vérifier si mon site est compromis
Les contrôles à faire quand une faille publiée concerne une extension que vous utilisez.
-
Modules et extensions abandonnés
Pourquoi le composant que personne ne met à jour reste le premier vecteur réel.
-
Vérifier ses extensions avant une mise à jour
La méthode pour appliquer un correctif sans casser le site en production.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.