# Webshell découverte ? Réagissez correctement maintenant

> Webshell ou fichier PHP suspect trouvé ? Ne le supprimez pas, sécurisez-le. Nous clarifions l'étendue et la faille. Appelez-nous ou écrivez sur WhatsApp.

Source : https://phpsos.de/fr/soforthilfe/webshell-gefunden/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** une webshell est un petit fichier par lequel un tiers peut piloter votre serveur à distance. Qui en a trouvé une est très probablement concerné et devrait nous contacter immédiatement. Ne pas la supprimer, ne pas l'ouvrir, d'abord la sécuriser. Nous clarifions à distance comment elle est arrivée sur le serveur, s'il existe d'autres accès, et nous nettoyons le serveur.

> **Agir immédiatement:**
> **Ne supprimez rien et ne réinstallez rien pour l'instant.** La webshell elle-même reste d'abord en place, afin de pouvoir être sécurisée. Vous êtes concerné ? Appelez-nous ou écrivez-nous sur WhatsApp, ou signalez la découverte via [Signaler une urgence](https://phpsos.de/fr/notfall/).

## Vous avez trouvé une webshell : qu'est-ce que cela signifie ?

Une webshell est un script PHP (ou un script dans un autre langage de serveur) qui reçoit des commandes de l'extérieur. Les attaquants peuvent ainsi lire des fichiers, télécharger des données, charger du code malveillant et atteindre d'autres systèmes. Le fichier est donc rarement la cible de l'attaque. C'est la porte dérobée qu'un intrus laisse derrière lui pour revenir.

Cela a deux conséquences. Premièrement : quelqu'un avait déjà un accès en écriture à votre serveur ou pouvait exécuter du code. Deuxièmement : le fichier trouvé n'est probablement pas le seul. S'y ajoute ce que l'on ignore souvent : depuis quand se trouve-t-il là et qu'en a-t-on fait entre-temps ?

## À quoi reconnaît-on une webshell

- un fichier PHP dans un dossier où il ne devrait pas y en avoir, par exemple les envois, le cache, les images ou les répertoires temporaires
- des noms de fichiers qui ressemblent à des fichiers système mais n'appartiennent pas à votre logiciel, ou des noms à double extension
- du code illisible avec de longues chaînes de caractères, de l'encodage et des fonctions d'exécution de commandes, voir [Reconnaître le code PHP obfusqué](https://phpsos.de/fr/blog/verschleierter-php-code/)
- une date de modification qui ne correspond pas à vos mises à jour
- des accès à ce fichier dans les journaux, souvent depuis des adresses étrangères et avec des requêtes POST
- des processus du serveur web qui lancent un shell, comme décrit dans [Signal d'alerte : le serveur web lance un shell](https://phpsos.de/fr/blog/webserver-startet-shell/)

Pour interpréter correctement les trouvailles, voir [Fichiers PHP dans le dossier d'envoi](https://phpsos.de/fr/blog/php-dateien-im-upload-ordner/) et, de façon détaillée, [Reconnaître et supprimer les webshells](https://phpsos.de/fr/ratgeber/webshell-erkennen/).

## Ce que vous faites tout de suite

1. **Ne pas appeler le fichier et ne pas l'exécuter.** Aucun test dans le navigateur.
2. **Ne pas le supprimer et ne pas le déplacer.** Ne modifiez ni le contenu ni l'horodatage.
3. **Noter :** le chemin complet, le nom du fichier, le moment de la découverte, qui l'a découvert et avec quoi.
4. **Sécuriser le fichier et ses métadonnées :** une copie avec le propriétaire, les droits et les horodatages. Des commandes de vérification en lecture seule suffisent, par exemple :

   ```bash
   stat /pfad/zur/datei.php
   sha256sum /pfad/zur/datei.php
   ```

5. **Conserver les journaux :** ne laissez pas écraser les journaux d'accès et d'erreurs du serveur web et de PHP. La presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026.
6. **Isoler le serveur si nécessaire :** si vous supposez que des données fuient, retirez le site du réseau. La page [Sécuriser les preuves avant de réinstaller](https://phpsos.de/fr/blog/beweise-sichern-vor-neuinstallation/) décrit comment conserver les preuves à cette occasion.
7. **Nous informer** avant que des mots de passe ne soient changés ou des fichiers nettoyés.

## Comment PHP SOS aide-t-il concrètement ?

1. **Faire le point :** qu'est-ce qui a été trouvé, où, quand et par qui ? Quels systèmes se trouvent sur le même serveur ?
2. **Sécuriser et fermer :** nous sécurisons la trouvaille, les fichiers, la base de données et les journaux, et nous bloquons les accès qui paraissent suspects.
3. **Examiner et nettoyer :** nous recherchons d'autres webshells, des fichiers du cœur modifiés, des [tâches cron cachées](https://phpsos.de/fr/blog/cronjobs-als-hintertuer/), des comptes administrateur étrangers et des [clés SSH inconnues](https://phpsos.de/fr/blog/ssh-schluessel-pruefen/), et nous les supprimons. La démarche correspond à la prestation [Supprimer les logiciels malveillants et les webshells](https://phpsos.de/fr/leistungen/malware-entfernung/).
4. **Durcir et rendre compte :** nous désignons la porte d'entrée probable, la fermons et sécurisons le serveur. Vous recevez une documentation avec les éléments trouvés et une chronologie.

## Comment la webshell est-elle arrivée sur le serveur ?

Les voies typiques sont des plug-ins ou des extensions obsolètes, des envois de fichiers non sécurisés, des identifiants volés et des failles dans les logiciels du serveur. Depuis la publication de PHP2Shell s'ajoute une possibilité supplémentaire : un PHP sans les correctifs de 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 peut être détourné à distance pour exécuter du code. Il n'existe pas d'indicateurs de compromission confirmés à ce sujet ; la détection repose sur le comportement. Que l'entrée se soit faite chez vous via PHP2Shell ou par une autre voie, on ne peut le déduire que des traces, et nous indiquons ce qui est établi et ce qui relève de la supposition. [Analyser les journaux du serveur web](https://phpsos.de/fr/ratgeber/logfiles-auswerten/) montre comment les journaux aident.

Un correctif ne supprime pas une webshell existante. La protection contre de futures trouvailles en fait aussi partie : [Interdire l'exécution de PHP dans les dossiers d'envoi](https://phpsos.de/fr/blog/php-in-uploads-verbieten/) empêche de nombreux cas. Tenez en outre compte des [limites des scanners de logiciels malveillants](https://phpsos.de/fr/blog/grenzen-von-malware-scannern/) : une analyse sans résultat n'est pas un signal de fin d'alerte.

Si vous devez savoir précisément ce qui s'est passé, par exemple pour l'assureur ou les autorités, une [forensique informatique](https://phpsos.de/fr/leistungen/it-forensik/) peut être judicieuse.

## Et si la webshell revient après avoir été supprimée ?

Cela arrive souvent et a généralement deux raisons. Soit il existe au moins une autre porte dérobée qui recrée la trouvaille, soit la porte d'entrée est toujours ouverte et l'attaquant revient simplement. Aucun des deux cas ne se règle en supprimant à répétition. Nous recherchons donc l'ensemble des modifications : fichiers nouveaux et modifiés, entrées dans la base de données et la configuration, tâches planifiées, comptes. Une [liste des fichiers récemment modifiés](https://phpsos.de/fr/blog/geaenderte-dateien-finden/) est un bon début, mais ne remplace pas l'examen par des spécialistes.

## Ce que vous devriez nous envoyer

- le chemin et le nom du fichier, si possible sous forme de copie avec les horodatages (nous convenons du mode de transmission)
- des extraits des journaux d'accès autour de ce fichier, si vous y avez accès
- le type de serveur, l'hébergeur, la version de PHP et le mode d'exécution, s'ils sont connus
- quels sites web et applications fonctionnent sur le serveur
- quand ont eu lieu pour la dernière fois des mises à jour, des envois ou des modifications

## Pourquoi PHP SOS

Nous travaillons Made in Germany et, avec notre réseau de partenaires de professionnels de la cybersécurité, nous sommes spécialisés depuis plus de 25 ans dans la sécurité informatique. Un interlocuteur vous guide tout au long de l'incident. Nous travaillons à distance, sans déplacement, partout en Allemagne et en Europe, documentons chaque étape et ne faisons aucune promesse que personne ne peut tenir. Nous restons à vos côtés jusqu'à ce que l'incident soit clos et documenté.

## Vous êtes concerné ? Appelez-nous. Nous vous aidons.

Une webshell découverte est un signal d'alerte à prendre au sérieux. Contactez-nous maintenant, par téléphone ou WhatsApp, et nous prenons le relais dès le premier message. [Signaler une urgence maintenant](https://phpsos.de/fr/notfall/)


## Questions fréquentes

**J'ai trouvé une webshell. Puis-je simplement supprimer le fichier ?**  
Pas en premier, s'il vous plaît. Le fichier montre quand et avec quoi l'attaquant est venu. Sécurisez-le d'abord avec ses horodatages et son propriétaire, puis il sera retiré de façon ciblée. Qui se contente de supprimer laisse généralement d'autres accès.

**Dois-je ouvrir le fichier suspect dans le navigateur pour voir ce qu'il fait ?**  
Non. Un appel peut exécuter le code malveillant et brouiller d'autres traces. Examinez le fichier en lecture seule uniquement, et de préférence sur une copie.

**Un scanner de logiciels malveillants suffit-il pour trouver toutes les webshells ?**  
Pas de façon fiable. Les scanners reconnaissent des schémas connus, mais les webshells obfusquées ou nouvellement conçues leur échappent. Une analyse sans résultat ne prouve pas qu'il ne reste plus rien.

**Comment savoir depuis combien de temps la webshell se trouve sur le serveur ?**  
La date de modification, les journaux d'accès et d'erreurs ainsi que la comparaison avec d'autres fichiers récents donnent des indices. Les horodatages peuvent toutefois être falsifiés. C'est pourquoi nous évaluons plusieurs sources et indiquons ce qui est établi et ce qui relève de la supposition.

**Dois-je déclarer cette découverte ?**  
Dès que des données personnelles ont pu être touchées, une notification à l'autorité de contrôle peut être nécessaire. Les délégués à la protection des données ou les avocats vous conseillent à ce sujet ; nous fournissons les faits techniques.

## Sources

- [BSI : Office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [RGPD art. 33 : notification à l'autorité de contrôle](https://dsgvo-gesetz.de/art-33-dsgvo/)
