Quand un site WordPress est compromis, le “nettoyage” ressemble rarement à un simple clic. On enlève ce qu’on voit, puis on s’assure que la porte d’entrée ne reste pas ouverte. Parmi les éléments qui posent le plus de problèmes, il y a les fichiers .php suspects, déposés à des endroits inattendus ou modifiés après coup. Même si vous les trouvez, une question plus subtile revient vite: sont-ils réellement accessibles depuis l’extérieur ?
Vérifier l’accessibilité des fichiers .php suspects, c’est passer du mode “audit” au mode “contrôle opérationnel”. On ne se contente https://gardewp.fr/nettoyage-malware-wordpress/ pas de constater qu’un fichier existe. On vérifie s’il peut être servi par le serveur, s’il est exécutable, et s’il peut encore déclencher une exfiltration, un redirection, ou une charge utile cachée. Cette étape est souvent décisive pour éviter de “nettoyer” partiellement un site qui reste infecté.
Pourquoi l’accessibilité change tout
Dans un incident réel, on observe deux scénarios fréquents. Le premier, le plus visible: un fichier malveillant est directement accessible via une URL. La preuve se voit parfois dans les logs, via des requêtes répétées, ou dans des comportements côté navigateur, redirections, téléchargements forcés, ou pages de spam.
Le second scénario est plus trompeur. Le fichier .php suspect existe, il peut même sembler récent, mais il n’est pas servi. Les causes typiques sont des permissions trop restrictives, un mauvais chemin, une configuration serveur qui bloque l’exécution dans certains répertoires, ou une règle .htaccess qui empêche le traitement PHP. Dans ce cas, supprimer le fichier peut rester nécessaire, mais vous pouvez aussi réduire le risque immédiat en corrigeant la racine du blocage.
J’ai déjà vu un site où un shell PHP était présent dans un répertoire “écrasé” par des règles de sécurité. Tant que la règle restait active, le site ne distribuait rien de malveillant. Le jour où l’équipe a “optimisé” une configuration et rétabli l’exécution PHP, le shell a commencé à répondre. Moralité: vérifier l’accessibilité, c’est aussi vérifier que les défenses ne sont pas en train de dériver.
Repérer les .php suspects, sans se perdre dans le bruit
Avant de parler accessibilité, il faut identifier les bons suspects. Vous pouvez partir de plusieurs signaux, par exemple des alertes de votre hébergeur, des scanners de fichiers, des changements inattendus dans les dates de modification, ou un comportement anormal (URLs ajoutées, spams, trafic étranger).
Sur WordPress, un piège classique est de traiter tous les .php “bizarres” comme malveillants. Des dossiers comme wp-admin et wp-includes contiennent de nombreux fichiers, certains modifiés lors de mises à jour légitimes. Le bon réflexe consiste à croiser au moins deux indices: emplacement inattendu, nom ou contenu incohérent, date de modification récente, taille anormale, et présence de chaînes typiques (base64, eval, gzinflate, fonctions de lecture de fichiers, requêtes réseau, etc.).
Une fois votre liste de fichiers .php “suspects” établie, vous pouvez vérifier l’accessibilité. Et là, la méthode doit être prudente: l’objectif n’est pas de “tester” la charge utile en l’exécutant au hasard, mais de déterminer si le serveur peut servir le fichier et exécuter PHP.
Ce que signifie “accessible” dans un contexte WordPress
“Accessible” ne veut pas dire “malveillant actif”. Techniquement, cela couvre plusieurs couches:
- L’URL correspond-elle à un chemin réel sur le serveur ? Le serveur répond-il avec un code HTTP utile, ou renvoie-t-il une erreur 404 ou 403 ? Le fichier est-il servi en tant que ressource statique, ou bien PHP est-il exécuté ? Le fichier déclenche-t-il du contenu, une redirection, ou un comportement qui indique une exécution ? Les règles de sécurité bloquent-elles le traitement PHP dans ce répertoire, ou bien autorisent-elles l’exécution ?
Pour un fichier .php placé au bon endroit, l’accessibilité peut être directe: http(s)://domaine.tld/chemin/fichier.php. Pour un fichier placé dans un dossier non exposé, l’URL peut exister côté disque mais pas côté web, ou être bloquée par configuration.
La validation passe donc par des tests d’URL, mais aussi par la vérification côté système (droits, directives PHP, configuration serveur). Le tout doit rester mesuré.
Méthode pratique: tester l’URL sans déclencher n’importe quoi
L’approche la plus fiable consiste à analyser la réponse HTTP et les en-têtes, sans pousser le code malveillant à faire davantage que de répondre. Si le serveur exécute PHP, la réponse peut être surprenante même sans paramètres. S’il y a une page blanche, un code 500, une redirection, ou un contenu qui n’a rien à voir avec votre site habituel, c’est un signal fort.
Voici la logique que j’utilise, en restant volontairement “non intrusif”.
Vérification rapide de l’accessibilité
Prenez l’URL exacte correspondant au chemin du fichier suspect (en respectant la casse si votre serveur en tient compte, et sans paramètres). Testez en navigateur ou via une commande client, et observez le code HTTP (200, 403, 404, 500). Regardez les en-têtes renvoyés: présence d’indications de traitement PHP, contenu de type texte ou redirection. Comparez avec un fichier PHP “connu” (un script interne non critique, si vous en avez) pour comprendre votre signature de serveur. Si l’URL renvoie une exécution visible (contenu qui change, erreurs PHP, messages inhabituels), considérez le fichier comme accessible et priorisez l’isolement.Selon votre environnement, vous pouvez obtenir des résultats très différents pour le même fichier, juste parce que les règles Apache, Nginx ou le mode PHP-FPM ne sont pas identiques. Par exemple, un fichier peut être “servi” en réponse 200 mais sans exécution si le serveur le traite comme un fichier statique, ce qui est rare pour .php avec une configuration standard, mais possible si PHP est restreint par répertoire ou via des règles.
Indices supplémentaires: permissions, droits d’exécution et pièges de configuration
Même si l’URL semble inaccessible, il ne faut pas conclure trop vite. Parfois, le serveur renvoie 403 parce que le répertoire est protégé par mot de passe ou par une règle .htaccess. Parfois, il renvoie 404 parce que l’URL n’est pas exposée via un alias, ou parce que la configuration de base bloque cette route.
Côté disque, vous pouvez vérifier les droits et la cohérence. Un fichier PHP malveillant peut avoir des permissions trop ouvertes, souvent lisibles et parfois exécutables par des comptes inattendus. Sur un WordPress propre, les permissions ont tendance à suivre des conventions d’hébergement, mais il n’existe pas une valeur universelle valable partout, parce que les contraintes d’un hébergeur, d’un conteneur, ou d’un durcissement changent les choses.
Ce que vous cherchez plutôt, ce sont des anomalies flagrantes, par exemple des fichiers appartenant à un utilisateur inattendu, ou des droits qui permettraient une modification facile depuis un autre vecteur. Si vous voyez un fichier dans un répertoire improbable, avec un propriétaire et des droits “qui ne collent pas” à votre modèle habituel, c’est un indice utile même si l’URL semble bloquée.
Au-delà des droits, les directives de sécurité comptent énormément. Dans certains setups, l’exécution PHP est désactivée dans des dossiers comme wp-content/uploads ou certains sous-répertoires. Dans d’autres, l’accès est autorisé mais l’exécution est encadrée. Vous ne voulez pas “forcer” la lecture ou lancer une exécution à la main si vous soupçonnez une charge utile active.
Un test utile, quand c’est faisable sans risque, est de vérifier si le serveur renvoie une erreur liée à PHP. Un 500 avec une mention PHP, ou une réponse qui ressemble à une sortie de script PHP, indique que le fichier est effectivement traité. Un 403 ou un 404 indique plutôt un blocage d’accès ou une non-exposition.
Quand l’URL semble inaccessible, mais que le risque reste réel
Il y a un cas qui revient souvent: le fichier .php n’est pas accessible directement, mais il est invoqué indirectement. Un malware peut créer un mécanisme d’appel via un autre fichier accessible. Par exemple, un script légitime ou un plugin compromis peut inclure dynamiquement le fichier suspect, ou bien utiliser une technique de chargement à partir d’un chemin construit.
Donc, même si votre test d’URL retourne 404, vous ne pouvez pas considérer le dossier “innocent”. La bonne démarche est de combiner:
- la vérification d’accessibilité directe via URL, la recherche de références dans des fichiers accessibles, l’examen du contenu suspect pour détecter des appels à d’autres scripts ou des chemins internes, et l’observation des logs.
Dans les cas où j’ai vu ça, le fichier “introuvable” par URL directe était néanmoins déclenché par une tâche liée à une URL déjà connue du site, ou par un hook dans WordPress. En pratique, le test d’URL réduit le risque immédiat, mais il ne remplace pas l’analyse de la chaîne d’infection.
S’appuyer sur les logs pour confirmer ce que l’URL ne dit pas
Les logs HTTP sont souvent la meilleure boussole. Les requêtes ne mentent pas, elles montrent ce que les visiteurs, bots, ou scripts malveillants tentent réellement. Si votre fichier .php suspect est accessible, il est fréquent de voir des tentatives d’accès dans les logs, parfois en rafales.
Même sans liste détaillée des chemins, vous pouvez chercher des motifs: accès à des fichiers .php non usuels, requêtes vers des répertoires rarement visités, codes 404 répétés vers des chemins “bizarres”, ou réponses 200 après une séquence de tentatives.
Là encore, pas de certitude absolue. Il peut y avoir une infection “silencieuse”, ou un attaquant qui n’essaie pas systématiquement depuis votre IP. Mais dans beaucoup de cas, les logs clarifient la question d’accessibilité bien plus vite que des suppositions.
Mettre le site en sécurité avant de faire du ménage “couteau”
Une fois que vous avez identifié un fichier accessible ou potentiellement invoqué, la tentation est de supprimer immédiatement. Je le comprends, mais sur un incident actif, vous pouvez gagner du temps en sécurisant d’abord le périmètre.
Ce que je recommande en pratique, c’est de réduire l’exposition avant de toucher aux fichiers, surtout si vous n’êtes pas certain du niveau de compromission. Un “mode maintenance” via un plugin ou via un fichier de configuration peut suffire pour calmer le trafic opportuniste. Dans certains hébergements, cela se fait par une page maintenance ou une règle serveur. L’idée n’est pas de réparer, c’est de limiter l’exécution pendant que vous analysez.
Si vous avez accès au serveur, isoler rapidement les dossiers exposés, limiter les accès à l’administration, et couper temporairement les vecteurs les plus probables sont des gestes rationnels. Cela dit, chaque environnement a ses contraintes. Couper PHP globalement peut casser votre site et compliquer l’investigation, donc on privilégie souvent un ciblage.
Réflexes pendant l’incident (sans multiplier les actions risquées)
- Mettre le site en maintenance ou réduire l’exposition, surtout si vous observez des requêtes répétées. Protéger l’accès admin (changer mots de passe, vérifier les comptes, retirer les accès persistants). Isoler les fichiers et répertoires suspects, au lieu de modifier à l’aveugle tout le reste. Comparer avec un état connu (commit, sauvegarde récente, ou copie saine) quand c’est disponible. Garder une trace: copies des fichiers suspects et captures d’écran ou exports de logs utiles.
Cette discipline évite de “réparer” en supprimant des preuves, et elle réduit les risques de prolonger l’incident via une configuration cassée.
Supprimer, remplacer, ou corriger l’accès: choisir selon ce que vous observez
L’accessibilité des fichiers .php suspects influence vos décisions. Trois cas se présentent souvent.
Si le fichier est accessible directement et exécute PHP, la priorité est la suppression ou le retrait immédiat, puis la restauration d’un état propre. Mais il faut aussi vérifier que l’attaquant n’a pas laissé d’autres entrées. En général, vous ne voulez pas simplement enlever un fichier visible, vous voulez retrouver la cause et fermer la porte.
Si le fichier est accessible mais renvoie une erreur, il peut s’agir d’un payload partiellement cassé. Là encore, la suppression reste logique, mais vous gagnerez à comprendre pourquoi il échoue. Une configuration qui empêche l’exécution peut aussi être un garde-fou, mais elle peut changer si quelqu’un modifie .htaccess ou la configuration Nginx.
Si le fichier n’est pas accessible en direct, mais qu’il est référencé ou invoqué indirectement, vous devez chercher la logique d’inclusion ou de déclenchement ailleurs. Dans WordPress, cela peut être un fichier dans un plugin, un thème, un mu-plugin, ou un morceau de code ajouté dans functions.php ou un autre point d’entrée. Dans ce cas, vous supprimez le fichier suspect, mais vous corrigez surtout le mécanisme de déclenchement.
Il y a aussi un cas plus subtil: le fichier est inaccessible depuis l’extérieur, mais il est accessible depuis un chemin interne via une règle serveur, une réécriture, ou un script proxy. Par exemple, certaines configurations exposent un “front controller” unique. Si c’est votre architecture, l’URL directe n’est pas un test suffisant, vous devez vous aligner sur vos routes réelles.
Vérification finale: prouver que la porte est fermée
Une fois le ménage fait, la dernière étape consiste à valider. Vérifier l’accessibilité a un sens, mais uniquement si vous revalidez après suppression et restauration.
Concrètement, vous refaites les tests d’URL sur les chemins des fichiers suspects. Si votre suppression a marché et que la restauration est correcte, vous devez voir 404 ou 403, selon votre configuration. Si vous voyez encore une réponse 200 ou une exécution PHP, il y a deux possibilités: fichier encore présent à un autre endroit, ou mécanisme d’inclusion qui produit une sortie équivalente.
Je recommande aussi de contrôler les éléments d’entrée WordPress. La question n’est pas uniquement “le fichier est-il supprimé”, c’est “est-ce que le système peut encore exécuter un code non autorisé”. Pour cela, la rotation des mots de passe, la vérification des fichiers de configuration, et le contrôle des plugins et thèmes installés restent essentiels.
Enfin, surveillez le comportement à court terme. Les infections actives laissent souvent des tentatives dans les logs, et vous verrez vite si le volume diminue après correction. Sur certains hébergements, la vitesse de propagation des changements de fichier et de cache peut créer un décalage, donc ne paniquez pas si un changement ne “prend” pas immédiatement.
Détails importants sur les tests, pour éviter de vous tromper
Quelques points pratiques, parce qu’ils font gagner du temps quand on est en plein incident:
- Un code 403 ne signifie pas “aucun risque”. Il signifie “accès refusé dans ce contexte précis”. Si l’exécution est indirecte, il peut rester un vecteur. Un code 404 peut être un leurre. Si un fichier est déplacé ou si une route réécrit le chemin, vous ne voyez pas forcément ce que le serveur exécute en coulisses. Un 500 peut indiquer une exécution PHP cassée, donc une accessibilité réelle. C’est souvent un signal à traiter comme sérieux. Les tests “sans paramètres” sont un bon début, mais certains payloads se déclenchent seulement avec des requêtes spécifiques. Ne faites pas de “fuzzing”. Cherchez plutôt des traces dans les logs ou le contenu du fichier.
Si vous disposez d’un environnement de test (staging) avec une copie de votre site, vous pouvez analyser les fichiers suspect en local et observer les chemins sans exposer votre production. C’est un luxe, mais quand c’est possible, c’est aussi la façon la plus sûre de comprendre l’architecture d’accès et l’impact réel.
Ce qu’il faut vérifier dans le fichier suspect, avant de l’effacer
Je ne vous conseille pas de lancer le fichier dans un navigateur, même si ça semble tentant. Mieux vaut ouvrir le fichier et lire ce qu’il fait. Vous cherchez surtout:
- des fonctions d’exécution conditionnelles, des chargements dynamiques, comme include ou require sur des chemins construits, des mécanismes qui lisent des fichiers, utilisent curl ou fsockopen, ou exfiltrent via requêtes sortantes, des variables qui suggèrent un déclenchement paramétré, une logique qui redirige vers une autre URL.
Le contenu vous dira souvent si le fichier est un “simple” downloader, un shell interactif, ou un https://gardewp.fr/ implant de persistance. Cette lecture réduit l’incertitude sur l’accessibilité nécessaire. Certains payloads ne donnent rien en réponse directe, mais agissent quand WordPress les appelle.
Il est aussi utile de regarder si le fichier a des métadonnées incohérentes: date de modification récente, taille étrange par rapport à d’autres scripts du même répertoire, encodage compressé dans le code.
Maintenir un site propre après le nettoyage
Nettoyer un WordPress infecté ne suffit pas, il faut empêcher la récidive. Les infections reviennent souvent par un vecteur identique: comptes compromis, plugins obsolètes, thème modifié, ou mauvaise politique de permissions.
Une fois l’incident traité, prenez l’habitude de:
- mettre à jour WordPress et les extensions, supprimer les plugins inutiles, vérifier la cohérence des fichiers (comparaison avec un état sain), et garder des sauvegardes vérifiées.
Sur la partie permissions, le “juste milieu” compte. Trop permissif augmente la surface de modification, trop strict peut casser les déploiements légitimes et inciter à “corriger” en urgence de façon dangereuse. J’ai vu des équipes durcir trop fort après un incident, puis réouvrir ensuite des permissions en vitesse, sans revenir à une méthode propre. Le résultat est un système instable, donc vulnérable.
Si vous n’êtes pas sûr: approcher comme un incident de sécurité, pas comme un ménage de fichiers
Si vous hésitez entre “fichier accessible” et “fichier inoffensif”, traitez-le comme un risque jusqu’à preuve du contraire. La vérification d’accessibilité est précisément faite pour réduire cette zone d’incertitude, mais elle doit s’inscrire dans une approche plus large: observation des logs, restauration d’un état connu, et contrôle des points d’entrée WordPress.
Quand vous combinez ces trois éléments, vous obtenez un résultat robuste: vous supprimez ce qui est mal, vous empêchez l’exécution là où ça compte, et vous validez que le site ne réagit plus comme avant.
Si vous voulez, décrivez-moi votre hébergement (Apache ou Nginx, type de PHP-FPM ou module), et le chemin d’un fichier suspect (juste le répertoire et le nom, sans contenu). Je pourrai vous proposer une méthode de vérification d’URL et d’interprétation des codes HTTP adaptée à votre configuration.