Faille PHP WordPress : vérifier et corriger son site

Comprendre ce qu’est une faille PHP WordPress

Le terme recouvre trois réalités différentes, qui ne se corrigent pas de la même façon.

Trois familles de failles, trois responsables

La première famille concerne la version de PHP installée sur le serveur. Chaque branche de PHP reçoit des correctifs de sécurité pendant une durée limitée ; au-delà, les vulnérabilités découvertes ne sont plus corrigées. Un site qui tourne encore sur PHP 7.4 ou 8.0 s’exécute sur un moteur qui n’a plus reçu de correctif depuis des années, et le changement de version dépend de l’hébergeur ou d’un simple réglage dans le panneau d’hébergement. La deuxième famille, de loin la plus fréquente, concerne le code PHP des extensions et des thèmes : une injection SQL dans un formulaire, un téléversement de fichier non vérifié, une fonction accessible sans authentification. Ces failles sont publiées chaque semaine dans les bases de vulnérabilités, avec le numéro de version corrigée, et exploitées par des robots dans les heures qui suivent. La correction est la mise à jour de l’extension concernée, ou sa suppression si elle n’est plus maintenue. La troisième famille regroupe les erreurs de configuration : édition de fichiers autorisée dans l’administration, exécution de PHP possible dans le dossier des médias, affichage des erreurs activé en production, droits de fichiers trop permissifs. Elles ne sont pas des bogues, mais elles transforment une petite faille en prise de contrôle complète. Le cœur de WordPress lui-même, régulièrement audité, mis à jour automatiquement et rarement à l’origine d’une faille PHP WordPress exploitée, représente une part marginale des incidents réels.

Faille PHP WordPress : ce que les robots exploitent vraiment

Les journaux d’accès d’un serveur racontent la même histoire partout : des centaines de requêtes quotidiennes, venues d’adresses du monde entier, qui testent l’existence de fichiers précis. /wp-content/plugins/nom-extension/readme.txt pour lire le numéro de version, puis une requête POST vers le fichier vulnérable si la version correspond. Le robot ne sait rien de votre site ; il parcourt une liste de millions de domaines avec une liste de failles connues, et il ne s’arrête que là où ça répond. Les cibles privilégiées sont les extensions installées sur des millions de sites : constructeurs de pages, formulaires de contact, galeries, outils de sauvegarde, extensions de commerce. Une seule vulnérabilité dans l’une d’elles ouvre des centaines de milliers de sites d’un coup, et les exploitations massives commencent souvent le jour même de la publication du correctif, parce que la comparaison entre la version corrigée et la précédente révèle exactement où frapper. Le délai entre la publication d’une faille et sa première exploitation automatisée se compte désormais en heures. Un site mis à jour une fois par mois est donc exposé en moyenne deux semaines par faille, ce qui suffit largement. C’est ce décalage, et non une faille PHP WordPress particulièrement astucieuse, qui explique la majorité des sites compromis.

Savoir si une faille PHP WordPress expose votre site

Trois vérifications, dix minutes, aucune compétence en développement.

Vérifier la version de PHP et son support

Dans l’administration WordPress, le menu Outils puis Santé du site affiche la version de PHP utilisée et signale si elle est obsolète. La même information se trouve dans le panneau de l’hébergeur, généralement dans une rubrique « Configuration PHP » ou « Sélecteur de version ». Le tableau ci-dessous résume l’état des branches courantes. Une branche en fin de vie n’est pas forcément exploitable immédiatement, mais chaque nouvelle vulnérabilité découverte dans PHP y restera ouverte définitivement. Le passage à une branche supportée se fait dans le panneau d’hébergement en un clic, et dans la grande majorité des cas, un site WordPress à jour fonctionne sans modification sur PHP 8.2 ou 8.3. Les exceptions sont les thèmes et extensions anciens, qui utilisent des fonctions supprimées ; ils se repèrent en testant le changement de version sur une copie du site, ou en consultant la compatibilité annoncée sur leur page officielle. Si une extension bloque le passage à une version supportée de PHP, c’est elle qui doit partir, pas la mise à jour.

Repérer les extensions vulnérables ou abandonnées

La liste des extensions installées, avec leur version, est la seconde vérification. Pour chacune, trois questions. La version installée est-elle la dernière ? Un retard de plusieurs versions sur une extension populaire signifie presque toujours qu’une faille connue est ouverte. L’extension est-elle encore maintenue ? Sur sa page officielle, une mention « n’a pas été testée avec les trois dernières versions majeures de WordPress » ou une dernière mise à jour vieille de plus de deux ans signale un abandon ; les failles découvertes ne seront jamais corrigées. L’extension sert-elle encore ? Une extension désactivée reste présente sur le disque et son code reste accessible directement par adresse, donc exploitable. Les bases de vulnérabilités publiques, comme celles de Patchstack ou de Wordfence, permettent de chercher le nom d’une extension et de voir les failles connues avec la version corrigée. Pour un site unique, ce contrôle prend un quart d’heure par mois. Pour une agence qui gère trente sites, c’est une demi-journée, ce qui explique pourquoi il n’est jamais fait à la main et pourquoi les outils de gestion de parc comparent automatiquement chaque version installée à la liste des failles publiées, et remontent les sites concernés chaque matin.

Contrôler les réglages qui aggravent tout

La troisième vérification porte sur la configuration. Ces réglages ne sont pas des failles à proprement parler, mais ils décident de ce qu’un attaquant peut faire une fois qu’il a trouvé une petite brèche. Voici les points à passer en revue, dans l’ordre d’importance.

• Exécution de PHP dans wp-content/uploads : si elle est possible, tout formulaire de téléversement vulnérable devient une prise de contrôle complète. Un fichier .htaccess de trois lignes dans ce dossier l’interdit.
• Éditeur de fichiers dans l’administration : un compte administrateur volé permet alors d’écrire du PHP directement. La constante DISALLOW_FILE_EDIT le désactive.
• Affichage des erreurs : en production, WP_DEBUG doit être à false, sinon les messages révèlent chemins et requêtes.
• Droits des fichiers : 644 pour les fichiers, 755 pour les dossiers, et jamais 777 ; wp-config.php peut descendre à 600.
• XML-RPC : à désactiver s’il ne sert pas, c’est un canal d’attaque par force brute et d’amplification.
• Préfixe de table et nom du compte : un compte « admin » et le préfixe wp_ par défaut facilitent les attaques automatisées.

Chacun de ces réglages se vérifie en une minute et se corrige en cinq. Ensemble, ils transforment une faille mineure, qui aurait permis de lire une table, en incident sans conséquence.

Lire les journaux pour voir qui frappe à la porte

Les journaux d’accès du serveur, disponibles dans le panneau d’hébergement ou dans le dossier logs, montrent en quelques minutes ce que les vérifications précédentes ne disent pas : si quelqu’un a déjà essayé, et par où. Filtrez les requêtes POST des sept derniers jours, puis repérez celles qui visent des fichiers d’extensions plutôt que des pages normales : admin-ajax.php avec une action inconnue, un fichier dans wp-content/plugins appelé directement, xmlrpc.php par centaines, wp-login.php depuis des dizaines d’adresses différentes. Les codes de réponse complètent le tableau : une série de 404 signale un robot qui cherche une extension que vous n’avez pas, un 200 sur un fichier d’extension appelé en direct signale qu’il l’a trouvée. Notez les adresses et les dates ; si une requête suspecte coïncide avec un fichier modifié ou un compte créé, la faille PHP WordPress a été exploitée et le nettoyage prime sur tout le reste. Cette lecture n’a pas besoin d’être quotidienne pour un site isolé, un contrôle mensuel suffit, mais elle devient précieuse le jour où un symptôme apparaît, parce qu’elle date l’incident et désigne la porte d’entrée. Pour un parc de sites, elle doit être automatisée : un outil qui compte les tentatives par site et par jour remonte les anomalies avant qu’elles ne deviennent des incidents.

Fermer les portes et le rester

Corriger une fois ne sert à rien si la routine ne suit pas : de nouvelles failles sont publiées chaque semaine.

Faille PHP WordPress : la routine de mise à jour qui tient

La mesure la plus efficace est aussi la plus simple : mettre à jour chaque semaine, et automatiquement quand c’est possible. WordPress propose les mises à jour automatiques pour le cœur, les extensions et les thèmes, à activer extension par extension. Le frein habituel est la peur de casser le site. Elle se traite par trois précautions : une sauvegarde automatique avant chaque mise à jour, un test rapide de la page d’accueil et d’un formulaire après, et un retour arrière immédiat si quelque chose a changé. Les mises à jour de sécurité des extensions sont mineures dans l’immense majorité des cas et ne modifient rien de visible ; ce sont les changements de version majeure, annoncés comme tels, qui méritent un test sur une copie. Au-delà de la mise à jour, tenez un inventaire : ce qui est installé, pourquoi, et depuis quand. Tout ce qui n’a plus de raison d’être est supprimé, pas seulement désactivé. Enfin, abonnez-vous aux alertes d’une base de vulnérabilités pour les extensions que vous utilisez, ou utilisez un outil qui le fait pour vous. Une faille PHP WordPress publiée un mardi est exploitée le mardi soir ; la mise à jour du vendredi arrive trop tard, celle du mardi midi arrive à temps.

Faille PHP WordPress : que faire quand le correctif n’existe pas

Il arrive qu’une faille soit publiée pour une extension abandonnée, ou que le correctif tarde plusieurs jours. Trois options, de la plus propre à la plus temporaire. La première est le remplacement : presque toute extension a un équivalent maintenu, et une migration d’un formulaire ou d’une galerie prend une heure. La deuxième est la désactivation et la suppression immédiates, en acceptant la perte de la fonction le temps de trouver un remplaçant ; une galerie absente coûte moins cher qu’un site compromis. La troisième est le correctif virtuel, proposé par certains pare-feux applicatifs et par des services comme Patchstack : une règle qui bloque la requête malveillante avant qu’elle n’atteigne le code vulnérable, sans modifier l’extension. Elle gagne du temps, mais elle ne remplace pas la correction réelle. Dans tous les cas, après la correction, vérifiez que la faille PHP WordPress n’a pas déjà été exploitée : fichiers PHP récents dans uploads, administrateurs inconnus, modifications de wp-config.php et de .htaccess. Les robots passent avant les correctifs, et un site corrigé mais déjà compromis reste compromis. Pour un parc de sites, ce contrôle quotidien est la seule façon de dormir tranquille : il remonte chaque matin les sites dont une extension accuse une faille publiée, avec la version à atteindre, et ceux dont un fichier a bougé sans raison.

Questions fréquentes

Mettre à jour PHP peut-il casser mon site ? Rarement si WordPress, le thème et les extensions sont à jour. Testez sur une copie, et revenez en arrière depuis le panneau d’hébergement si une page d’erreur apparaît.

Une extension désactivée est-elle encore dangereuse ? Oui. Son code reste sur le disque et accessible directement. Supprimez-la.

Comment savoir si une faille a déjà été exploitée ? Cherchez les fichiers PHP récents, les administrateurs inconnus et les modifications de wp-config.php. Un scan externe complète, sans remplacer, cette vérification.

Un pare-feu suffit-il ? Non. Il bloque les attaques connues, pas celles publiées hier. La mise à jour reste la première protection.