En bref : le moyen le plus rapide de trouver une backdoor WordPress est de comparer le noyau et les plugins aux sommes de contrôle officielles avec WP-CLI, puis d'examiner de façon ciblée les mu-plugins, les uploads, wp-config.php, les comptes administrateur et la base de données. Important après PHP2Shell : une mise à jour de WordPress ne comble pas la faille PHP et ne supprime aucune porte dérobée existante.
Pourquoi les exploitants WordPress devraient regarder de plus près maintenant
Avec PHP2Shell, deux failles critiques dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619, sont devenues publiques en octobre 2026. Elles permettent l'exécution de code malveillant sans authentification, quel que soit le soin apporté à votre installation WordPress. Des correctifs existent depuis le 21 octobre 2026, mais selon des articles de presse, une première tentative d'attaque avait déjà été observée le 17 octobre.
Quiconque était vulnérable pendant cette période devrait chercher des traces. WordPress est une cible typique, car de nombreuses installations sont construites de façon similaire et les attaquants connaissent les cachettes. Ce que les exploitants doivent faire en général au sujet de PHP2Shell figure sur la page WordPress et PHP2Shell.
Effectuez les contrôles suivants, si possible, sur une copie ou après une sauvegarde. Les commandes ne font que lire et ne modifient rien.
Comment remarquer une backdoor au quotidien
Une porte dérobée est conçue pour rester discrète. Il existe pourtant des signes visibles même sans connaissances techniques. Parmi eux, des redirections vers des sites étrangers qui n'apparaissent que pour les visiteurs venant de la recherche Google ou uniquement sur mobile. Sont tout aussi suspectes les nouvelles pages publicitaires pour des médicaments, des jeux d'argent ou des contrefaçons de produits de marque, qui apparaissent dans l'index de recherche mais pas dans l'administration de WordPress.
D'autres indices sont des avertissements de Google ou du navigateur, des plaintes de clients au sujet de spams envoyés depuis votre domaine, une consommation de temps de calcul soudainement très élevée chez l'hébergeur ou des administrateurs que personne ne connaît dans l'équipe. Aucun de ces signes ne prouve à lui seul une backdoor. Si plusieurs apparaissent ensemble, ne repoussez pas les contrôles suivants.
À l'inverse : si rien de tout cela ne se remarque, cela ne signifie pas que l'installation est saine. Précisément les portes dérobées créées uniquement pour un accès ultérieur n'ont souvent aucun effet visible de l'extérieur.
Trouver une backdoor WordPress : contrôler le noyau et les plugins
WP-CLI peut comparer les fichiers du noyau WordPress et des plugins du répertoire officiel avec les sommes de contrôle publiées. Chaque écart est une tâche de vérification concrète.
cd /var/www/meine-seite
# Fichiers du noyau comparés aux sommes de contrôle officielles
wp core verify-checksums
# Plugins du répertoire officiel
wp plugin verify-checksums --all
# Versions installées et statut
wp plugin list
wp theme list
Les plugins et thèmes commerciaux ne peuvent pas être vérifiés ainsi. Pour eux, seule la comparaison avec un paquet d'origine du fournisseur fraîchement téléchargé aide. Les plugins inconnus que personne dans l'équipe n'a installés sont toujours suspects, même s'ils semblent désactivés.
Cachettes typiques dans le système de fichiers
Certains endroits reviennent sans cesse dans les installations WordPress compromises :
wp-content/mu-plugins/: chargé automatiquement et absent de la liste normale des plugins.wp-content/uploads/: c'est la place des images et des documents, pas des fichiers PHP.wp-config.php: lignesincludeourequiresupplémentaires au début ou à la fin..htaccesset.user.inidans le répertoire web et dans les sous-dossiers : redirections inattendues ou fichiers préchargés automatiquement.- Fichiers dans le répertoire principal dont les noms rappellent des fichiers du noyau WordPress mais qui n'en font pas partie.
# Fichiers PHP dans le dossier d'upload
find wp-content/uploads -type f -name "*.php*"
# Contenu des plugins must-use
ls -la wp-content/mu-plugins/
# Tous les fichiers .htaccess et .user.ini avec date de modification
find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} +
# Fichiers PHP modifiés récemment
find . -type f -name "*.php" -newermt "2026-10-17" -ls
Des motifs de recherche généraux pour le code obfusqué sont décrits dans le guide Détecter et supprimer les webshells.
Contrôler les utilisateurs, la base de données et les tâches planifiées
De nombreuses portes dérobées ne se trouvent pas du tout dans le système de fichiers. Un compte administrateur supplémentaire suffit souvent aux attaquants pour revenir plus tard.
# Tous les administrateurs avec date d'inscription
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# Tâches planifiées dans WordPress
wp cron event list
# Adresse du site (les manipulations entraînent des redirections)
wp option get siteurl
wp option get home
# Articles contenant des scripts intégrés
wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '%<script%'"
Contrôlez aussi les options au contenu anormalement volumineux et les widgets contenant du code étranger. Des résultats ne signifient pas automatiquement une attaque, car les codes de suivi ou les cartes intégrées utilisent eux aussi des scripts. Ce qui compte, c'est que quelqu'un dans l'équipe connaisse le contenu.
Après une découverte, changez tous les mots de passe et les clés de sécurité dans wp-config.php. Sinon, les connexions existantes des attaquants restent valides.
Fermer les portes dérobées et empêcher leur retour
Si vous avez trouvé une backdoor, une réinstallation est généralement plus sûre que la réparation de fichiers isolés. L'ordre suivant a fait ses preuves :
- Préserver les traces : conserver journaux, fichiers suspects et un export de la base de données, datés.
- Amener PHP à une version corrigée et redémarrer tous les processus PHP.
- Installer le noyau WordPress, les plugins et les thèmes à neuf depuis des sources d'origine.
- Reprendre les uploads et la base de données après vérification, supprimer les comptes étrangers, changer tous les accès.
- Empêcher l'exécution de PHP dans le dossier d'upload au niveau du serveur.
Pour Nginx, un bloc dans la configuration du serveur suffit :
location ~* ^/wp-content/uploads/.*\.php$ {
deny all;
}
Sous Apache, vous obtenez le même résultat avec une règle dans la configuration du serveur pour le dossier d'upload. Un .htaccess dans le dossier d'upload lui-même est plus faible, car un attaquant disposant de droits d'écriture peut le modifier de nouveau.
Prévoyez après le nettoyage quelques semaines de surveillance renforcée. Les nouveaux administrateurs, les nouveaux fichiers PHP et les modifications de wp-config.php devraient alors se remarquer immédiatement, par exemple grâce à un contrôle régulier avec WP-CLI ou à une surveillance des fichiers sur le serveur.
Le guide Droits des fichiers sur le serveur web montre comment définir ensuite les droits afin que WordPress ne puisse écrire que là où c'est nécessaire.
Comment PHP SOS aide-t-il concrètement ?
- Nous sauvegardons l'état de l'installation avant que quoi que ce soit ne soit modifié.
- Nous contrôlons le noyau, les plugins, les thèmes, la base de données, les comptes et la configuration du serveur à la recherche de portes dérobées.
- Nous réinstallons WordPress à partir de sources saines et ne reprenons que des contenus vérifiés.
- Nous renforçons le serveur et l'installation et documentons ce qui a été trouvé et corrigé.
Le déroulement d'un nettoyage est décrit par la prestation Faire supprimer malwares et webshells.
Questions fréquentes
Une mise à jour de WordPress comble-t-elle la faille PHP2Shell ?
Non. PHP2Shell se trouve dans l'interpréteur PHP, pas dans WordPress. Une mise à jour de WordPress, des thèmes ou des plugins n'y change rien ; ce qui compte, c'est la version de PHP du serveur et le redémarrage de tous les processus PHP.
Un plugin de sécurité trouve-t-il toutes les backdoors ?
Pas de façon fiable. Un plugin s'exécute à l'intérieur de l'installation compromise et peut lui-même avoir été manipulé. Complétez-le par des contrôles externes, par exemple les sommes de contrôle de WP-CLI et une comparaison avec des fichiers d'origine sains.
Que sont les mu-plugins et pourquoi sont-ils suspects ?
Les plugins « must-use » du dossier wp-content/mu-plugins sont chargés automatiquement et n'apparaissent pas dans la liste normale des plugins. Les attaquants l'exploitent volontiers, car les exploitants consultent rarement ce dossier.
Une backdoor peut-elle aussi se trouver dans la base de données ?
Oui. Du code malveillant ou des redirections sont souvent placés dans des options, des articles ou des widgets. Les attaquants créent en outre souvent leurs propres comptes administrateur, que vous trouvez dans la table des utilisateurs.