# Réinstaller ou nettoyer le serveur ? La décision après une compromission

> Réinstaller ou nettoyer un serveur après un piratage ? Les critères, le bon ordre des opérations et les erreurs typiques de la reconstruction.

Source : https://phpsos.de/fr/blog/neu-aufsetzen-oder-bereinigen/  
É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 :** réinstaller ou nettoyer un serveur après un piratage dépend de la certitude avec laquelle vous connaissez l'ampleur de l'intrusion. Si l'attaquant a peut-être eu des droits root, si le moment de l'intrusion est incertain ou si des journaux manquent, une reconstruction à partir de sources fiables est le choix le plus sûr. Un nettoyage n'entre en ligne de compte que pour une compromission étroitement limitée et bien établie. Dans les deux cas : d'abord conserver les preuves et fermer la faille, ensuite seulement faire le ménage.

## Pourquoi cette question est posée si souvent après PHP2Shell

Selon php.net, PHP2Shell permet d'exécuter du code malveillant à distance sans authentification. Celui qui a exploité un serveur non corrigé doit donc se demander si quelque chose s'est produit depuis le 17/10/2026, date de la première tentative d'attaque observée selon des articles de presse. Le correctif ne répond pas à cette question, et il n'existe aucun indicateur de compromission publié et confirmé.

Si l'on trouve alors un fichier suspect, un processus inconnu ou une tâche cron étrangère, la décision s'impose. L'impulsion est souvent de supprimer vite ou de réinstaller aussitôt. Les deux peuvent être justes, mais pas comme première étape.

## L'ordre avant la décision

Avant de choisir entre nettoyer et réinstaller, trois choses doivent être faites. Elles valent pour les deux voies.

1. **Endiguer :** retirer le serveur du réseau ou limiter l'accès au strict nécessaire, sans l'éteindre si l'on veut encore sauvegarder la mémoire vive.
2. **Conserver les preuves :** sauvegarder journaux, fichiers, base de données et si possible une image du système, avec la date et une somme de contrôle. Pourquoi cela est nécessaire avant toute réinstallation est expliqué dans [Conserver les preuves avant de réinstaller](https://phpsos.de/fr/blog/beweise-sichern-vor-neuinstallation/).
3. **Associer l'assureur et la protection des données :** de nombreuses cyberpolices attendent que les étapes essentielles soient concertées. Des indications figurent dans [Cyberassurance : ce qui compte en cas de sinistre](https://phpsos.de/fr/compliance/cyberversicherung/). Savoir s'il existe une obligation de notification au titre du RGPD, le délégué à la protection des données ou l'avocat l'évaluent.

Ce n'est qu'ensuite que la vraie pesée vaut la peine.

## Réinstaller le serveur après le piratage ou le nettoyer : les critères

| Critère | Nettoyer | Réinstaller |
|---|---|---|
| Ampleur de l'intrusion | Étroitement limitée, établie, par exemple un fichier dans le dossier d'envoi sans autres traces | Incertaine ou avec des indices d'accès au système |
| Droits root possibles de l'attaquant | Exclus avec de bonnes preuves | Non exclus |
| Disponibilité des journaux | Complets pour la période concernée | Lacunaires, écrasés ou manipulables |
| Effort | Moindre, si le constat est clair | Plus élevé, mais mieux planifiable |
| Incertitude restante | Plus élevée, les portes dérobées cachées sont difficiles à exclure | Moindre, si la reconstruction part proprement de sources fiables |
| Durée d'indisponibilité | Le plus souvent plus courte | Le plus souvent plus longue, bien maîtrisable avec de la préparation |
| Adéquation aux anciens systèmes | Problématique si le système est de toute façon obsolète | Bonne occasion de passer à une version de PHP prise en charge |

En règle générale : moins vous en savez, plus la reconstruction s'impose. Avec une faille dans l'interpréteur PHP qui exécute du code dans le contexte de l'utilisateur du serveur web, un attaquant peut exploiter d'autres vulnérabilités pour obtenir plus de droits. Cela ne peut guère être exclu sans enquête approfondie.

## Les deux voies en pratique

### Ce que « réinstaller » signifie vraiment

Réinstaller ne veut pas dire copier l'ancienne sauvegarde sur un serveur neuf. Une reconstruction commence par un système d'exploitation propre issu d'une source officielle, des paquets à jour et une version corrigée de PHP. L'application est installée à partir de l'original de l'éditeur, de même que les extensions et les thèmes.

Ce n'est qu'ensuite que viennent les propres contenus, et vérifiés. Les fichiers téléversés ne doivent contenir aucun script exécutable, la base de données peut contenir des contenus injectés, par exemple des comptes administrateur cachés ou des scripts dans des articles. Les fichiers de configuration sont réécrits au lieu d'être copiés. Tous les identifiants sont renouvelés : base de données, administrateurs du CMS, clés SSH, clés d'API, panneau d'hébergement.

Les sauvegardes jouent ici un rôle important, mais seulement si leur état est antérieur à l'intrusion et si elles n'ont pas été elles-mêmes modifiées. Plusieurs générations en des lieux séparés rendent cela vérifiable ; plus de détails dans [Sauvegardes selon la règle 3-2-1](https://phpsos.de/fr/ratgeber/backups-3-2-1/).

### Quand nettoyer est défendable

Un nettoyage peut être judicieux si la compromission a été découverte tôt, si des journaux complets existent et si l'enquête ne révèle aucun indice d'autres accès. Les fichiers trouvés sont alors supprimés après sauvegarde, les tâches cron, comptes utilisateurs et clés SSH vérifiés, et les fichiers du noyau comparés à l'original de l'éditeur.

Une évaluation réaliste est importante : les webshells sont souvent discrets et cachés à plusieurs endroits. La manière de les trouver est décrite dans [Reconnaître et supprimer les webshells](https://phpsos.de/fr/ratgeber/webshell-erkennen/). Après un nettoyage, le serveur devrait être surveillé de près, pour que ne passe pas inaperçue une porte dérobée oubliée.

> **Agir immédiatement:**
> Ne supprimez rien avant que journaux et fichiers soient sauvegardés, et fermez la faille avant que le serveur ne retourne sur le réseau. Sinon vous perdez les traces et invitez la prochaine intrusion.

## Quand vous n'avez pas besoin de prestataire

Pour un site simple sur hébergement mutualisé, où l'hébergeur gère le système et confirme le correctif PHP, la décision ne vous revient souvent pas. Vous pouvez réinstaller l'application à partir de l'original, vérifier les contenus et renouveler les identifiants, avec le soutien de l'hébergeur. Une équipe interne expérimentée peut aussi mener seule une reconstruction, si la conservation des preuves et la documentation sont en place.

Une aide externe vaut la peine si les droits root ne peuvent être exclus, si des données personnelles pourraient être concernées, si l'assurance est impliquée ou si plusieurs systèmes sont liés.

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

1. Nous sauvegardons journaux, fichiers et base de données de façon probante avant que quoi que ce soit ne soit modifié.
2. Nous évaluons l'ampleur de l'intrusion et recommandons de nettoyer ou de reconstruire avec justification, en distinguant établi, probable et inconnu.
3. Nous reconstruisons au besoin le serveur à partir de sources fiables, avec une version corrigée de PHP et des accès renouvelés.
4. Nous prenons en charge la [suppression des logiciels malveillants](https://phpsos.de/fr/leistungen/malware-entfernung/) là où un nettoyage est défendable, et documentons chaque étape.

## Conclusion

La question « réinstaller ou nettoyer ? » se tranche par la connaissance de l'intrusion. Celui qui ne connaît pas l'ampleur avec certitude reconstruit. Celui qui peut la circonscrire avec des preuves peut nettoyer. Dans les deux cas, le même ordre s'applique : endiguer, conserver, fermer la faille, puis faire le ménage.


## Questions fréquentes

**Réinstaller est-il toujours préférable après un piratage ?**  
Pas toujours, mais souvent. Quand on ignore jusqu'où l'attaquant est allé, une reconstruction à partir de sources fiables est en général le choix le plus sûr. En cas de compromission étroitement limitée et bien établie, un nettoyage peut suffire.

**Puis-je simplement restaurer une ancienne sauvegarde ?**  
Seulement s'il est certain que la sauvegarde date d'avant l'intrusion et ne contient aucune porte dérobée. De plus, la faille doit être fermée au préalable, sinon le serveur est de nouveau vulnérable aussitôt. Les données plus récentes doivent être vérifiées séparément.

**Que dois-je conserver avant de réinstaller ?**  
Les journaux, une copie des fichiers et de la base de données et, si possible, une image du système. Vous avez besoin de ces preuves pour l'analyse des causes, l'assurance et une éventuelle notification. Une fois supprimées, elles sont perdues.

**Suffit-il de supprimer le webshell trouvé ?**  
Rarement. Les attaquants installent souvent plusieurs portes dérobées, par exemple des tâches cron, des comptes utilisateurs ou des clés SSH. Celui qui ne supprime que le fichier visible laisse les autres accès ouverts.

## Sources

- [BSI : informations sur les incidents de sécurité](https://www.bsi.bund.de/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)
- [php.net : avis de sécurité](https://www.php.net/)