Depuis le préavis du 20 octobre, PHP2Shell figure parmi les vérifications de nombreux responsables informatiques. Le 21 octobre 2026, le projet PHP a publié des mises à jour contre deux vulnérabilités critiques. Pour DAXS, il s’agissait d’interpréter les alertes, de rechercher les services potentiellement concernés et de hiérarchiser les mesures selon leur exposition réelle. Ce qui compte est ce qui fonctionne effectivement sur chaque système, au-delà de la clôture d’une tâche de mise à jour.
Ce qui a été publié
Les vulnérabilités CVE-2026-109618 et CVE-2026-109619 peuvent permettre l’exécution de code sans authentification préalable. Le préavis leur attribue à toutes deux une note CVSS v4.0 de 9,2. Cette classification critique justifie une évaluation rapide ; elle ne démontre pas quelle installation précise d’un client aurait subi une attaque réussie.
Le projet PHP indique les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les paquets entretenus par les distributions peuvent bénéficier de correctifs rétroportés. Un numéro de version de base inférieur ne prouve donc, à lui seul, ni l’absence de protection ni l’application d’une correction. Le paquet exact, l’avis de l’éditeur et l’environnement d’exécution réellement utilisé sont déterminants.
Les avis concernent plusieurs intégrations aux serveurs web. PHP souligne le risque avec Apache et mod_php ; cela ne constitue pas une déclaration générale d’innocuité pour PHP-FPM ou d’autres modes d’exploitation. Composants, extensions et paramètres sont examinés pour chaque environnement. Le nom d’un produit dans un inventaire ne suffit pas.
Notre première question : où PHP fonctionne-t-il réellement ?
Nous avons rapproché les alertes disponibles des connaissances existantes sur les systèmes. L’inventaire inclut sites publics, interfaces d’administration, applications supplémentaires et services intégrant PHP. Les priorités dépendent de l’accessibilité externe, de la fonction du service et du responsable de sa mise à jour. Les éléments incertains deviennent des tâches de vérification concrètes.
Nous distinguons le paquet installé du service web actif. Plusieurs versions de PHP peuvent coexister. La mise à jour réussie du programme en ligne de commande ne démontre pas quel environnement d’exécution utilise un processus précis du serveur web. Après une modification, les services concernés et leurs paramètres effectifs doivent donc être contrôlés de manière traçable. Une page de diagnostic publiquement accessible n’est pas une solution permanente.
L’inventaire doit aussi comprendre les systèmes moins visibles. L’administration web peut être une fonction secondaire d’un appareil tout en créant une surface d’attaque supplémentaire. Déterminer si elle utilise PHP et nécessite un correctif reste une question technique. La seule présence d’une interface web ne démontre pas qu’un appareil est concerné.
Mettre à jour, vérifier l’effet réel et consigner les points ouverts
Le processus commence par l’inventaire et l’évaluation. Les mises à jour disponibles sont ensuite appliquées selon les priorités. Le contrôle porte sur le paquet, les redémarrages nécessaires, la configuration effective et les fonctions applicatives requises. Les responsables doivent savoir quels services sont vérifiés et où manquent encore une réponse de l’éditeur, un paquet adapté ou une réception technique.
Si un service spécialisé ne peut pas être actualisé immédiatement, nous examinons d’abord les accès publics directs réellement nécessaires. Un accès Internet superflu peut être supprimé temporairement. Un usage interne légitime peut éventuellement continuer par des accès convenablement isolés. Cette mesure délibérément limitée nécessite de vérifier ses effets et ses conséquences ; elle ne supprime pas automatiquement les vulnérabilités du logiciel sous-jacent.
Une tâche n’est donc pas terminée au démarrage d’une mise à jour. Elle exige une conclusion traçable ou un point ouvert attribué à un responsable. Lorsqu’un accès est restreint, l’accessibilité restante est également contrôlée. Après installation d’un correctif, le service effectivement utilisé est vérifié. Ces deux aspects appartiennent à la documentation d’exploitation tenue à jour.
La vérification comprend aussi le canal de distribution du logiciel. Pour une installation entretenue par le système d’exploitation, l’avis de la distribution est comparé au paquet installé. Pour un environnement d’exécution intégré, les informations de l’éditeur du produit font référence. Cela évite de mal interpréter un simple numéro de version. Si les preuves sont insuffisantes, le point reste ouvert avec une prochaine étape définie. Un statut vert sans fondement vérifiable serait trompeur.
Le rôle des WAF, proxys, pare-feu et réseaux séparés
WAF, proxys inverses, pare-feu et VLAN font déjà partie des outils utilisés pour limiter les accès et les flux. Un pare-feu contrôle les connexions autorisées, un proxy regroupe des accès web définis et les réseaux séparés contribuent à circonscrire les communications permises. Ces fonctions sont utiles, mais elles ne corrigent pas toutes les vulnérabilités d’un processus PHP.
En particulier, PHP2Shell ne doit pas être présenté comme entièrement résolu par un WAF placé en amont ou dans l’application. Le projet PHP désigne la mise à jour comme solution complète ; les restrictions temporaires ne couvrent que certains chemins d’attaque. Nous examinons donc ces couches avec l’état des correctifs et vérifions si un autre chemin pourrait contourner la restriction prévue.
Des essais isolés et l’IA au service du jugement technique
Nous avons également utilisé nos propres environnements de test isolés pour l’évaluation technique. Claude et OpenAI Codex ont aidé à la recherche et à la préparation de ces environnements. Le jugement professionnel et des sources techniques fiables ont été décisifs. Une réponse plausible de l’IA ne remplace ni la preuve de la version installée ni la vérification d’un paramètre effectif.
L’observation reste nécessaire après la mise à jour. Erreurs inhabituelles, processus inattendus ou connexions anormales sont évalués par rapport au comportement normal du système. Une correction installée ne prouve pas rétrospectivement que rien ne s’est produit auparavant. Inversement, une seule anomalie dans un journal ne prouve pas une attaque réussie.
Replacer les communications publiques dans leur contexte
La communication de l’Université de Vienne sur les restrictions de services informatiques centraux montre l’impact possible des mesures préventives. Son avis actualisé indique que la plupart des services sont à nouveau disponibles. Ces informations éclairent la situation, sans décrire l’état d’une autre organisation ou d’un environnement précis suivi par DAXS.
Les avis des éditeurs doivent également correspondre au service concerné. Un fournisseur peut distinguer ses produits d’un portail hébergé qu’il exploite. Une déclaration relative à un produit ne s’étend pas à toutes les applications tierces. Pour OPNsense, FreePBX, Sophos ou un gateway particulier, il faut donc examiner version exacte, composants intégrés, recommandations de l’éditeur et conditions d’accès réelles.
La préparation rend la réponse vérifiable
Un inventaire utile, des responsabilités claires et des procédures de mise à jour préparées facilitent la réaction aux alertes critiques. Nous ne publions ni pourcentage de correction sans preuve ni déclaration générale d’innocuité pour tous les systèmes. Les vérifications individuelles traçables et le traitement continu des cas ouverts sont décisifs. Vendredi, nous verrons comment l’IA peut aider à inclure les appareils facilement oubliés dans ces contrôles.
