PHP2Shell : que faire après l’alerte PHP d’octobre 2026 ?
Exped Global Solutions ·
Deux failles critiques, des tentatives d’exploitation et une question concrète : qui protège votre site ? Les faits vérifiés et les décisions utiles pour les entreprises en Algérie.
Votre site fonctionne. Les formulaires arrivent, les clients consultent vos offres et les commandes continuent. Puis un message apparaît : une faille critique touche PHP. Le réflexe consiste souvent à demander si le site est encore accessible. La question utile est plus précise : savons-nous quelle version tourne réellement, qui la maintient et comment vérifier sa sécurité ?
Pour une PME, un hôtel ou une entreprise industrielle en Algérie, cette distinction change la discussion avec le prestataire. Une page qui s’affiche ne constitue pas une preuve de sécurité.
Ce qui est confirmé au 25 octobre 2026
Le projet PHP a publié le 21 octobre des correctifs pour CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Ces failles du moteur peuvent permettre une exécution de code à distance sans authentification. Elles concernent les installations vulnérables qui traitent des requêtes web ; PHP souligne un risque particulièrement élevé avec Apache et mod_php. Les versions correctives annoncées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Consultez l’avis officiel PHP du 21 octobre et la dernière version disponible dans votre branche avant toute intervention.
Dans sa mise à jour du 22 octobre, Cisco Talos décrit des tentatives d’exploitation observées après la divulgation, avec surtout des scans et des tentatives de livraison de charges malveillantes. Cela documente une activité hostile. Cela ne permet pas d’affirmer que tous les sites PHP ont été piratés, ni qu’un site particulier a été compromis.
Pourquoi mettre WordPress à jour ne suffit pas toujours
Imaginez un commerce : changer la vitrine ne répare pas la serrure du bâtiment. Le CMS et ses extensions constituent une couche ; le moteur PHP qui les exécute en constitue une autre. Un site développé sur mesure peut aussi dépendre de ce moteur. Il faut donc poser une question explicite sur l’environnement serveur, en plus de vérifier les mises à jour de l’application.
Sur un hébergement mutualisé, le titulaire du compte peut parfois choisir une branche PHP, tandis que l’hébergeur reste responsable des paquets et du redémarrage des processus. Faites préciser la répartition des responsabilités au lieu de supposer qu’une option affichée dans le panneau règle toute la chaîne.
Le message à envoyer à votre hébergeur
Voici notre proposition de demande opérationnelle :
Notre site utilise-t-il une version de PHP concernée par PHP2Shell ? Merci de confirmer la version ou le paquet corrigé effectivement chargé par le serveur web, la date d’application et la prise en compte du correctif par les processus en service. Merci aussi de préciser la vérification réalisée sur nos applications et le traitement de l’avis PHP complémentaire du 23 octobre.
Demandez une réponse écrite et conservez-la avec le dossier technique du site. Une confirmation portant uniquement sur la version utilisée en ligne de commande ne décrit pas nécessairement celle utilisée pour servir vos pages.
Un point supplémentaire : l’avis du 23 octobre
Die Centre canadien pour la cybersécurité, dans son actualisation du 23 octobre, signale aussi CVE-2026-115560 : un autre scénario, soumis à une combinaison inhabituelle de configuration et de comportement applicatif, qui n’est pas corrigé par les mises à jour du 21 octobre. L’avis recommande provisoirement de désactiver le suivi de progression des téléversements de session. Cette décision doit être appliquée par l’équipe responsable selon l’avis PHP actuel, avec vérification des fonctions concernées.
Ce même centre recommande de prioriser les systèmes exposés sur Internet, de surveiller les journaux et d’examiner les processus, fichiers, comptes et connexions inattendus associés aux services web. En cas de soupçon de compromission, une mise à jour seule ne suffit pas à établir que le système est sain.
Transformer l’alerte en organisation durable
Notre conseil de méthode : donnez à chaque site un responsable nommé, un inventaire technique accessible et un historique de maintenance. Décidez à l’avance qui peut interrompre un service, qui contacte l’hébergeur et qui informe les équipes métier. Testez une restauration de sauvegarde avant le jour où elle devient urgente.
Pour une activité qui dépend des réservations, des commandes ou des demandes de devis, cette préparation relève de la continuité de service. Elle mérite une place dans le budget du projet, au même titre que le design et les contenus.
Vous souhaitez clarifier l’architecture et la maintenance de vos outils ? Présentez votre contexte à Exped. Pour suivre nos prochains repères sur le numérique en entreprise, vous pouvez également vous inscrire au journal en bas de cette page.
Article de veille vérifié le 25 octobre 2026. Les avis de sécurité évoluent : consultez les sources officielles au moment d’agir. Les exemples métier et la méthode d’organisation sont des propositions éditoriales d’Exped.