En bref : savoir si vous devez mettre un site hors ligne à cause de la faille PHP tient à une question : PHP tourne-t-il sur ce serveur, preuve à l'appui, dans une version corrigée, et tous les processus ont-ils été redémarrés ? Si oui, aucune mise hors ligne n'est nécessaire. Si la mise à jour n'est pas possible immédiatement, le BSI (office fédéral allemand de la sécurité des technologies de l'information) recommande de retirer temporairement le serveur web du réseau. Attendre n'est défendable que si le système n'utilise pas PHP, n'est pas accessible publiquement ou si le fournisseur a confirmé le correctif par écrit.
La situation dans laquelle vous devez décider
PHP2Shell comprend deux failles dans PHP lui-même, CVE-2026-109618 et CVE-2026-109619, toutes deux évaluées CVSS v4.0 9,2. Elles permettent d'exécuter du code malveillant à distance sans authentification. Des versions corrigées sont disponibles depuis le 21/10/2026 : 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Pour PHP 8.1 et antérieur, il n'existe plus de mises à jour officielles.
Le BSI a émis le niveau d'alerte orange et conseille la mise à jour immédiate, à défaut la mise hors ligne temporaire. Selon des articles de presse, la ville de Mayence, des services du gouvernement du Land de Hesse et d'autres établissements publics ont retiré des sites du réseau par précaution ; la chancellerie de Hesse n'a signalé aucune attaque. Ce que les entreprises peuvent en déduire figure dans Des autorités retirent leurs sites du réseau.
Pour les responsables en entreprise, la question est plus pratique : que faisons-nous aujourd'hui de notre boutique, de notre portail, de notre site d'entreprise ?
Mettre le site hors ligne, corriger ou attendre : les trois options comparées
Le tableau suivant met les options côte à côte. Il ne remplace pas l'évaluation de votre cas particulier, mais rend la pesée visible.
| Critère | Corriger immédiatement | Couper temporairement | Attendre |
|---|---|---|---|
| Protection contre PHP2Shell | Élevée, si le correctif et le redémarrage sont prouvés | Élevée pendant la durée de la coupure | Aucune, tant que non corrigé |
| Interruption d'activité | Courte, pour la mise à jour et le redémarrage | De quelques heures à quelques jours | Aucune |
| Condition préalable | Version de PHP prise en charge, accès, fenêtre de maintenance | Décision de la direction, page de remplacement statique | Raison prouvée pour laquelle il n'y a pas de risque |
| Effort | Faible à moyen | Faible sur le plan technique, élevé sur le plan organisationnel | Faible, mais effort de vérification pour la preuve |
| Cas typique | Serveur avec PHP 8.2 à 8.5 | Ancien système sous PHP 8.1 ou antérieur, état incertain | Système sans PHP ou accessible uniquement en interne |
| Risque résiduel | Une intrusion antérieure reste possible | Une intrusion antérieure reste possible | Entièrement subsistant |
Une ligne mérite l'attention : ni le correctif ni la coupure ne clarifient si quelque chose s'est déjà produit auparavant. Selon des articles de presse, la première tentative d'attaque observée date du 17/10/2026, donc avant le correctif. Un regard sur d'éventuelles traces fait donc partie de chaque option.
En cinq questions vers la décision
Parcourez les questions dans l'ordre. La première réponse claire mène en général à la décision.
- PHP tourne-t-il sur le système, et est-il joignable depuis Internet ? Si non, le système n'est pas directement concerné par PHP2Shell. Documentez comment vous l'avez établi.
- L'état des correctifs est-il prouvé ? Prouvé signifie : version corrigée ou rétroportage avec numéros CVE dans le journal des modifications du paquet et redémarrage de tous les processus PHP. Un affichage de version dans le panneau ne suffit pas. La manière de le vérifier est décrite dans Vérifier correctement la version de PHP et l'état des correctifs.
- La mise à jour peut-elle être installée dans les prochaines heures ? Si oui : corriger, redémarrer, contrôler. D'ici là, des mesures transitoires peuvent aider.
- Est-ce impossible, par exemple à cause de PHP 8.1 ou d'un accès manquant ? Alors la mise hors ligne temporaire est, selon le BSI, la voie à suivre. Les mesures transitoires selon php.net réduisent le risque, mais ne protègent pas complètement ; les détails figurent dans Mesures immédiates si vous ne pouvez pas encore corriger.
- Y a-t-il des signes de compromission ? Alors la question n'est plus « corriger ou couper », mais « traiter un incident ». Couper, conserver les preuves, ne pas supprimer précipitamment.
Si vous coupez : coupez correctement
Une mise hors ligne doit supprimer la surface d'attaque, pas seulement cacher la page d'accueil. Une page de maintenance toujours générée par PHP ne remplit pas ce but. Mieux vaut une page HTML statique que le serveur web diffuse sans PHP, ou une redirection vers un autre serveur.
Pensez à tout ce qui dépend du même PHP : sous-pages, interfaces pour applications ou gestion commerciale, espaces d'administration, rappels de paiement. Parlez au préalable avec le prestataire de paiement et la logistique si une boutique est concernée. Et informez collaborateurs et clients en termes clairs : le site est hors ligne par précaution, le contact passe par téléphone et e-mail. C'est mieux que le silence, qui nourrit les spéculations.
La fin de la coupure est également importante. Fixez à quelle condition le site revient en ligne, par exemple « PHP dans une version corrigée, redémarrage contrôlé, premier contrôle des traces sans résultat ». Ainsi, un frein d'urgence devient une procédure ordonnée.
Couper n'est pas une défaite. Selon des articles de presse, plusieurs services publics ont fait exactement cela sans qu'il y ait eu d'attaque. Une mise hors ligne par précaution ne signifie pas automatiquement qu'un site a été piraté.
Quand vous n'avez pas besoin de prestataire
Toutes les décisions n'exigent pas une aide externe. Si votre site est chez un hébergeur qui confirme par écrit l'état des correctifs et le redémarrage, et qu'il n'y a pas d'anomalies, vous êtes bien placé avec une brève documentation. Il en va de même si votre propre informatique peut corriger elle-même un serveur avec une version de PHP prise en charge et maîtrise le contrôle.
Une aide vaut la peine si des systèmes tournent avec une ancienne version de PHP, si l'état est incertain, si plusieurs serveurs sont concernés ou s'il y a des signes d'intrusion.
Comment PHP SOS aide-t-il concrètement ?
- Nous clarifions avec vous en peu de temps quels systèmes sont concernés et quel état des correctifs est prouvé.
- Nous fournissons à la direction une base de décision sur une page : options, risques, voie recommandée.
- Nous mettons en œuvre la voie choisie, soit correctif avec redémarrage, mesures transitoires ou mise hors ligne propre avec page de remplacement statique, dans le cadre de notre aide immédiate PHP2Shell.
- Nous recherchons des traces depuis le 17/10/2026 et documentons le résultat.
Conclusion
Corriger est le cas normal, couper le bon frein d'urgence, attendre n'est défendable que preuve à l'appui. Celui qui répond honnêtement aux cinq questions et consigne la décision par écrit agit dans l'esprit de la recommandation du BSI et pourra montrer plus tard pourquoi.
Questions fréquentes
Dois-je mettre mon site hors ligne à cause de PHP2Shell ?
Pas si PHP tourne déjà dans une version corrigée et que tous les processus ont été redémarrés. Le BSI recommande la mise hors ligne temporaire au cas où une mise à jour immédiate n'est pas possible.
Qu'est-ce qui coûte le plus cher, une coupure : le chiffre d'affaires ou le risque ?
On ne peut y répondre qu'au cas par cas. Une indisponibilité de quelques heures est le plus souvent mieux planifiable qu'une intrusion dont personne ne connaît les conséquences ni la durée. Consignez la pesée par écrit, quelle que soit son issue.
Une page de maintenance peut-elle tourner sur le même serveur ?
Oui, si elle est servie comme fichier statique sans PHP. Si la page de maintenance est toujours générée par PHP, la surface d'attaque subsiste.
Attendre est-il jamais le bon choix ?
Oui, dans des cas clairement délimités : si aucun PHP ne tourne sur le système, s'il n'est pas joignable depuis Internet ou si le fournisseur a confirmé par écrit le correctif et le redémarrage. Attendre sans de tels justificatifs n'est pas une option, mais un risque.
Qui devrait prendre la décision ?
La personne qui porte le risque pour l'activité, en règle générale la direction ou le propriétaire. L'informatique fournit les faits. Qui décide devrait figurer à l'avance dans le plan d'urgence.