Une intrusion a-t-elle laissé des traces sur votre WordPress ? Après le correctif

Mettre PHP à jour ferme la faille. Mais cela ne retire pas forcément un accès, un fichier ou une redirection qu’un pirate aurait déjà laissés sur le site. Après l’alerte d’octobre 2026, voici les contrôles utiles avant de considérer votre WordPress comme sain.

Désinfection
Lire le guide Voir la désinfection
Désinfection WordPress
Vérifier l’exposition
Chercher les traces
Repartir sur une base saine

Un site peut sembler normal tout en envoyant des visiteurs ailleurs, en diffusant du spam ou en laissant un accès actif à un tiers. Mettre PHP à jour est indispensable. Mais si le site a été exposé avant le correctif, la mise à jour ne permet pas de savoir ce qui a pu être laissé derrière.

Si le correctif a été appliqué tardivement, ou si personne ne peut dire quand il l’a été, le site mérite un contrôle même s’il fonctionne. Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux failles critiques. Elles pouvaient permettre à un tiers de faire agir le serveur sans se connecter au tableau de bord. Les versions corrigées annoncées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Des tentatives visant ces failles ont été observées.

Le correctif ferme la faille, pas forcément l’incident

Le correctif empêche une nouvelle exploitation connue de la faille. Il ne supprime pas automatiquement un fichier ajouté auparavant, un compte administrateur créé par un tiers ou une redirection cachée dans le site.

C’est comme réparer une porte mal fermée : il faut encore vérifier ce qui a pu se passer avant. Une exposition ne prouve pas une intrusion. En revanche, si la date du correctif n’est pas connue, un contrôle ciblé évite de laisser un accès actif sans le savoir.

Illustration d’une vérification de sécurité après une faille PHP sur un site WordPress.
Le correctif PHP réduit le risque pour la suite. La vérification cherche les traces d’une éventuelle intrusion passée.

Les signes à vérifier, pas seulement sur la page d’accueil

Un WordPress piraté peut paraître normal quand vous êtes connecté. Une redirection ou une page de spam peut n’apparaître que pour un visiteur venant de Google, sur mobile ou dans un navigateur non connecté. Ouvrez donc le site dans une fenêtre privée. Regardez aussi ce que Google affiche pour votre domaine.

Ne retirez pas seulement ce qui se voit

Supprimer une page de spam ou désactiver une extension suspecte peut faire disparaître le symptôme sans retirer l’accès qui a servi à l’ajouter. Il faut regarder les fichiers, les données du site, les comptes, les extensions, les accès à l’hébergement et les sauvegardes. Avant toute suppression, gardez une copie du site et les journaux disponibles : ces historiques peuvent aider à comprendre l’incident.

Qui vérifie quoi, et dans quel ordre ?

Le but n’est pas de lancer un scan et de cocher une case. Il faut d’abord vérifier que le serveur est bien corrigé, puis chercher les changements inattendus et retirer les accès ou contenus malveillants identifiés. Si plusieurs sites partagent le même compte d’hébergement, ils peuvent aussi devoir être vérifiés.

Illustration du contrôle des fichiers et de la base de données d’un WordPress compromis.

Quand le site peut être considéré comme stabilisé

Une page d’accueil qui s’affiche ne suffit pas. Après le nettoyage, vérifiez que la version PHP corrigée est active, que les comptes et accès ont été renouvelés, que les éléments suspects ont été traités et que les parcours importants fonctionnent encore : formulaire, commande, paiement, espace client ou connexion.

Le travail ne s’arrête pas au nettoyage du site

Si Google a détecté des contenus piratés ou des logiciels malveillants, consultez le rapport « Problèmes de sécurité » dans Search Console. Vérifiez aussi les pages connues de Google avec une recherche site:votredomaine.fr. Les avertissements ou pages indésirables ne disparaissent pas immédiatement : Google doit repasser sur le site et, si nécessaire, recevoir une demande de réexamen.

Éviter qu’un correctif urgent devienne une nouvelle urgence

Cette alerte rappelle un point simple : WordPress peut être à jour alors que PHP est géré ailleurs, par l’hébergeur ou une équipe système. La maintenance doit couvrir toute la chaîne. L’enjeu n’est pas de tout bloquer, mais de savoir qui met à jour quoi, d’avoir des sauvegardes utilisables et de repérer vite une anomalie.

Après une faille PHP, la bonne question n’est pas seulement « est-ce mis à jour ? ». C’est aussi : « pouvons-nous vérifier ce qui s’est passé avant le correctif ? ». Un symptôme, une alerte ou une activité inhabituelle mérite d’être regardé comme un incident. Une vérification calme et ordonnée évite autant la panique que le faux sentiment de sécurité.

À lire ensuite

Un pare-feu ne nettoie pas un WordPress déjà compromis

Un pare-feu peut bloquer une nouvelle attaque. Il ne retire pas une redirection pirate, un accès caché ou des pages injectées déjà présentes.

Lire cet article ↗

Besoin d’un avis clair sur votre site ?

Premier échange clair · Priorités concrètes

Je peux vous aider à comprendre la situation, identifier les points importants et définir une intervention adaptée.

Planifier un échange Demander un diagnostic

Premier échange gratuit · Sans engagement · Réponse rapide