Ce mois d’octobre 2026 a connu une alerte majeure pour l’ensemble de l’écosystème web avec la vulnérabilité PHP2Shell.

Nous prenons ici le temps 

• d’analyser l’urgence et la portée de la menace, 
• de décrire les conditions nécessaires pour assurer une protection et une correction efficaces de vos applicatifs et site web, 
• de montrer l’intérêt d’une infogérance assurée par un spécialiste, comme le travail considérable et méthodique mené en urgence par les équipes Alfa-Safety.

C’est aussi l’occasion d’en tirer des enseignements et de collectivement œuvrer pour une meilleure sécurisation des plateformes exposées sur Internet.

Ce mois d’octobre 2026 a connu une alerte majeure pour l’ensemble de l’écosystème web avec la vulnérabilité PHP2Shell.

Nous prenons ici le temps 

• d’analyser l’urgence et la portée de la menace, 
• de décrire les conditions nécessaires pour assurer une protection et une correction efficaces de vos applicatifs et site web, 
• de montrer l’intérêt d’une infogérance assurée par un spécialiste, comme le travail considérable et méthodique mené en urgence par les équipes Alfa-Safety.

C’est aussi l’occasion d’en tirer des enseignements et de collectivement œuvrer pour une meilleure sécurisation des plateformes exposées sur Internet.

PHP2Shell : une faille d’une ampleur exceptionnelle

Une faille “zero day”

La faille PHP2Shell (CVE-2026-109618 et CVE-2026-109619) est une faille critique de type zero-day, exploitée avant la disponibilité générale d’un correctif . Elle permet à un attaquant de prendre le contrôle d’un serveur web à distance, sans aucune authentification. La faille se situe dans le moteur PHP lui-même : la requête malveillante est traitée avant que le code de l’application ne s’exécute, ce qui rend inopérante toute protection applicative.

Sa portée est très large. Toutes les versions de PHP depuis la 5.4 sont concernées, et des chercheurs ont démontré une exploitation réussie sur Magento 2.4.9 ainsi que sur dix autres applications PHP. Magento, Drupal, WordPress ou Symfony sont donc exposés, même lorsque leur propre code est irréprochable.

Le fait de toucher PHP, le langage de développement le plus répandu des applications web, rendait cette faille critique à l’échelle mondiale.

L’identification de la faille et les risques embarqués

Cette faille a été détectée dans le cadre de l’Initiative “Patch the planet” à laquelle participent des acteurs de l’IA dont OpenAI. L’idée est d’utiliser la puissance de l’IA pour identifier préventivement des failles avant qu’elles ne soient exploitées. Dans ce cas, on estime que cette faille était présente depuis plusieurs années.

Il faut savoir qu’au seul 3ème trimestre 2026, ont été détectées en 3 mois autant de failles que sur toute l’année 2025.

Inversement, le risque avec l’IA est qu’il devient très difficile de préserver le secret avant la diffusion des correctifs, et de fait, nous avons pu constater que certains acteurs avaient commencé à l’exploiter avant même la publication officielle.

Les actions préparatoires en amont de la publication des correctifs

La cellule de crise

Le contexte a été particulièrement tendu, comme nous l’avons dit, les premières attaques ont été observées avant même la publication des correctifs.

Dès le 20 octobre, veille de la publication attendue des correctifs, Alfa-Safety active une cellule de crise, composée de membres de son équipe sécurité et de l’équipe infogérance, afin de se préparer au maximum :

• Une équipe de traitement des opérations techniques est désignée, mobilisable à tout moment dès que les correctifs seront publiés, des rôles sont répartis
• Certains sont en charge de la communication avec les clients, et notamment de répondre au nombre croissant de demandes que nous recevons très rapidement.
• Un groupe assure la préparation et la validation des méthodes de déploiement
• Certains suivent en temps réel toutes les informations disponibles.
• Enfin, d’autres travaillent à vérifier l’inventaire des clients concernés et les combinaisons de versions OS/PHP dans lesquelles ils se trouvent.

Les actions préparatoires

Sans attendre les correctifs, nous avons engagé un certain nombre d’actions préparatoires 

• Mises en maintenance : Bon nombre de nos clients ont demandé la mise en maintenance de leur site/application. Notre vigilance s’est portée sur le fait de déployer des pages  de maintenance HTML et de ne pas laisser le moteur PHP actif et donc vulnérable.
• Mesures de mitigation : Des mesures temporaires de mitigation ont été diffusées permettant de réduire rapidement le risque d’exploitation et de limiter la période d’exposition, en attendant le déploiement du correctif officiel. Il a fallu les analyser, comprendre leur impact potentiel, et évaluer si elles ne risquaient pas de poser des perturbations fonctionnelles comme par exemple désactiver une fonctionnalité de PHP. Alfa-Safety a décidé d’appliquer une seule de ces mesures sur la configuration PHP de l’ensemble des serveurs, y compris les plus anciens (Ubuntu 18.04 et 20.04). 
• Validation de la chaîne de déploiement : Nous avions recensé plus de 1000 domaines à corriger en urgence. L’équipe a donc vérifié la chaîne de mise à jour, le bon fonctionnement du gestionnaire de paquets, et surtout l’écriture de scripts spécifiques à cette faille.

La diffusion et le déploiement des correctifs

De la diffusion au déploiement

• • A 15h50, PHP publie ses correctifs pour les versions encore maintenues uniquement (8.2 et supérieures). Toutefois, nous devons encore attendre que les correctifs soient disponibles dans les différentes versions d’Ubuntu, l’OS déployé par alfa-Safety. Vu le nombre de dépendances et de combinaisons entre PHP et Ubuntu, il faut attendre environ 1h30 pour que les paquets de nos distributions soient mis à disposition depuis la source référencée sur laquelle nous nous appuyons
  • Entre 17h et 17h30, les paquets pour nos distributions Ubuntu sont mis à disposition À partir de ce moment, nous pouvons commencer le déploiement
  • De 17h30 à 18h30, déploiement automatisé des correctifs sur 80% des serveurs, hors cas non standards.
  • Jusqu’à 21h, traitement des cas particuliers sur lesquels le déploiement automatisé n’avait pu être lancé ou s’était trouvé en échec, serveurs éteints, versions non standards ou obsolètes
• 21h fin officielle des opérations

L’automatisation d’un déploiement ultra rapide

Ainsi en moins d’1h30, des centaines de serveurs sont corrigés.
Ceci n’a été possible que par la rigueur du travail d’un infogérant et notamment grâce :

• aux mises à jour des serveurs, aux relances et à la planification effectuées en copil avec nos clients,
• à la tenue d’un inventaire précis et à jour qui permet de préparer le déploiement et de cibler les opérations par types de configuration,
• à l’utilisation efficace d’Ansible pour la gestion des configurations,
• à une méthode et un mécanisme automatique déjà en place pour patcher les serveurs chaque jour sur un créneau fixe.

De plus, dans ce cas particulier, compte tenu de la gravité de la faille et du très grand nombre de serveurs à patcher, il a fallu ajuster notre méthode de déploiement pour en accélérer l’exécution et parvenir à gérer une multitude de mises à jour en parallèle.
Nos équipes ont ainsi adapté un script spécifique qui a permis d’assurer une vitesse exceptionnelle de déploiement.

Les serveurs en version obsolète et les cas particuliers

PHP n’avait publié ses correctifs que pour les versions 8.2 et supérieures.

Grâce au travail d’Ondřej Surý, mainteneur des paquets PHP pour Ubuntu et Debian, nous avons toutefois pu appliquer les correctifs sur des versions de PHP obsolètes, dès lors que les serveurs fonctionnaient sous Ubuntu 22.04 ou supérieur.

Pour les serveurs sous des versions plus anciennes d’Ubuntu (18.04 et 20.04), pour lesquels aucun paquet corrigé n’était disponible, nos équipes ont construit et déployé leurs propres paquets PHP intégrant le correctif. Cette solution permet de sécuriser ces environnements à court terme, mais elle reste transitoire : elle ne remplace pas une montée de version complète, notamment d’Ubuntu, que nous avons engagée avec chaque client concerné, bien souvent dans des délais très courts.

Les leçons à retenir

Rappeler la responsabilité de l’équipe de développement ou de la TMA

Un infogérant comme Alfa-Safety peut appliquer un correctif en un temps très court (de l’ordre d’1h) à condition que l’application tourne sur une version de langage encore maintenue. 

Or le choix et la montée de version de PHP, de Node.js ou de tout autre langage sont intimement liés au code applicatif : ils relèvent de vos équipes de développement ou de votre TMA, seules à même de garantir la compatibilité de l’application.

Concrètement, plus vos applications suivent les versions maintenues, plus nous sommes en mesure de vous protéger rapidement. Si vous êtes concernés, les images Docker maintenues par vos développeurs ou votre TMA doivent être mises à jour par leurs soins.

Il faut se préparer à un niveau croissant de risque cyber et prévoir un budget adapté

Les outils d’intelligence artificielle accélèrent considérablement la découverte de vulnérabilités : OpenAI fait d’ailleurs partie des acteurs ayant participé à la divulgation de PHP2Shell. Ce type d’alerte va très probablement devenir plus fréquent et le délai entre divulgation et exploitation de plus en plus court.

Dans ce contexte, les acteurs de l’hébergement/infogérance comme Alfa-Safety, mais aussi les hyperscalers, seront amenés à durcir leurs politiques de mise à jour, en encadrant plus strictement l’exploitation de versions de langages et de systèmes non maintenues. Plus que jamais, il est indispensable de maintenir les versions logicielles et middlewares les plus à jour possible.

Enfin, il faudra se doter d’un budget sécurité plus conséquent : 

• montée de version plus fréquentes, 
• outils de gestions des identités et des secrets, 
• audit d’intrusion, 
• CDN en amont de l’infrastructure…

autant de postes qu’il faudra financer sur les mois et années à venir.

Un infogérant spécialisé vous accompagne dans le pilotage de ces évolutions

Alfa-Safety a toujours anticipé les évolutions et conseillé ses clients dans les montées de version, en proposant une roadmap de mise à jour et en alertant sur toutes les situations vulnérables. Nous assurons un patching quotidien automatisé des correctifs publiés sur les middleware que nous déployons. Nos méthodes de travail et l’outillage d’exploitation que nous développons nous permettent d’automatiser et standardiser bon nombre de montées de version. Chez Alfa-Safety, une montée de version PHP se fait techniquement en un clic.

Il est essentiel que nous puissions collaborer de manière proactive sur ces évolutions, afin de trouver les bons créneaux et le bon rythme pour mener ces évolutions en perturbant le moins possible vos applicatifs.

À noter dès aujourd’hui : PHP 8.2 arrive en fin de vie le 31 décembre 2026. Si vos applications utilisent cette version, il est temps de planifier leur montée de version avec vos équipes.

Alfa-Safety garantit la disponibilité 24/7, la performance et la sécurité de vos applications web critiques. Nous concevons et infogérons l’architecture Cloud et DevOps adaptée à vos besoins.