En bref : la faille de sécurité PHP2Shell se compose de deux erreurs critiques dans PHP, la base de la plupart des sites web et boutiques en ligne. Des attaquants peuvent ainsi exécuter du code malveillant sur des serveurs web sans mot de passe. Le BSI (office fédéral allemand de la sécurité des technologies de l'information) alerte au niveau orange et conseille : mettre à jour immédiatement, sinon mettre temporairement hors réseau les serveurs concernés. Pour la direction, cela signifie aujourd'hui : clarifier la responsabilité, exiger la mise à jour et sa preuve, décider d'une éventuelle mise hors ligne et tout documenter.
La situation en trois phrases
Le 21 octobre 2026, le projet PHP a publié des mises à jour pour deux failles de sécurité critiques, connues sous le nom de PHP2Shell. C'est PHP lui-même qui est concerné, non un produit particulier, donc potentiellement chaque site, chaque boutique et chaque portail qui fonctionne avec PHP. Le BSI a déclaré le niveau d'alerte 3 / orange, des sociétés de sécurité font état de tentatives d'attaque ; des attaques réussies confirmées à grande échelle n'étaient, selon le BSI, pas connues dans un premier temps.
Des autorités comme le BKA (office fédéral allemand de la police criminelle) et plusieurs villes ont, selon des articles de presse, mis leurs sites hors ligne par précaution. C'était de la prudence, non le signe d'une attaque.
Ce que la faille de sécurité PHP signifie pour la direction et l'entreprise
La question n'est pas de savoir si vous utilisez PHP. Presque toutes les entreprises le font quelque part : site web, boutique, portail de candidatures, espace client, intranet, système de tickets, microsite d'agence. La question est de savoir si ces systèmes sont à jour et qui en est responsable.
Si une attaque réussit, l'attaquant peut, au pire, prendre le contrôle du serveur. Les conséquences possibles sont des fuites de données, des contenus manipulés, des redirections vers des sites frauduleux, l'indisponibilité de la boutique ou l'utilisation abusive du serveur pour d'autres attaques. Si des données personnelles peuvent être concernées, des obligations de notification s'y ajoutent ; le délai prévu par l'art. 33 RGPD est en règle générale de 72 heures. Les détails figurent sous Obligation de notification RGPD. Ceci n'est pas un conseil juridique.
Les coûts qui surviennent typiquement en cas de sinistre sont présentés dans l'article Postes de coûts d'un piratage.
Où PHP est souvent oublié dans les entreprises
La plupart gardent le site principal à l'œil. On oublie plutôt les systèmes en périphérie : le portail de candidatures d'un prestataire externe, la page d'atterrissage d'une ancienne campagne, un espace partenaires pour revendeurs, le système de tickets du support, un cloud de fichiers sur un serveur propre ou l'interface web d'un stockage réseau. Les systèmes de test des agences sont eux aussi souvent accessibles publiquement et tournent sur le même serveur que le vrai site.
Pour la direction, la leçon est simple : la question à l'informatique n'est pas « Notre site est-il corrigé ? », mais « Tous nos systèmes avec PHP sont-ils corrigés, y compris ceux des prestataires ? ». La différence entre les deux questions est souvent précisément l'endroit où une attaque réussit.
Ce que la situation n'est pas
Le classement vers le bas est tout aussi important. PHP2Shell n'est pas une raison de céder à l'activisme qui perturbe l'activité plus que nécessaire. Qui a corrigé de façon prouvée, redémarré tous les processus PHP et ne trouve aucune anomalie lors de la vérification peut revenir au fonctionnement normal. Une mise hors ligne temporaire est une option pour les cas non clarifiés, non une obligation pour tous.
Cinq questions à poser à votre informatique ou à votre prestataire
Vous pouvez poser ces questions aujourd'hui. Les réponses devraient venir par écrit.
- Lesquels de nos systèmes fonctionnent avec PHP ? Une liste avec adresse, usage et exploitant.
- Chaque système est-il corrigé ? Version corrigée 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou rétroportage confirmé par le fournisseur.
- Tous les processus PHP ont-ils été redémarrés ? Sans redémarrage, la mise à jour n'agit pas.
- Qu'en est-il des systèmes sous PHP 8.1 ou plus ancien ? Il n'existe pas de mises à jour officielles pour eux. Quel est le plan ?
- A-t-on vérifié si quelque chose s'est produit avant la mise à jour ? Journaux sauvegardés à partir du 20 octobre, traces recherchées ?
Si votre site est chez un hébergeur, une demande formelle aide. Un modèle figure dans le guide Demander à l'hébergeur la confirmation de la mise à jour PHP.
Les décisions qui devraient être prises aujourd'hui
| Décision | Options | Base |
|---|---|---|
| Qui pilote ? | une personne responsable en interne, un partenaire externe | la responsabilité doit être sans ambiguïté |
| Systèmes non corrigés | corriger immédiatement, mesures transitoires, mettre temporairement hors ligne | recommandation du BSI, nature des données, importance pour le chiffre d'affaires |
| Recherche de traces | en interne, en externe, seulement en cas d'anomalies | besoin de protection des données sur le serveur |
| Communication | informer en interne, préparer les clients, attendre | situation après la vérification |
| Systèmes anciens | planifier la migration, isoler, mettre hors service | PHP 8.1 et plus ancien sans mises à jour officielles |
Consignez qui a décidé quoi, quand et sur quelle base d'information. Une courte note datée suffit. Elle vaut souvent, après coup, vis-à-vis des assureurs, clients ou autorités de contrôle, plus que n'importe quelle explication a posteriori.
Pourquoi cette documentation est importante pour la direction, la page Responsabilité de la direction en cas de failles de sécurité informatique l'explique. Il s'agit d'une information générale et non d'un conseil juridique.
Ce que vous ne devriez pas croire
Les dirigeants entendent souvent trois affirmations en ce moment, et toutes trois sont fausses :
- « Nous avons mis à jour WordPress, donc nous sommes en sécurité. » La faille se trouve dans PHP, non dans le CMS. Une mise à jour du CMS ne la corrige pas.
- « Nous sommes trop petits, personne ne nous attaque. » Les attaques sont automatisées. On cherche des serveurs vulnérables, non des noms connus.
- « La mise à jour est installée, le sujet est donc clos. » Un correctif ne supprime pas un logiciel malveillant introduit auparavant et ne prouve pas que rien ne s'est produit.
Comment PHP SOS aide-t-il concrètement ?
- Vue d'ensemble pour la direction : nous établissons un court aperçu de vos systèmes PHP avec statut et recommandation pour chacun.
- Mise en œuvre : nous corrigeons, redémarrons ou appliquons des mesures transitoires là où une mise à jour n'est pas encore possible.
- Vérification : nous sauvegardons les journaux et recherchons des traces d'une attaque.
- Preuve : vous recevez une documentation utilisable en interne et vis-à-vis de tiers.
Le déroulement est décrit dans l'assistance immédiate PHP2Shell.
Conclusion
PHP2Shell est une faille technique assortie d'une tâche de management. La technique, ce sont des spécialistes qui s'en chargent. La direction veille à ce que quelqu'un soit responsable, à ce que les cinq questions reçoivent une réponse et à ce que les décisions soient prises en connaissance de cause et documentées. Cela tient dans une matinée, si l'on commence aujourd'hui.
Questions fréquentes
La direction doit-elle s'occuper elle-même de PHP2Shell ?
Pas de la mise en œuvre technique, mais du pilotage, oui. La direction devrait s'assurer que les responsabilités sont claires, que la recommandation du BSI est appliquée et que des décisions comme une mise hors ligne temporaire sont prises en connaissance de cause et documentées.
Comment expliquer la faille en une phrase ?
Dans PHP, le logiciel sur lequel tournent la plupart des sites web et boutiques, il existe deux erreurs critiques par lesquelles des inconnus peuvent lancer des programmes sur le serveur sans mot de passe ; une mise à jour est disponible et doit être installée.
Combien coûte le fait de ne rien faire ?
Cela ne se chiffre pas de façon générale. Les conséquences possibles d'une attaque réussie sont des interruptions d'activité, des fuites de données, des obligations de notification, des efforts de nettoyage et d'analyse forensique ainsi qu'une perte de confiance des clients. Une mise à jour avec vérification est en règle générale nettement moins coûteuse.
Suffit-il que l'hébergeur s'en occupe ?
En hébergement mutualisé, c'est en règle générale l'hébergeur qui installe la mise à jour. Faites-vous le confirmer par écrit, y compris le redémarrage des processus PHP. La confirmation ne dit pas si quelque chose s'est produit avant la mise à jour ; pour cela, une vérification du site est nécessaire.