Restauration site WordPress piraté : guide technique WP-CLI

Votre client vous appelle en panique : son site affiche des redirections vers des casinos en ligne et Google l’a blacklisté. Ce scénario, tout développeur WordPress l’a vécu au moins une fois. La restauration d’un site WordPress piraté ne s’improvise pas - elle exige une méthodologie rigoureuse et des outils en ligne de commande pour identifier, nettoyer et sécuriser efficacement l’installation compromise.

Le problème avec les interfaces graphiques, c’est qu’elles masquent souvent l’étendue réelle de l’infection. Un malware sophistiqué peut se cacher dans des dizaines de fichiers, créer des backdoors dans la base de données et installer des cron jobs qui réinfectent le site quelques heures après votre nettoyage manuel. WP-CLI change la donne : vous accédez directement au cœur de WordPress, vous automatisez les vérifications et vous gardez une trace de chaque action.

Ce guide vous donne les commandes WP-CLI exactes, les scripts bash testés en production et les procédures que j’utilise sur chaque intervention. Que vous gériez vos propres sites ou ceux de vos clients, ces techniques vous permettront d’intervenir rapidement et méthodiquement sur n’importe quelle infection WordPress.

Diagnostic initial : évaluer l’étendue de l’infection en 5 minutes

Avant de toucher à quoi que ce soit, vous devez comprendre ce que vous affrontez. La commande wp core verify-checksums compare chaque fichier du core WordPress avec les checksums officiels de WordPress.org. Lancez-la immédiatement :

wp core verify-checksums

Si des fichiers sont modifiés, WP-CLI les liste explicitement. Attention aux faux positifs : certains hébergeurs ajoutent des fichiers légitimes comme wp-config-sample.php modifié ou des fichiers de cache. Concentrez-vous sur les fichiers dans wp-admin et wp-includes - ceux-là ne devraient jamais être modifiés.

Les attaquants créent souvent des fichiers PHP récents pour maintenir leur accès. Ce script bash liste tous les fichiers PHP modifiés dans les 7 derniers jours :

find . -name '*.php' -mtime -7 -exec ls -la {} \;

Vérifiez ensuite les utilisateurs administrateurs. Les pirates créent fréquemment des comptes admin avec des noms anodins comme “support” ou “wp_update” :

wp user list --role=administrator --format=table

Tout utilisateur que vous ne reconnaissez pas est suspect. Notez les IDs pour suppression ultérieure. Analysez également les tâches cron programmées - les malwares utilisent souvent le système de cron WordPress pour se réinstaller automatiquement :

wp cron event list

Repérez les hooks suspects comme wp_update_plugins_fake, check_theme_updates ou tout nom qui semble imiter une fonction WordPress légitime. Avant toute manipulation, exportez immédiatement la base de données :

wp db export backup-$(date +%Y%m%d).sql

Créer un backup forensique avant l’intervention

Le backup forensique n’est pas optionnel. Si votre nettoyage échoue ou si vous devez analyser l’infection plus tard, vous aurez besoin d’une copie exacte de l’état compromis. Ce script crée un backup complet avec fichiers, base de données et permissions :

#!/bin/bash
SITE_PATH="/var/www/wordpress" BACKUP_DIR="/home/backups/forensic-$(date +%Y%m%d-%H%M%S)"
mkdir -p $BACKUP_DIR
cd $SITE_PATH
# Export base de données
wp db export $BACKUP_DIR/database.sql
# Archive fichiers avec permissions
tar -czvf $BACKUP_DIR/files.tar.gz --preserve-permissions .
# Liste des permissions pour référence
find . -printf '%m %u %g %p\n' > $BACKUP_DIR/permissions.txt

Ce backup doit impérativement quitter le serveur compromis. Transférez-le immédiatement vers un emplacement sûr :

scp -r $BACKUP_DIR user@serveur-sain:/backups/

Documentez l’état initial du site pour comparaison post-nettoyage. Ces informations seront précieuses pour le rapport client :

wp option get siteurl > $BACKUP_DIR/config-siteurl.txt
wp plugin list --format=csv > $BACKUP_DIR/plugins-list.csv
wp theme list --format=csv > $BACKUP_DIR/themes-list.csv

Générez enfin un hash SHA256 de tous les fichiers PHP. Après le nettoyage, vous pourrez comparer ces hashes pour confirmer que les fichiers malveillants ont été supprimés :

find . -name '*.php' -exec sha256sum {} \; > $BACKUP_DIR/hashes-before.txt

Scanner le malware avec Wordfence CLI et Sucuri

Les scanners automatisés détectent les signatures de malware connues et accélèrent considérablement le diagnostic. Wordfence propose un scanner CLI puissant. Installez-le sur votre serveur :

wp plugin install wordfence --activate
wp wordfence scan --type=full

Pour une analyse externe qui ne dépend pas du site compromis, utilisez Sucuri SiteCheck via leur API ou directement en ligne. Vous pouvez aussi installer le plugin Sucuri en CLI :

wp plugin install sucuri-scanner --activate

L’interprétation des résultats demande de l’expérience. Certains faux positifs reviennent régulièrement : les fichiers timthumb.php légitimes, les fonctions eval() utilisées par des plugins de cache, ou le base64 dans les builders visuels. Concentrez-vous sur les patterns vraiment suspects : eval(base64_decode(, $_POST['cmd'], ou les fichiers avec des noms aléatoires comme xkj7d.php.

Créez une liste des fichiers infectés pour traitement batch :

grep -r 'eval(base64_decode' --include='*.php' -l > infected-files.txt
grep -r '\$_POST\[.cmd' --include='*.php' -l >> infected-files.txt

Un edge case fréquent : les malwares qui se cachent dans la table wp_options sous forme de données sérialisées. Cherchez les options suspectes :

wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%base64_decode%' OR option_value LIKE '%eval(%'"

Réinstallation propre du core WordPress

Une fois le diagnostic établi, réinstallez le core WordPress depuis les sources officielles. L’option --skip-content préserve votre dossier wp-content :

wp core download --force --skip-content

Cette commande écrase tous les fichiers de wp-admin et wp-includes par des versions propres. Vérifiez immédiatement l’intégrité :

wp core verify-checksums

Vous devez obtenir Success: WordPress installation verifies against checksums. Si des erreurs persistent, des fichiers orphelins traînent encore. Ce script compare les fichiers présents avec la liste officielle et supprime les intrus :

#!/bin/bash
# Télécharger la liste des fichiers core officiels
wp core download --path=/tmp/wp-clean --skip-content
find /tmp/wp-clean -type f -name '*.php' | sed 's|/tmp/wp-clean/||' | sort > /tmp/core-files.txt
# Lister les fichiers actuels (hors wp-content)
find . -path ./wp-content -prune -o -type f -name '*.php' -print | sed 's|^\./||' | sort > /tmp/current-files.txt
# Trouver et supprimer les fichiers non officiels
comm -23 /tmp/current-files.txt /tmp/core-files.txt | while read file; do
    echo "Suppression fichier orphelin: $file"
    rm -f "$file"
done

Après cette étape, votre core WordPress est garanti propre. Les backdoors qui s’y cachaient ont disparu.

Nettoyer les plugins et thèmes : la méthode batch replace infected

Les plugins et thèmes représentent le vecteur d’infection le plus courant. La méthode la plus sûre consiste à tout désactiver, puis à réinstaller proprement :

wp plugin deactivate --all

Pour chaque plugin du repository officiel, supprimez et réinstallez :

wp plugin delete akismet && wp plugin install akismet --activate
wp plugin delete contact-form-7 && wp plugin install contact-form-7 --activate

Les plugins premium nécessitent plus d’attention. Téléchargez une version fraîche depuis le site de l’éditeur et uploadez-la manuellement ou via WP-CLI si vous avez le zip :

wp plugin install /chemin/vers/plugin-premium.zip --force

Appliquez la même méthode aux thèmes. Si vous utilisez un thème enfant, sauvegardez d’abord les fichiers personnalisés :

cp wp-content/themes/theme-enfant/functions.php /tmp/functions-backup.php
cp wp-content/themes/theme-enfant/style.css /tmp/style-backup.css
wp theme delete theme-enfant
wp theme delete theme-parent
wp theme install theme-parent

Recréez ensuite le thème enfant proprement et réintégrez vos personnalisations après vérification manuelle du code sauvegardé.

Nettoyer la base de données des injections

Les injections en base de données sont particulièrement sournoises. Elles peuvent injecter du JavaScript malveillant dans chaque article ou modifier silencieusement les options du site. Commencez par rechercher les scripts injectés dans les contenus :

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%eval(%'"

Si vous identifiez une injection récurrente, utilisez search-replace pour la supprimer en masse :

wp search-replace '<script src="https://malware.example/bad.js"></script>' '' --all-tables --precise

Inspectez les options suspectes et supprimez-les :

wp option list --search='*base64*'
wp option list --search='*eval*'
wp option delete nom_option_suspecte

Vérifiez et supprimez les utilisateurs créés par l’attaquant :

wp user list --role=administrator
wp user delete 42 --reassign=1  # Réassigne le contenu à l'admin ID 1

Réinitialisez tous les mots de passe administrateurs. Cette étape est non négociable - les credentials ont pu être compromis :

wp user update admin --user_pass=$(openssl rand -base64 12)
wp user update editeur --user_pass=$(openssl rand -base64 12)

Communiquez les nouveaux mots de passe de manière sécurisée à leurs propriétaires.

Sécuriser le site après nettoyage

Le nettoyage terminé, il faut verrouiller le site contre une réinfection. Régénérez les clés de sécurité du wp-config.php - cela invalide tous les cookies existants :

wp config shuffle-salts

Forcez la déconnexion de toutes les sessions utilisateur actives :

wp user session destroy --all

Installez et configurez Wordfence pour une protection continue :

wp plugin install wordfence --activate

Mettez en place un monitoring automatique. Ce script cron vérifie quotidiennement l’intégrité du core :

#!/bin/bash
# /etc/cron.daily/wp-integrity-check
cd /var/www/wordpress
RESULT=$(wp core verify-checksums 2>&1)
if [[ $RESULT != *"Success"* ]]; then
    echo "$RESULT" | mail -s "ALERTE: Intégrité WordPress compromise" admin@example.com
fi

Corrigez enfin les permissions fichiers. Des permissions trop laxistes facilitent les infections :

find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
chmod 600 wp-config.php

Automatiser la restauration avec un script bash réutilisable

Après plusieurs interventions, vous apprécierez d’avoir un script automatisé. Voici une version complète et réutilisable :

#!/bin/bash
#
# Script de restauration WordPress piraté
# Usage: ./restore-wp.sh /chemin/vers/wordpress
#
set -e
WP_PATH="${1:-.}"
BACKUP_DIR="/home/backups/restore-$(date +%Y%m%d-%H%M%S)"
EMAIL_ALERT="admin@example.com"
LOG_FILE="$BACKUP_DIR/restore.log"
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}
cd $WP_PATH
mkdir -p $BACKUP_DIR
log "=== Démarrage restauration WordPress ==="
log "Chemin: $WP_PATH"
# Étape 1: Backup forensique
log "Étape 1: Création backup forensique..."
wp db export $BACKUP_DIR/database.sql
tar -czf $BACKUP_DIR/files.tar.gz .
log "Backup créé dans $BACKUP_DIR"
# Étape 2: Diagnostic
log "Étape 2: Diagnostic initial..."
wp core verify-checksums 2>&1 | tee -a $LOG_FILE || true
wp user list --role=administrator --format=table | tee -a $LOG_FILE
# Étape 3: Réinstallation core
log "Étape 3: Réinstallation core WordPress..."
wp core download --force --skip-content
wp core verify-checksums
# Étape 4: Réinstallation plugins
log "Étape 4: Nettoyage plugins..."
wp plugin deactivate --all
for plugin in $(wp plugin list --status=inactive --field=name); do
    if wp plugin search "$plugin" --per-page=1 --format=count | grep -q "1"; then
        log "Réinstallation: $plugin"
        wp plugin delete $plugin
        wp plugin install $plugin
    fi
done
# Étape 5: Sécurisation
log "Étape 5: Sécurisation..."
wp config shuffle-salts
wp user session destroy --all
# Étape 6: Vérification finale
log "Étape 6: Vérification finale..."
wp core verify-checksums
wp plugin list --format=table | tee -a $LOG_FILE
log "=== Restauration terminée ==="
log "Rapport complet: $LOG_FILE"
# Notification email
mail -s "Restauration WordPress terminée - $WP_PATH" $EMAIL_ALERT < $LOG_FILE

Personnalisez les variables en tête de script selon votre environnement. Le log détaillé vous permet de fournir un rapport d’intervention complet à votre client, documentant chaque action effectuée et son résultat.

Conclusion

La restauration d’un site WordPress piraté avec WP-CLI suit toujours le même processus méthodique : diagnostic rapide avec verify-checksums, backup forensique complet, scan automatisé des malwares, nettoyage du core et des plugins, purge de la base de données, puis sécurisation finale. Ces commandes et scripts vous permettent d’intervenir rapidement sur n’importe quelle infection, en gardant une trace complète de vos actions.

La clé du succès réside dans la rigueur : ne sautez aucune étape, documentez tout, et vérifiez systématiquement le résultat de chaque commande. Un site mal nettoyé sera réinfecté dans les jours qui suivent - les backdoors oubliées sont la première cause de récidive.

Trop complexe pour votre client ou vous manquez de temps sur vos projets en cours ? Vous pouvez externaliser l’intervention d’urgence et vous concentrer sur vos développements. Pour les agences et freelances qui rencontrent régulièrement ce type de situation, n’hésitez pas à discuter d’un partenariat pour les futures interventions.

FAQ

Combien de temps prend une restauration WordPress piraté complète ?

Une restauration complète prend entre 2 et 6 heures selon la complexité de l’infection. Les cas simples avec malware connu et fichiers core uniquement touchés se règlent en 2 heures. Les infections profondes avec backdoors multiples, base de données compromise et mécanismes de réinfection automatique peuvent nécessiter une journée entière d’intervention méthodique.

Peut-on restaurer un site piraté sans accès SSH ?

C’est possible mais beaucoup plus lent et risqué. Sans SSH et WP-CLI, vous devez utiliser le panneau d’hébergement comme cPanel ou Plesk pour manipuler les fichiers, et phpMyAdmin pour nettoyer la base de données. Le processus prend 3 à 4 fois plus de temps et le risque d’oublier des fichiers infectés augmente significativement. Si votre hébergement ne propose pas SSH, envisagez une migration vers une offre professionnelle.

Comment savoir si le nettoyage WordPress est vraiment terminé ?

Exécutez wp core verify-checksums qui doit retourner “Success”. Lancez un scan Wordfence complet sans alertes critiques. Vérifiez qu’aucun fichier PHP n’a été modifié dans les 24 heures suivantes avec la commande find. Testez le site sur Google Safe Browsing et Sucuri SiteCheck pour confirmer l’absence de blacklistage. Surveillez les logs serveur pendant 7 jours minimum pour détecter toute activité suspecte ou tentative de réinfection.

Faut-il changer d’hébergeur après un piratage WordPress ?

Pas nécessairement. Si l’infection provient d’un plugin vulnérable ou de credentials volés, l’hébergeur n’est pas en cause. En revanche, si l’attaque exploite une faille au niveau serveur ou si d’autres sites sur le même hébergement mutualisé sont également infectés, migrer vers un hébergement WordPress managé avec isolation des comptes devient recommandé. Les hébergeurs spécialisés WordPress offrent aussi des sauvegardes automatiques et des scans de sécurité intégrés.

WP-CLI fonctionne-t-il sur tous les hébergements ?

WP-CLI nécessite un accès SSH, disponible sur la plupart des hébergements professionnels comme OVH Pro, Infomaniak, o2switch ou tout VPS. Les hébergements mutualisés bas de gamme ne proposent souvent pas SSH - vérifiez auprès de votre hébergeur avant de vous engager. Si vous intervenez régulièrement sur des sites piratés, optez pour un VPS où vous avez le contrôle total de l’environnement serveur et pouvez installer tous les outils nécessaires.

Cette procédure restaure l’existant à l’identique, vulnérabilités comprises. Si votre site n’a pas besoin de la mécanique WordPress, une migration vers Astro évite d’avoir à la refaire un jour.