En bref : si vous soupçonnez que votre serveur a été piraté via PHP2Shell, contactez-nous maintenant. Vous êtes concerné ? Appelez-nous. Nous vous aidons. Dès le premier message, nous prenons en charge le confinement, sécurisons les traces, fermons la faille, supprimons le code malveillant et documentons l'incident jusqu'à sa clôture.
Ne supprimez rien et ne réinstallez rien pour l'instant. Les fichiers supprimés et les journaux écrasés sont les traces qui montrent si quelqu'un est entré et comment. Si nécessaire, déconnectez le serveur du réseau, mais laissez-le inchangé. Signaler une urgence : nous vous indiquons la prochaine étape.
Êtes-vous concerné ? Signes que PHP2Shell a déjà été exploité
PHP2Shell est le nom donné à deux failles critiques dans PHP lui-même, qui permettent à des attaquants d'exécuter du code malveillant à distance, sans authentification. Il n'existe pour l'instant aucune empreinte univoque. Ce qui compte, c'est donc ce que fait le serveur, pas ce qu'un scanner trouve. Voici les indices d'une intrusion :
- Des processus du serveur web ou de PHP-FPM qui lancent un shell comme
shoubash. C'est un signal d'alerte fort. - Des fichiers PHP nouveaux ou modifiés dans les dossiers d'envoi, de cache ou temporaires, que personne n'a créés.
- Des tâches cron, des services ou des clés SSH que vous ne connaissez pas.
- Des connexions sortantes vers des destinations inconnues, une charge soudainement élevée ou un trafic inhabituel.
- Des requêtes dans les journaux à partir du 17 octobre 2026, notamment des envois de fichiers et des requêtes de session inhabituels avant l'application du correctif.
- Des signalements de l'hébergeur, du navigateur ou d'un moteur de recherche concernant du spam, des logiciels malveillants ou des redirections.
Vous en saurez plus sous Suis-je déjà compromis ?. L'absence de tout signe ne prouve pas que le serveur est sain. Cela signifie seulement que rien n'a attiré l'attention jusqu'ici.
Ce que vous faites tout de suite
- Ne modifiez rien. Ne supprimez aucun fichier, ne restaurez aucune sauvegarde, ne réinstallez rien avant que tout ait été sécurisé.
- Sécurisez les journaux. Demandez à votre hébergeur ou à votre service informatique de ne pas écraser les journaux d'accès, d'erreurs et système. La presse spécialisée conseille de conserver les journaux à partir du 20 octobre 2026.
- Décidez de l'accessibilité. Si des données risquent de fuir ou si des visiteurs peuvent être mis en danger, mettez le site hors ligne ou en mode maintenance.
- Rassemblez les accès. Notez qui a accès au serveur, au panneau d'administration, au CMS et à la base de données. Ne changez les mots de passe qu'après concertation, et depuis un appareil sain.
- Informez les bonnes personnes. La direction, le délégué à la protection des données et, si vous avez une police d'assurance, l'assureur.
- Appelez-nous ou écrivez-nous. Plus tôt nous connaissons la situation, plus il reste d'éléments démontrables.
Comment PHP SOS aide-t-il concrètement ?
Nous travaillons à distance, sans déplacement, dans toute l'Allemagne et en Europe.
- Faire le point : nous clarifions quels systèmes sont en service, quel mode d'exécution de PHP est utilisé, ce qui a attiré l'attention et quelles données peuvent être concernées.
- Sécuriser et fermer : nous sécurisons les fichiers, la base de données et les journaux, et nous constatons l'état avant toute modification. Ensuite, nous fermons la faille par le correctif ou, si celui-ci n'est pas encore possible, par des mesures transitoires, et nous redémarrons tous les processus PHP.
- 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 ou reconstruisons l'état à partir de sources fiables. La démarche est décrite dans Faire supprimer les logiciels malveillants et les webshells.
- Durcir et rendre compte : nous remplaçons les secrets concernés, renforçons les mesures de protection et fournissons un rapport qui distingue ce qui est établi, ce qui est probable et ce qui est inconnu.
Si l'incident dépasse un seul serveur, nous passons à une réponse aux incidents structurée. S'il faut des preuves recevables devant un tribunal, nous faisons appel à la forensique informatique.
Pourquoi un correctif seul ne suffit pas après une attaque
Les failles se trouvent dans l'interpréteur PHP, pas dans le CMS. Le projet PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Qui a mis à jour ensuite et redémarré tous les workers est protégé contre de nouvelles attaques par cette voie. Mais ce qu'un attaquant a déposé auparavant reste en place : une webshell, un compte supplémentaire, une tâche planifiée. C'est précisément pourquoi les jours entre le 17 et le 21 octobre sont particulièrement importants.
À cela s'ajoute un second point : une webshell n'est souvent que la première étape. Qui pouvait exécuter du code sur le serveur web pouvait aussi lire des fichiers de configuration et en reprendre les accès à la base de données, à la messagerie et aux API. Ces secrets doivent être remplacés, sinon la porte reste ouverte même si PHP est corrigé. Le guide sur la détection des webshells explique comment examiner sensément les fichiers et les dates.
Obligation de notification et documentation
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 devenir nécessaire. Le délai court à partir de la prise de connaissance, pas à partir de la fin de l'enquête. Il appartient au délégué à la protection des données ou à un avocat de décider si votre cas doit être notifié ; nous ne fournissons pas de conseil juridique. Notre documentation en fournit la base. Pour en savoir plus sur le délai, voir Obligation de notification RGPD en 72 heures, et pour les étapes suivantes, la liste de contrôle après un piratage.
Ce que vous devriez nous envoyer
- Une description de ce qui est remarqué, depuis quand, et par qui
- Le type de serveur : serveur dédié, serveur géré ou offre d'hébergement, ainsi que l'hébergeur
- Le résultat de
php -vet, si elle est connue, le mode d'exécution (PHP-FPM, mod_php, LiteSpeed) - La date de la mise à jour de PHP, si elle a déjà été appliquée
- L'accès au serveur ou l'autorisation de parler avec votre hébergeur
- Une personne de contact habilitée à décider des arrêts et des redémarrages
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, qui vous accompagne du premier message jusqu'à la clôture. Tout ce que nous faisons est documenté, afin que vous puissiez le justifier auprès de la direction, de l'assureur et des autorités. Nous ne promettons rien que personne ne puisse tenir : si des journaux manquent, nous le disons ouvertement, et nous indiquons ce qui est établi et ce qui reste une supposition.
Vous êtes concerné ? Appelez-nous. Nous vous aidons.
N'attendez pas que le soupçon devienne une certitude. Appelez-nous ou écrivez-nous sur WhatsApp. 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.
Questions fréquentes
Suffit-il de mettre PHP à jour si mon serveur a peut-être déjà été piraté ?
Non. La mise à jour ferme la faille, mais elle ne supprime pas un logiciel malveillant déjà introduit et ne prouve pas que rien ne s'est produit auparavant. Après le correctif, le serveur doit être examiné à la recherche de traces d'une intrusion.
Comment reconnaître une attaque PHP2Shell réussie ?
Il n'existe aucun indicateur de compromission (IOC) publié et confirmé. La détection repose sur le comportement : des processus du serveur web qui lancent un shell, de nouveaux fichiers PHP dans les dossiers d'envoi ou de cache, des tâches cron ou des clés SSH inconnues et des connexions sortantes inhabituelles.
Dois-je déconnecter le serveur du réseau si je soupçonne une intrusion ?
C'est souvent la bonne décision : le BSI (l'office fédéral allemand de la sécurité des technologies de l'information) conseille même, lorsque la mise à jour n'est pas possible immédiatement, de retirer temporairement le serveur web du réseau. L'essentiel est de ne rien supprimer et de conserver les journaux et les fichiers, afin que l'incident puisse être élucidé.
Dois-je informer l'autorité de protection des données après une attaque PHP2Shell ?
Si des données personnelles ont pu être touchées, une notification dans un délai de 72 heures peut être nécessaire. La décision se prend avec votre délégué à la protection des données ou un avocat ; nous fournissons les faits techniques pour cela.
Des serveurs ont-ils vraiment déjà été piratés via PHP2Shell ?
Selon des articles de presse, les premières tentatives d'attaque observées datent du 17 octobre 2026, et Cloudflare a fait état de tentatives d'attaque observées. Le BSI n'a d'abord signalé aucune attaque réussie confirmée à grande échelle. Dans un cas précis, seul le serveur lui-même permet de trancher.