En bref : vous détectez un webshell à des fichiers PHP nouveaux ou modifiés à des emplacements inhabituels, à des processus étrangers de l'utilisateur du serveur web et à des connexions inhabituelles. Préservez les traces avant de supprimer quoi que ce soit et restaurez le code à partir d'une source saine. Un correctif seul ne supprime aucune porte dérobée.
Pourquoi les webshells sont un sujet après PHP2Shell
Les failles CVE-2026-109618 et CVE-2026-109619 dans PHP lui-même permettent l'exécution de code malveillant à distance sans authentification. Après une attaque réussie, un objectif évident est une porte dérobée durable, donc un webshell. Elle subsiste même si PHP a entre-temps été mis à jour.
Selon des articles de presse, une première tentative d'attaque a été observée dès le 17 octobre 2026, les correctifs ont suivi le 21 octobre. Quiconque était vulnérable pendant cette période devrait vérifier de façon ciblée. Aucun indicateur de compromission confirmé n'a été publié jusqu'ici. La recherche repose donc sur des anomalies de comportement, pas sur une liste toute faite.
Si vous trouvez un webshell sur un serveur contenant des données clients : ne supprimez rien dans la précipitation. Préservez d'abord les preuves, puis isolez le serveur et planifiez la suite du traitement.
Comment détecter un webshell : contrôler les fichiers
La plupart des webshells sont des fichiers PHP dans le répertoire web. Sont suspects les fichiers créés ou modifiés après le 17 octobre, les fichiers PHP dans les dossiers d'upload et de cache, ainsi que les fichiers au code obfusqué. Les commandes suivantes ne modifient rien, elles se contentent de lister :
# Fichiers PHP modifiés depuis le 17.10.2026
find /var/www -type f -name "*.php*" -newermt "2026-10-17" -ls
# Fichiers PHP dans les dossiers d'upload, de cache ou tmp
find /var/www -type f -name "*.php*" \( -path "*upload*" -o -path "*cache*" -o -path "*tmp*" \) -ls
# Obfuscation typique : eval combiné à un décodage
grep -rlE "eval\s*\(\s*(base64_decode|gzinflate|str_rot13|gzuncompress)" /var/www --include="*.php"
# Des lignes très longues indiquent souvent du code compressé
grep -rlE ".{3000,}" /var/www --include="*.php"
Les résultats sont des indices, pas des preuves. Certains plugins utilisent légitimement du code encodé. Comparez les fichiers suspects avec le paquet d'origine de l'éditeur. Le plus fiable est une comparaison avec des sommes de contrôle ou un système de gestion de versions comme Git :
# Écarts par rapport au dernier état connu dans le dépôt Git
git -C /var/www/projekt status --porcelain
Un horodatage peut être falsifié. Ne vous fiez donc pas uniquement à la date de modification d'un fichier.
Quelles caractéristiques rendent un fichier suspect
| Caractéristique | Pourquoi elle attire l'attention |
|---|---|
| Fichier PHP dans un dossier d'upload ou d'images | Il ne devrait y avoir que des médias |
Double extension comme .jpg.php ou .php.png |
Camouflage en fichier inoffensif |
| Très longues lignes sans retour à la ligne | Typique d'un code compressé ou chiffré |
| Nom de fichier proche d'un fichier du noyau, mais absent du paquet d'origine | Camouflage dans un environnement connu |
| Propriétaire ou droits différents de ceux des fichiers voisins | Le fichier a été créé par un autre moyen |
Plus il y a de caractéristiques réunies, plus la probabilité d'une découverte est élevée. N'ouvrez les fichiers suspects que comme texte, jamais par le navigateur, car un appel via le site exécuterait le code.
Contrôler les processus, les connexions et les tâches cron
Un webshell actif laisse souvent des traces en dehors du système de fichiers. L'utilisateur du serveur web, par exemple www-data, apache ou nginx, ne lance normalement ni shells, ni outils réseau, ni compilateurs.
# Processus des utilisateurs typiques du serveur web
ps -eo user,pid,ppid,lstart,cmd | grep -E "^(www-data|apache|nginx)"
# Connexions réseau ouvertes avec le processus associé
sudo ss -tunap | grep -E "php|www-data|apache|nginx"
# Tâches planifiées de l'utilisateur du serveur web
sudo crontab -u www-data -l
ls -la /etc/cron.d /var/spool/cron 2>/dev/null
Sont suspectes les connexions sortantes durables vers des destinations inconnues, les processus aux noms cryptiques et les tâches cron qui téléchargent des fichiers depuis Internet. Contrôlez en outre dans les journaux d'accès les requêtes vers des fichiers qui n'existaient pas auparavant. Le guide Analyser les journaux du serveur web après une attaque explique comment faire.
Préserver les traces avant de supprimer
Qui supprime d'abord perd la réponse aux questions les plus importantes : comment l'attaquant est-il entré, qu'a-t-il vu, quelles données sont concernées ? Vous avez besoin de ces réponses pour une éventuelle notification au titre du RGPD, pour les assureurs et pour décider si d'autres systèmes sont menacés.
Ordre judicieux :
- Documenter l'état : liste des processus, connexions réseau, utilisateurs connectés.
- Copier les fichiers suspects et les journaux avec une somme de contrôle, sans les ouvrir ni les exécuter.
- Si possible, créer une image du système ou un instantané de la machine virtuelle.
- Déconnecter le serveur du réseau ou restreindre fortement l'accès.
Pour les systèmes contenant des données sensibles ou en cas de litige possible, la sauvegarde doit être réalisée dans les règles de l'art forensique. Vous trouverez des informations de fond sous Analyse forensique informatique après une attaque de serveur web.
Supprimer proprement les webshells
Supprimer un seul fichier est rarement la fin de l'histoire. Les attaquants créent souvent plusieurs accès : d'autres fichiers à des endroits cachés, des entrées dans des fichiers de configuration comme .htaccess ou .user.ini, de nouveaux comptes administrateur dans l'application ou des tâches cron. Un nettoyage fiable suit ces étapes :
- Amener PHP à une version corrigée (8.5.12, 8.4.27, 8.3.36, 8.2.35 ou backport confirmé) et redémarrer tous les processus PHP.
- Reconstruire le code de l'application à partir d'une source saine au lieu de réparer des fichiers isolés.
- Ne reprendre que des contenus vérifiés, comme les uploads et la base de données, et y rechercher de façon ciblée du code introduit.
- Changer tous les identifiants : base de données, SSH, FTP, comptes administrateur, clés d'API.
- Limiter les droits d'écriture du serveur web au strict nécessaire et empêcher l'exécution de PHP dans les dossiers d'upload.
Pour WordPress, il existe des cachettes typiques que décrit le guide Trouver les portes dérobées dans WordPress. Ensuite, le site devrait être surveillé de plus près pendant un certain temps afin de remarquer tôt un nouvel accès.
Comment PHP SOS aide-t-il concrètement ?
- Nous sauvegardons journaux, fichiers et état du système de façon traçable avant que quoi que ce soit ne soit modifié.
- Nous recherchons les portes dérobées dans les fichiers, la base de données, les tâches cron et la configuration, et nous qualifions les découvertes.
- Nous réinstallons l'application à partir d'une source saine, changeons les accès et renforçons le serveur.
- Nous documentons l'incident jusqu'à sa clôture, comme base pour les notifications et les assureurs.
Le déroulement d'un nettoyage est décrit par la prestation Faire supprimer malwares et webshells.
Questions fréquentes
Qu'est-ce qu'un webshell ?
Un webshell est un fichier introduit, généralement en PHP, par lequel des attaquants peuvent piloter le serveur à distance. Il se camoufle souvent en fichier anodin au nom discret et reste actif même après une mise à jour.
Un antivirus trouve-t-il tous les webshells ?
Non. Les scanners reconnaissent des motifs connus ; les variantes nouvelles ou fortement obfusquées passent entre les mailles. Pour PHP2Shell, il n'existe en outre aucun indicateur de compromission confirmé publié ; l'analyse du comportement est donc plus importante qu'une liste de signatures.
Suffit-il de supprimer le fichier trouvé ?
Le plus souvent non. Les attaquants créent souvent plusieurs accès, par exemple d'autres fichiers, des tâches cron ou de nouveaux comptes administrateur. Sans analyse de la cause et changement de tous les identifiants, un nouvel accès est probable.
Dois-je signaler quelque chose après la découverte d'un webshell ?
Si des données personnelles peuvent être concernées, une obligation de notification au titre du RGPD peut exister, en principe dans un délai de 72 heures. Clarifiez ce point avec votre délégué à la protection des données ou un avocat ; ceci ne constitue pas un conseil juridique.