En bref : la faille de sécurité PHP de WordPress dont on parle actuellement ne se trouve pas dans WordPress, mais dans PHP sur le serveur situé en dessous. Une mise à jour de WordPress ne comble donc pas PHP2Shell. Ce qui compte, ce sont l'état du correctif de PHP, le redémarrage de tous les processus PHP et un contrôle des cachettes habituelles comme wp-content/uploads et mu-plugins.
Pourquoi une mise à jour de WordPress ne corrige pas PHP2Shell
WordPress est une application écrite en PHP. Les failles CVE-2026-109618 et CVE-2026-109619 se situent un niveau plus bas, dans l'interpréteur PHP lui-même. Selon l'équipe PHP, elles permettent d'exécuter du code malveillant à distance sans authentification. Avec Apache et mod_php, un exploit a été démontré avant même que le code de WordPress ne s'exécute.
Un site avec un cœur à jour, des plugins à jour et des mots de passe robustes peut donc rester vulnérable si le PHP en dessous est ancien. À l'inverse, un PHP corrigé ne prouve pas que rien ne s'est produit auparavant. Nous expliquons le contexte dans Qu'est-ce que PHP2Shell ?.
| Niveau | Qui met à jour | Comble PHP2Shell ? |
|---|---|---|
| Cœur de WordPress | Vous ou votre agence | Non |
| Plugins et thèmes | Vous ou votre agence | Non |
| PHP sur le serveur | Hébergeur ou administrateur du serveur | Oui, avec le redémarrage de tous les processus PHP |
Faille PHP de WordPress : vérifier la version de PHP
Dans le tableau de bord, sous Outils > Santé du site > Info, dans la section « Serveur », vous trouvez la version de PHP avec laquelle votre site fonctionne réellement. C'est plus fiable que php -v en ligne de commande, car celle-ci utilise souvent une autre installation de PHP que le serveur web.
Le numéro affiché ne suffit toutefois pas à lui seul. Les versions corrigées en amont sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. De nombreux hébergeurs intègrent cependant les correctifs sous forme de backport ; un numéro plus ancien reste alors affiché bien que le correctif soit appliqué. La manière de déterminer l'état réel est décrite dans Vérifier correctement la version de PHP et l'état du correctif. Les versions de PHP prises en charge par votre version de WordPress se vérifient dans la configuration requise sur wordpress.org.
Où le code malveillant aime se cacher dans WordPress
Après une attaque réussie, les auteurs déposent en général une porte dérobée pour revenir même après le correctif. WordPress offre pour cela des endroits connus :
- wp-content/uploads/ : prévu pour les images et les PDF, pas pour les fichiers PHP.
- wp-content/mu-plugins/ : les plugins « Must-use » se chargent automatiquement et ne peuvent pas être désactivés depuis le tableau de bord.
- wp-config.php : contient l'accès à la base de données et les clés de sécurité ; une ligne insérée y passe à peine inaperçue.
- .htaccess à la racine et dans les sous-dossiers : redirections réservées aux moteurs de recherche ou exécution d'extensions de fichiers inhabituelles.
- Thèmes, surtout
functions.php, ainsi que plugins désactivés et oubliés. - Base de données : nouveaux administrateurs dans
wp_users, JavaScript étranger danswp_optionsou dans les articles.
Premiers contrôles sans danger avec WP-CLI et les outils intégrés :
# Comparer les fichiers du cœur aux sommes de contrôle officielles
wp core verify-checksums
# Vérifier les plugins du répertoire wordpress.org
wp plugin verify-checksums --all
# Lister les fichiers PHP dans le dossier d'upload
find wp-content/uploads -type f -name "*.php"
# Afficher tous les administrateurs
wp user list --role=administrator
Un résultat est une raison d'examiner de près, pas encore une preuve. Les plugins commerciaux ne peuvent pas être vérifiés ainsi. Le guide Trouver des portes dérobées dans WordPress détaille la suite.
Ne supprimez pas des fichiers suspects à la hâte. Sauvegardez d'abord les fichiers, la base de données et les journaux du serveur à partir du 20/10/2026. Sans ces traces, il sera impossible d'établir plus tard si des données ont fui.
Plugins, thèmes et accès administrateur comme risque supplémentaire
PHP2Shell n'a pas besoin d'une faille de plugin. Au quotidien, les plugins et les thèmes restent toutefois la porte d'entrée la plus fréquente des sites WordPress. Chaque plugin apporte son propre code, ses propres fonctions d'upload et ses propres cycles de mise à jour. Vous devriez supprimer les plugins inutilisés plutôt que de simplement les désactiver, car les fichiers désactivés restent sur le serveur.
Pour wp-login.php et wp-admin, les règles sont les suivantes : peu d'administrateurs, des comptes personnels plutôt que des accès partagés et une authentification à deux facteurs. Si vous n'avez pas besoin de XML-RPC, il peut être bloqué. En cas de soupçon, tous les mots de passe et les clés de sécurité dans wp-config.php doivent être renouvelés. Vous y désactivez aussi l'éditeur de fichiers du tableau de bord :
define( 'DISALLOW_FILE_EDIT', true );
Ce que vous devriez faire maintenant en tant qu'exploitant WordPress
- Faire confirmer par écrit à l'hébergeur l'état du correctif PHP et le redémarrage de tous les processus PHP.
- Faire conserver les journaux du serveur à partir du 20/10/2026.
- Effectuer ou faire effectuer les contrôles ci-dessus.
- Mettre à jour WordPress, les plugins et les thèmes. C'est juste, mais ce n'est pas un substitut à l'étape 1.
- En cas d'anomalies, ne pas simplement continuer à exploiter le site, mais le faire nettoyer.
Une mise à jour de la plateforme peut combler des failles connues dans WordPress et les plugins. Elle ne peut ni réparer PHP ni supprimer des fichiers introduits qui n'appartiennent pas au cœur.
Comment PHP SOS aide-t-il concrètement ?
- Nous établissons avec vous ou votre hébergeur l'état réel de PHP pour votre site WordPress, y compris les backports et le redémarrage.
- Nous sauvegardons les journaux, les fichiers et la base de données avant toute modification.
- Nous contrôlons le cœur, les plugins, les uploads, les mu-plugins,
.htaccesset les comptes utilisateurs à la recherche de portes dérobées. - En cas de découvertes, notre suppression de malwares se charge du nettoyage jusqu'à ce que l'incident soit clos et documenté ; sans découvertes, nous durcissons l'installation dans le cadre de l'aide immédiate PHP2Shell.
Questions fréquentes
Dois-je mettre à jour WordPress à cause de PHP2Shell ?
Un WordPress à jour est toujours judicieux, mais il ne comble pas PHP2Shell. La faille se trouve dans l'interpréteur PHP du serveur. Il faut pour cela une mise à jour de PHP ou un backport confirmé par votre hébergeur, ainsi qu'un redémarrage de tous les processus PHP.
Un plugin de sécurité protège-t-il contre PHP2Shell ?
Seulement de façon très limitée. Un plugin est lui-même du code PHP qui s'exécute dans WordPress. Avec mod_php, un exploit a été démontré avant même que le code de l'application ne démarre ; un plugin risque donc de ne rien remarquer de l'attaque.
Pourquoi WordPress affiche-t-il encore une ancienne version de PHP alors que l'hébergeur a appliqué le correctif ?
De nombreux hébergeurs et distributions Linux intègrent les correctifs sous forme de backport dans la version existante. Le numéro de version reste alors le même. Faites-vous confirmer l'état du correctif par écrit par l'hébergeur.
Un fichier PHP a-t-il le droit de se trouver dans wp-content/uploads ?
Normalement non. Le dossier d'upload est destiné aux médias. Un fichier PHP à cet endroit est un signal d'alerte net et doit être sauvegardé et examiné par un spécialiste avant d'être supprimé.