# Serveur piraté : que faire ? Premiers gestes et aide d'urgence

> Serveur piraté, que faire ? Ne rien supprimer, préserver les traces, clarifier les accès. Nous prenons le relais à distance. Appelez ou WhatsApp.

Source : https://phpsos.de/fr/soforthilfe/server-gehackt-was-tun/  
É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 :** vous êtes concerné ? Appelez-nous. Nous vous aidons. Si vous soupçonnez que votre serveur a été piraté, une seule chose compte d'abord : préserver les traces. À distance, dès le premier message, nous prenons en charge l'état des lieux, la sécurisation, le confinement, le nettoyage et la documentation, jusqu'à la clôture de l'incident.

> **Agir immédiatement:**
> **Ne supprimez rien et ne réinstallez rien pour l'instant.** Ne restaurez pas non plus de sauvegarde avant que tout ait été sécurisé. Qui range détruit précisément les traces qui montrent comment l'attaquant est entré. [Signaler une urgence](https://phpsos.de/fr/notfall/), et nous procéderons ensemble.

## Êtes-vous concerné ? Signes qu'un serveur a été piraté

Un soupçon suffit pour nous contacter. Vous n'avez pas à prouver l'attaque. Voici des indices typiques :

- Le serveur web ou PHP-FPM lance des processus comme `sh` ou `bash`. C'est un signal d'alerte fort, que nous expliquons sur la page [Le serveur web lance un shell](https://phpsos.de/fr/blog/webserver-startet-shell/).
- Des fichiers PHP nouveaux ou inconnus se trouvent dans les dossiers d'envoi, de cache ou temporaires.
- Il existe des tâches cron que personne n'a créées, ou des clés SSH que personne ne sait attribuer.
- La charge est élevée sans raison apparente, ou le serveur établit des connexions sortantes inhabituelles.
- Les e-mails de votre serveur atterrissent dans les courriers indésirables ou sont rejetés.
- L'hébergeur, un client ou un avertissement du navigateur signale du code malveillant.
- Des comptes administrateur que personne n'a créés apparaissent dans le CMS.

D'autres signes figurent sous [Suis-je déjà compromis ?](https://phpsos.de/fr/php2shell/bin-ich-gehackt-anzeichen/). Si plusieurs points s'appliquent, traitez le serveur comme piraté jusqu'à preuve du contraire.

## Serveur piraté : ce que vous faites tout de suite

1. **Garder son calme et ne rien modifier.** Aucun fichier supprimé, aucune « réparation rapide », aucune réinstallation par-dessus l'ancien état.
2. **Noter l'heure.** Consignez ce que vous avez observé et quand, et qui a modifié le système en dernier.
3. **Conserver les journaux.** Les journaux d'accès, d'erreurs et système ne doivent ni être tournés ni être écrasés. Pour PHP2Shell, la presse spécialisée conseille de conserver les journaux du serveur à partir du 20 octobre 2026.
4. **Réduire la surface d'attaque.** Retirez le serveur du réseau public ou bloquez-le avec le pare-feu si des données risquent de fuir. Ne vous contentez pas de l'éteindre.
5. **Rassembler les accès.** Qui a un accès SSH, panneau, FTP, CMS et base de données ? Ne changez les mots de passe qu'après concertation et uniquement depuis un appareil sain.
6. **Désigner un interlocuteur.** Une personne habilitée à décider doit être joignable, y compris pour les arrêts et les redémarrages.
7. **Contactez-nous maintenant.** Appelez-nous ou écrivez-nous sur WhatsApp. Nous clarifions tout le reste avec vous, étape par étape.

## Retirer du réseau ou laisser tourner ?

C'est la question la plus fréquente dans les premières minutes, et elle n'a pas de réponse générale. Pour une boutique en ligne avec des paiements ou un portail contenant des données clients, la protection des données l'emporte généralement. Un isolement temporaire est alors la bonne solution, par exemple via une page de maintenance ou une règle de pare-feu qui n'autorise que vos administrateurs.

Un arrêt brutal est en revanche rarement la meilleure première mesure, car la mémoire vive contient des traces qu'un redémarrage efface. Il vaut mieux faire une image du système, par exemple un instantané chez l'hébergeur, avant que quoi que ce soit ne soit modifié. Dans la situation PHP2Shell, le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) recommande de retirer temporairement les serveurs web du réseau lorsqu'une mise à jour n'est pas possible immédiatement. Cela ne signifie pas que tout serveur mis hors service a été piraté.

Dans votre cas, nous décidons avec vous s'il faut isoler, limiter ou laisser tourner, en fonction de ce que contient le système.

## Reconstruire ou nettoyer ?

Beaucoup voudraient surtout reconstruire immédiatement le serveur. Ce n'est pas faux, mais seulement après la sécurisation. Sinon, on ne sait pas comment l'attaquant est entré, et la même voie reste ouverte au nouveau système. La page [Réinstaller le serveur ou le nettoyer ?](https://phpsos.de/fr/blog/neu-aufsetzen-oder-bereinigen/) décrit l'arbitrage, et la page [Sécuriser les preuves avant de réinstaller](https://phpsos.de/fr/blog/beweise-sichern-vor-neuinstallation/) la sécurisation avant une reconstruction.

Important : une mise à jour de PHP ne résout pas à elle seule le problème. Elle ferme la faille, mais ne supprime pas un logiciel malveillant déjà introduit. Pour savoir comment retrouver les traces dans les journaux, voir [Analyser les journaux du serveur web après une attaque](https://phpsos.de/fr/ratgeber/logfiles-auswerten/). Et partez du principe que des identifiants contenus dans les fichiers de configuration ont été lus : les accès à la base de données, à la messagerie et aux API doivent figurer sur la liste des secrets à renouveler.

## Comment PHP SOS aide-t-il concrètement ?

1. **Faire le point :** nous clarifions avec vous ce qui a été observé, quels systèmes peuvent être concernés et quelles données s'y trouvent.
2. **Sécuriser et fermer :** nous sécurisons les fichiers, la base de données et les journaux avant toute modification. Ensuite, nous contenons l'attaque et fermons la porte d'entrée, pour PHP2Shell avec le correctif et le redémarrage de tous les processus PHP.
3. **Examiner et nettoyer :** nous recherchons les webshells, les portes dérobées, les tâches cron et les accès étrangers, et nous les supprimons. Les détails figurent sous [Faire supprimer les logiciels malveillants et les webshells](https://phpsos.de/fr/leistungen/malware-entfernung/).
4. **Durcir et rendre compte :** vous recevez une documentation avec chronologie, éléments trouvés et recommandations. Si l'incident dépasse un seul serveur, nous passons à une [réponse aux incidents](https://phpsos.de/fr/leistungen/incident-response/) structurée.

## Ce que vous ne devriez pas faire

Dans le stress, des erreurs évitables se produisent. Ne supprimez pas de fichiers « suspects » sur simple soupçon sans les avoir sécurisés au préalable. N'exécutez pas de commandes tirées de forums que vous ne comprenez pas. Et n'installez pas de plug-ins de sécurité sur un serveur peut-être déjà compromis : un code malveillant peut tromper les scanners, et le résultat vous berce d'une fausse sécurité. Méfiez-vous aussi des conseils qui proposent de bloquer toutes les requêtes portant un identifiant de session précis ; des auteurs spécialisés rejettent expressément de tels conseils pour PHP2Shell. Vous pouvez vérifier sûrement votre propre version avec `php -v` et un coup d'œil au journal des modifications du paquet de votre distribution, car les backports laissent souvent le numéro de version inchangé.

## Ce que vous devriez nous envoyer

- une courte description : ce qui a été remarqué, depuis quand, ce qui a été modifié en dernier
- le type de système : serveur dédié, serveur virtuel, serveur géré ou offre d'hébergement
- l'accès par SSH ou par le panneau, ou l'autorisation de parler avec votre hébergeur
- des indications sur les sauvegardes existantes et leur ancienneté
- les messages d'alerte de l'hébergeur, du navigateur ou de clients, dans leur formulation exacte

S'il vous manque quelque chose, contactez-nous quand même. Nous comblons les lacunes au fil de la conversation.

## 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. Vous avez un interlocuteur unique, nous travaillons à distance, sans déplacement, partout en Allemagne et en Europe. Chaque étape est documentée, et nous distinguons ouvertement ce qui est établi, ce qui est probable et ce qui est inconnu. Nous ne faisons pas de promesses que personne ne peut tenir. Un aperçu du suivi figure dans la [liste de contrôle après un piratage](https://phpsos.de/fr/ratgeber/checkliste-nach-dem-hack/), et toute l'aide d'urgence sous [Site web piraté ? Aide d'urgence à distance](https://phpsos.de/fr/leistungen/website-gehackt-notfallhilfe/). Sur l'obligation de notification en cas de violation de données, lisez la [règle des 72 heures](https://phpsos.de/fr/compliance/dsgvo-meldepflicht-72-stunden/) ; l'appréciation juridique reste du ressort des délégués à la protection des données et des avocats.

## Vous êtes concerné ? Appelez-nous. Nous vous aidons.

N'attendez pas que le soupçon devienne un dommage plus grave. Nous prenons le relais dès le premier message et restons à vos côtés jusqu'à ce que l'incident soit clos et documenté. [Signaler une urgence maintenant](https://phpsos.de/fr/notfall/).


## Questions fréquentes

**Serveur piraté : dois-je l'éteindre immédiatement ?**  
Pas dans la précipitation. Une extinction peut détruire des traces volatiles en mémoire vive. Il vaut mieux déconnecter le serveur du réseau ou l'isoler par le pare-feu, et d'abord le sécuriser. Si vous hésitez, contactez-nous avant.

**Comment savoir si mon serveur a vraiment été piraté ?**  
Des indices sont fournis par les processus lancés par le serveur web, de nouveaux fichiers PHP dans les dossiers d'envoi ou de cache, des tâches cron et des clés SSH inconnues, ainsi que des connexions sortantes inhabituelles. Seule une analyse des journaux et des fichiers donne une certitude. Il n'existe aucun indicateur PHP2Shell confirmé ; la détection repose sur l'analyse du comportement.

**Une mise à jour de PHP suffit-elle si le serveur a déjà été piraté ?**  
Non. Un correctif ferme la porte d'entrée, mais ne supprime pas un logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit auparavant. Après la mise à jour, tous les processus PHP doivent en outre être redémarrés.

**Dois-je déclarer un serveur piraté ?**  
Si des données personnelles ont pu être touchées, une notification à l'autorité de contrôle dans un délai de 72 heures peut être nécessaire. L'appréciation revient à votre délégué à la protection des données ou à votre avocat ; nous fournissons pour cela les faits techniques.

**Puis-je nettoyer moi-même le serveur piraté ?**  
Pour de petits systèmes, c'est possible, mais risqué : qui ne supprime que les fichiers visibles passe souvent à côté de portes dérobées, de tâches cron ou d'accès. Nous vérifions si un nettoyage suffit ou si une reconstruction à partir de sources saines est plus judicieuse.

## Sources

- [BSI : Office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)
- [RGPD art. 33 : notification à l'autorité de contrôle](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)