Récupérer un site WordPress piraté : méthode 2026

Un site WordPress piraté se récupère, y compris quand Google affiche déjà son avertissement rouge. Dans les dix premières minutes, deux réflexes aggravent la situation plus sûrement que l'attaque elle-même : supprimer des fichiers à l'aveugle — ils contiennent les traces qui permettront d'identifier la faille — et changer le mot de passe administrateur en considérant l'affaire réglée, alors que l'attaquant dispose d'autres accès. La bonne réponse est une procédure d'incident en six étapes, dans un ordre strict : confirmer, isoler, diagnostiquer, nettoyer ou restaurer, durcir, sortir des listes noires. Comptez moins d'une heure si une sauvegarde saine existe, une demi-journée à plusieurs jours pour un nettoyage manuel. Chaque étape ci-dessous donne les commandes exactes, applicables sur tout hébergement disposant d'un accès SSH ou SFTP.

L'essentiel en un coup d'œil

Confirmer et qualifier la compromission

Confirmer la compromission consiste à recouper au moins deux signaux indépendants, puis à estimer la date d'intrusion — c'est elle qui déterminera, plus loin, quelle sauvegarde est encore saine. Les symptômes typiques d'un WordPress infecté :

• Redirections vers des sites tiers (pharma, casino, contrefaçon), parfois visibles uniquement sur mobile ou depuis les résultats de recherche ;
• Spam SEO : des pages en japonais ou pharmaceutiques indexées sous votre domaine — taper site:votredomaine.fr dans Google les révèle ;
• Avertissement navigateur « Ce site risque d'endommager votre ordinateur » : le domaine est entré en liste Google Safe Browsing, ce que confirme le rapport de transparence Google ;
• Compte administrateur inconnu, fichiers modifiés sans intervention de votre part, envois de spam depuis le serveur.

Deux commandes établissent les faits :

# Comptes administrateurs : tout intrus saute aux yeux
wp user list --role=administrator --fields=ID,user_login,user_registered,user_email

# Fichiers PHP modifiés sur les 14 derniers jours (indice, pas preuve : l'horodatage se falsifie)
find . -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort -r | head -30

Un scan distant (Sucuri SiteCheck, VirusTotal sur l'URL) complète le tableau sans rien installer sur le site. La FAQ officielle WordPress.org « My site was hacked » recoupe ces mêmes signaux. Notez la date de compromission la plus ancienne que vous parvenez à établir : la majorité des sites WordPress piratés le sont depuis plusieurs semaines quand le premier symptôme devient visible.

Isoler le site sans détruire les preuves

Isoler le site poursuit trois objectifs simultanés : cesser de servir du malware aux visiteurs, stopper la dégradation SEO, et figer les preuves. Ne supprimez rien à ce stade — chaque fichier suspect documente le vecteur d'entrée. Le blocage le plus simple passe par .htaccess, en conservant votre propre accès :

# .htaccess — couper le trafic public le temps de l'intervention
<RequireAll>
    Require ip 203.0.113.42
</RequireAll>

Remplacez l'adresse par la vôtre. Une page de maintenance côté hébergeur convient aussi, à condition de renvoyer un code 503 — compris par les moteurs comme une indisponibilité temporaire.

Révoquez ensuite la totalité des accès, pas seulement le vôtre : mots de passe de tous les comptes WordPress, identifiants FTP/SFTP, mot de passe de la base de données (puis mise à jour de wp-config.php), clés d'API et mots de passe d'application. Invalidez les sessions ouvertes :

# Détruire toutes les sessions WordPress actives (y compris celles de l'attaquant)
for id in $(wp user list --field=ID); do wp user session destroy "$id" --all; done

Sur l'hébergement web Tomco, deux mécanismes travaillent déjà à ce stade : l'EDR détecte les webshells et signatures de malware connues, place les fichiers en quarantaine automatiquement — l'alerte et le fichier neutralisé apparaissent dans Enhance Panel. Et chaque site vit dans un environnement isolé : un site compromis ne contamine pas les autres sites du même compte, l'incident reste circonscrit à un seul périmètre.

Diagnostiquer le vecteur d'entrée

Le diagnostic répond à une seule question : par où l'attaquant est-il entré ? Nettoyer sans cette réponse garantit la réinfection. Sur les incidents traités par le support Tomco, le classement des vecteurs confirmés varie peu d'une année sur l'autre : l'extension obsolète porteuse d'une vulnérabilité publique arrive nettement en tête, suivie des identifiants faibles ou réutilisés ; thèmes piratés « nulled » et vols d'accès FTP depuis un poste de travail infecté se partagent le solde.

Quatre vérifications couvrent l'essentiel :

1. Les logs d'accès. Remonter à la première requête vers le fichier malveillant identifié : son origine (adresse IP, date, chemin exploité) désigne le vecteur.
2. Extensions et thèmes. Confronter chaque version installée à la base de vulnérabilités WPScan : une CVE publiée sur une version présente au moment de l'intrusion est le suspect n°1.
3. Les fichiers. Aucun .php n'a sa place dans uploads ; vérifier aussi le code injecté en tête de wp-config.php ou index.php.
4. Les tâches planifiées. Un cron malveillant retélécharge le malware après chaque nettoyage : inspecter wp cron event list et crontab -l.

# Requêtes POST vers des fichiers PHP qui ne devraient jamais en recevoir
grep -E 'POST /wp-content/(uploads|cache|upgrade)/[^ ]*\.php' access.log

# Webshells : aucun fichier PHP légitime dans uploads
find wp-content/uploads -type f -name '*.php'

Nettoyer ou restaurer un site WordPress piraté : l'arbre de décision

Une seule question commande la suite : disposez-vous d'une sauvegarde complète antérieure à la date de compromission établie à la première étape ?

Oui — restaurez. C'est l'option fiable : fichiers et base de données remis depuis le même point, dont l'intégrité est certaine. Corrigez ensuite le vecteur identifié — mise à jour ou suppression de l'extension en cause, rotation des identifiants — avant la remise en ligne, sans quoi la réinfection suit en quelques jours. La restauration suppose un dispositif en place : la méthode complète est détaillée dans le guide stratégie de sauvegarde 3-2-1.

Non — nettoyez le WordPress hacké manuellement, en restant lucide sur les limites de l'exercice : une porte dérobée tient en trois lignes parmi des dizaines de milliers de fichiers, et aucun nettoyage manuel n'offre de garantie d'exhaustivité. C'est un pis-aller, pas un équivalent. La séquence :

# 1. Intégrité du cœur : liste les fichiers modifiés ou étrangers
wp core verify-checksums

# 2. Réinstallation complète du cœur (wp-content préservé)
wp core download --force --skip-content

# 3. Réinstaller chaque extension depuis sa source officielle
wp plugin install nom-extension --force

Complétez par l'inspection de la base de données — comptes, code <script> injecté dans les articles, options siteurl et home — et la purge des .php dans uploads.

L'arbre de décision se joue en réalité des semaines avant l'incident, sur la profondeur de rétention. L'infection précède sa découverte de plusieurs semaines dans la majorité des cas : avec les 7 à 30 jours de rétention standard chez la plupart des hébergeurs, toutes les copies disponibles d'un site WordPress piraté depuis six semaines contiennent déjà la porte dérobée. La rétention de 90 jours des sauvegardes Tomco — journalières, restauration granulaire fichiers ou base — laisse la marge nécessaire pour remonter avant une compromission découverte tardivement.

Durcir le site après l'incident

Un site restauré ou nettoyé repart avec les faiblesses de la veille. Quatre gestes ferment l'incident :

1. Rotation complète des secrets : mots de passe WordPress, FTP, base de données, clés d'API — et les clés de salage de wp-config.php, qui invalident définitivement tous les cookies de session volés :

# Régénérer les 8 clés de salage (déconnecte toutes les sessions)
wp config shuffle-salts

2. Tout mettre à jour : cœur, extensions, thèmes, version PHP. La fenêtre entre la publication d'une CVE et son exploitation de masse se compte en heures.
3. Activer la 2FA sur tous les comptes administrateur et éditeur.
4. Supprimer l'inutilisé : extensions désactivées, thèmes dormants, comptes orphelins — un plugin désactivé reste exploitable sur le disque.

Ces gestes traitent l'urgence. Le durcissement complet — 17 mesures classées par impact et effort, de la limitation des tentatives de connexion au blocage de l'exécution PHP dans uploads — fait l'objet du guide sécuriser WordPress en 2026.

Sortir des listes noires Google

Dernière étape : faire constater le nettoyage. Dans Google Search Console, la section « Sécurité et actions manuelles → Problèmes de sécurité » liste les URL signalées et la catégorie retenue (logiciel malveillant, spam, phishing). Une fois le site propre et durci, soumettez la demande de réexamen en décrivant factuellement le vecteur identifié et les actions menées — les demandes documentées sont traitées plus vite. Ordres de grandeur annoncés par Google : environ un jour pour du phishing, quelques jours pour un logiciel malveillant, jusqu'à deux semaines pour du spam injecté.

L'avertissement rouge des navigateurs disparaît après validation du réexamen — Chrome, Firefox et Edge s'appuient tous sur Safe Browsing. Les pages de spam SEO indexées sortent d'elles-mêmes au fil du recrawl ; l'outil de suppression d'URL de la Search Console accélère le retrait des plus visibles.

Un site WordPress piraté une première fois reste une cible marquée : surveillez la Search Console pendant deux à trois semaines. La réapparition de pages indexées inconnues signale une réinfection — vecteur mal identifié ou porte dérobée résiduelle — et renvoie à l'étape diagnostic.