PHP2Shell : versions corrigées et vérifications pour votre hébergeur

Que s’est-il passé avec PHP2Shell ?

Le 21 octobre 2026, PHP a publié des mises à jour de sécurité pour CVE-2026-109618 et CVE-2026-109619. Dans certaines conditions, ces deux failles peuvent permettre une exécution de code à distance sans authentification. Chacune obtient un score CVSS v4.0 de 9,2. Ce score mesure la gravité technique, pas la probabilité qu’une entreprise donnée ait déjà été attaquée.

La PHP Foundation décrit des retards dans la correction du problème de mémoire et des difficultés de divulgation coordonnée. Des informations diffusées prématurément ont conduit à avancer la publication d’un jour. Pour les exploitants, la priorité est de savoir quels systèmes en fonctionnement ont effectivement reçu le correctif. [1] [3] [4]

Quelles versions de PHP contiennent les correctifs ?

Le tableau indique les premières versions corrigées publiées par le projet PHP pour les deux failles du 21 octobre. Il ne permet pas d’écarter CVE-2026-115560, la faille supplémentaire annoncée le 23 octobre. Consultez aussi les avis ultérieurs de l’éditeur.

Les distributions Linux et les offres d’hébergement géré peuvent intégrer un correctif rétroporté tout en conservant un ancien numéro de version PHP. Il faut alors vérifier la version complète du paquet et le bulletin de sécurité du fournisseur. PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour régulières du projet PHP ; les rétroportages des fournisseurs et les correctifs minimaux disponibles sous forme de code source doivent être vérifiés séparément. Ils ne remplacent pas une migration planifiée vers une branche prise en charge. [1] [4]

Faites défiler le tableau horizontalement.

Contrôler aussi l’alerte du 23 octobre sur les sessions

PHP recommande temporairement session.upload_progress.enabled=0 jusqu’à la prochaine version corrective régulière. Cet avis concerne CVE-2026-115560 et une combinaison inhabituelle de configuration et de code applicatif. Il doit être traité séparément des deux failles déjà corrigées.

La condition décrite est précise : session.serialize_handler est initialement défini sur php_binary ou php_serialize. Pendant la requête, l’application le remplace par php avec ini_set(), avant d’appeler session_start(), tandis que le suivi de progression des téléversements en session reste activé. Selon PHP, les applications qui ne modifient jamais ce gestionnaire à l’exécution peuvent laisser cette fonctionnalité activée.

Demandez à l’administrateur de vérifier la configuration effective. Une désactivation préventive doit s’appliquer dans la configuration du serveur ou de PHP avant l’analyse des requêtes ; les processus concernés doivent être redémarrés. Un ini_set() exécuté ensuite dans le code applicatif ne le remplace pas. Si ce réglage est déjà appliqué, conservez-le. L’avis ne donne pas encore de date ni de nouveaux numéros de version pour le correctif régulier. État vérifié le 24 octobre 2026. [1] [2]

Pourquoi mettre WordPress à jour ne suffit pas

Le CMS et l’environnement PHP qui l’exécute sont deux composants distincts. Une installation WordPress, Drupal ou Joomla à jour ne prouve donc pas que le serveur web utilise un PHP corrigé. Le chargement normal d’un site ne permet pas non plus de confirmer l’application du correctif.

Recensez les boutiques, portails clients, sous-domaines et anciennes installations en plus du site principal. Pour chaque système, identifiez l’environnement qui exécute réellement les requêtes web. PHP-FPM n’est pas automatiquement épargné ; PHP cite également mod_php, CGI, FrankenPHP et LiteSpeed. La ligne de commande peut utiliser une autre installation PHP que le serveur web. Ne publiez pas de page phpinfo() librement accessible pour effectuer cette vérification. [1] [5]

Pour approfondir : pourquoi des vulnérabilités connues restent ouvertes malgré les correctifs

Ce que votre hébergeur doit confirmer

Une réponse générale comme « nos serveurs sont à jour » laisse des questions essentielles sans réponse. Demandez une confirmation propre à vos systèmes. Vous pouvez utiliser ce texte :

Merci de confirmer l’environnement PHP web et la version complète du paquet utilisés pour notre site, l’application des correctifs pour CVE-2026-109618 et CVE-2026-109619, ainsi que le traitement de l’avis PHP du 23 octobre 2026 relatif à CVE-2026-115560. Veuillez préciser la date d’activation et fournir la référence du bulletin de l’éditeur ou de la distribution.

Faites défiler le tableau horizontalement.

Ce que prouvent les alertes WAF et les tentatives d’attaque

Un pare-feu applicatif web peut limiter certains chemins d’attaque. Il ne remplace ni la mise à jour de PHP ni la vérification de la configuration effective. Si la mise à jour ne peut pas être appliquée immédiatement, convenez de mesures restrictives ou d’une isolation temporaire avec l’administrateur responsable, en suivant les consignes complètes de l’éditeur.

AWS a documenté des tentatives dans sa télémétrie MadPot avant la divulgation publique. AWS précise aussi qu’on ignore si ces tentatives auraient réussi sur des systèmes réels. Un nombre de tentatives n’est donc pas un nombre d’entreprises compromises. À l’inverse, un tableau de bord sans alerte ne prouve pas qu’une instance est restée intacte. [1] [5] [6]

Quand peut-on clôturer les vérifications ?

Pour chaque système, consignez le responsable, le paquet actif, la référence du fournisseur, la date d’activation et le résultat du test fonctionnel. Distinguez la vérification du correctif de l’investigation d’incident : un système corrigé aujourd’hui ne renseigne pas sur ce qui s’est produit avant la mise à jour.

Si des modifications de fichiers, des processus inattendus ou des accès suspects évoquent une compromission, préservez les journaux disponibles et faites intervenir l’équipe responsable de la réponse aux incidents. Une évaluation de sécurité externe peut examiner les systèmes visibles et leurs anomalies ; sans preuves supplémentaires, elle ne peut pas confirmer définitivement l’état des paquets internes ni une éventuelle compromission.

• Systèmes PHP web concernés et responsables recensés.
• Correctifs des deux CVE initiales vérifiés sur l’instance en fonctionnement.
• Avis du 23 octobre sur les sessions contrôlé et documenté séparément.
• Fonctions essentielles à l’activité vérifiées après la modification.
• Prochaine action et échéance attribuées aux systèmes non résolus.
• Incidents suspects examinés séparément ; la mise à jour ne vaut pas preuve d’absence d’intrusion.