Vérifier si votre site a été piraté après PHP2Shell

Existe-t-il des indicateurs officiels de compromission PHP2Shell ?

Au 22 octobre 2026, PHP n’a publié aucune liste définitive d’indicateurs propres à PHP2Shell. Dans un fil de surveillance sur X, les chercheurs de Wiz conseillent de guetter des requêtes multipart inhabituelles suivies d’erreurs de limite de mémoire ou de réponses HTTP 500, des cookies de session PHPSESSID malformés et des processus PHP qui redémarrent anormalement souvent. Plusieurs agences nationales recommandent aussi de rechercher des portes dérobées. Voyez ces signes comme des pistes à creuser, pas comme des preuves. Les vérifications ci-dessous portent sur les signes habituels d’une prise de contrôle de site web.

Que faire avant de vérifier ?

Installez le correctif PHP2Shell et redémarrez PHP. Examiner un site encore vulnérable ne renseigne que sur le passé. Si vous constatez des dégâts en cours (défiguration, spam, redirections), mettez d’abord le site hors ligne.

Comment savoir si mon site a été piraté ?

Cherchez les changements que vous n’avez pas faits :

1. Des comptes administrateur que vous ne reconnaissez pas. Dans WordPress, ouvrez Comptes (Utilisateurs) et filtrez sur Administrateur. Vérifiez aussi les comptes d’hébergement, FTP/SFTP et de base de données.
2. Des fichiers PHP là où ils n’ont rien à faire. Les dossiers d’upload comme wp-content/uploads ne devraient contenir que des images et des documents. Un fichier .php à cet endroit est un signal d’alarme sérieux.
3. Des fichiers modifiés récemment auxquels vous n’avez pas touché. Triez les fichiers par date de modification dans votre gestionnaire de fichiers ; examinez de près tout ce qui a changé depuis l’annonce des vulnérabilités.
4. Des extensions, thèmes ou extensions « must-use » que vous n’avez pas installés. Contrôlez le dossier wp-content/mu-plugins, qui n’apparaît pas dans la liste normale des extensions.
5. Des tâches planifiées que vous n’avez pas créées. Vérifiez les tâches cron dans votre panneau de contrôle ; les attaquants s’en servent pour réinstaller leurs portes dérobées.
6. Des alertes venues de l’extérieur. Avertissements de votre hébergeur, problèmes de sécurité dans la Google Search Console, signalements de spam ou de redirections depuis votre domaine.
7. Les journaux, si vous en avez : requêtes inhabituelles, pics d’erreurs ou plantages autour de la période de divulgation.

Un fichier PHP inconnu prouve-t-il une attaque PHP2Shell ?

Non. Un fichier, un compte ou une redirection inexpliqués prouvent qu’il y a un problème, pas quelle vulnérabilité l’a causé. Enquêtez dans tous les cas.

Que faire si je trouve quelque chose ?

Agissez dans cet ordre, et gardez une copie avant de supprimer quoi que ce soit :

1. Mettez le site hors ligne ou bloquez l’accès public.
2. Conservez les preuves : copies des fichiers suspects, journaux et instantané du serveur, en notant les heures.
3. Changez tous les mots de passe depuis un appareil sain : hébergement, FTP/SFTP, base de données, chaque compte administrateur, ainsi que les clés secrètes du site et les jetons d’API.
4. Restaurez une sauvegarde antérieure à l’intrusion, ou reconstruisez le site à partir de sources fiables, puis mettez à jour PHP, l’application, les thèmes et les extensions avant de remettre le site en ligne.
5. Prévenez votre hébergeur, ainsi que toute personne ou autorité que vous êtes tenu d’informer si des données personnelles ou de paiement ont pu être touchées.

Installer le correctif chasse-t-il un attaquant déjà présent ?

Non. Le correctif ferme la brèche ; il ne supprime ni une porte dérobée, ni un compte malveillant, ni des identifiants volés. Comme la recherche décrit aussi des fuites de mémoire, une vérification des fichiers qui ne révèle rien n’exclut pas non plus une exposition de données.

Faut-il faire appel à un professionnel ?

Oui, si le site traite des paiements ou des données personnelles, si vous ne trouvez pas de sauvegarde saine, si le problème revient après nettoyage, ou si vous ne savez pas jusqu’où l’intrusion est allée. Une équipe de réponse à incident saura évaluer correctement l’étendue des dégâts.

Mon site a-t-il été piraté du seul fait que PHP était vulnérable ?

Pas forcément. Cloudflare a signalé des tentatives d’attaque, mais aucune compromission réussie n’est confirmée dans les sources que nous avons consultées au 22 octobre 2026. Cela ne prouve pas pour autant que votre site est sain. Vérifiez au lieu de supposer. Retour au vérificateur PHP2Shell.

Sur quelles sources s’appuie cette page ?

• Wiz Research : conseils de surveillance (fil sur X)
• Wiz Research : recherche initiale
• CISA : guides de réponse aux incidents et aux vulnérabilités
• CISA/FBI : avis comprenant des conseils de défense contre les web shells
• The PHP Group : avis de sécurité
• Cloudflare : protections WAF