Installer un correctif PHP peut corriger une faille de sécurité. Cela ne permet pas aux administrateurs de savoir si des attaquants sont arrivés les premiers.
C’est le défi auquel sont confrontées les équipes de sécurité après les révélations liées à PHP2Shell, au cœur de l’alerte du « mois noir d’octobre ». Amazon a signalé des tentatives d’exploitation avant la divulgation publique, tandis qu’un avis PHP distinct a ajouté des contrôles de configuration, y compris pour les organisations qui avaient déjà installé les mises à jour d’urgence.
Les équipes de sécurité doivent désormais déterminer si des attaquants ont obtenu un accès avant l’application des correctifs, s’ils ont laissé des éléments derrière eux et si chaque application exposée utilise bien les correctifs.
- La fenêtre d’enquête commence avant l’application du correctif
- Un avis distinct maintient l’attention sur les contrôles de configuration
- Mettre à jour le CMS ne comble pas toutes les failles
- L’IA modifie la rentabilité des exploits
- Ce que les équipes de sécurité doivent établir avant de clore la réponse
La fenêtre d’enquête commence avant l’application du correctif
La perturbation initiale a notamment touché des sites web de gouvernements européens mis hors ligne par précaution. La question qui se pose ensuite est de savoir si des systèmes exposés ont été ciblés avant que leurs opérateurs ne sachent qu’ils devaient agir.
Amazon Threat Intelligence a signalé une tentative d’exploitation de PHP2Shell contre son infrastructure de honeypots MadPot le 17 oct., soit quatre jours avant la divulgation publique. D’autres tentatives ont suivi autour de la publication, mais Amazon a indiqué qu’il n’était pas certain qu’elles auraient réussi contre des systèmes réels.
Amazon a recommandé de mener l’enquête à partir du 17 oct. au moins, plutôt que de prendre la date de l’avis comme point de départ. Cette distinction est importante pour les organisations dont les vérifications initiales ne couvraient que la période postérieure au début de l’application des correctifs.
Les éléments disponibles doivent également être examinés avec prudence. Dans une correction du 25 oct., l’Unit 42 de Palo Alto Networks a rétracté son attribution initiale d’une attaque contre une agence gouvernementale européenne à PHP2Shell. Les chercheurs ont observé une compromission impliquant une application PHP vulnérable, mais n’ont pas pu confirmer que ces CVE précises avaient fourni l’accès initial.
La correction ne réduit pas la nécessité d’appliquer les correctifs. Elle signifie toutefois que l’incident rapporté ne permet pas d’établir une exploitation réussie de PHP2Shell.
Un avis distinct maintient l’attention sur les contrôles de configuration
Les failles d’origine, CVE-2026-109618 et CVE-2026-109619, ont été corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 oct. Les éditeurs de distributions et de versions bénéficiant d’un support à long terme peuvent fournir des correctifs rétroportés ; les administrateurs doivent donc vérifier l’état du paquet fourni par leur éditeur plutôt que de se fier uniquement à une comparaison avec la version amont.
Le 23 oct., le projet PHP a publié un avis informatif concernant un problème distinct, CVE-2026-115560, lié à la progression des téléversements de session. Il nécessite une combinaison inhabituelle de configuration et de comportement applicatif, et PHP a indiqué qu’il le traiterait dans le cycle normal de publication.
Plus précisément, une application doit configurer session.serialize_handler sur php_binary ou php_serialize, puis le basculer sur php avec ini_set() avant d’appeler session_start(). La progression des téléversements de session doit également rester activée.
PHP recommande de définir session.upload_progress.enabled=0 jusqu’à la prochaine version corrective normale. Cela désactive le suivi natif par PHP de la progression des téléversements de session ; les administrateurs doivent donc vérifier si leurs applications en dépendent. Pour ce problème distinct, PHP indique que les applications qui ne modifient jamais le gestionnaire de sérialisation à l’exécution peuvent conserver cette fonctionnalité activée. Elles doivent néanmoins installer les mises à jour corrigeant les vulnérabilités PHP2Shell d’origine.
Les administrateurs qui appliquent cette mesure d’atténuation doivent utiliser une configuration prenant effet avant l’analyse des requêtes, comme php.ini, le pool PHP-FPM ou la configuration du serveur Apache. PHP déconseille de s’appuyer sur ini_set() au niveau de l’application ou sur les fichiers .user.ini de PHP-FPM pour cette modification.
Les recommandations de déploiement de Red Hat préconisent également de redémarrer chaque worker concerné ; un rechargement ne suffit pas. Dans les déploiements conteneurisés, remplacez le conteneur ou le pod en cours d’exécution. Vérifiez que l’application qui traite les requêtes web utilise le paramètre mis à jour, plutôt que de vous en remettre uniquement à la configuration PHP de la ligne de commande.
La désactivation de la progression des téléversements de session traite le problème conditionnel distinct, mais ne remplace pas les mises à jour PHP2Shell d’origine. L’avis ultérieur ne signifie pas que ces mises à jour n’ont pas corrigé les vulnérabilités initiales.
Mettre à jour le CMS ne comble pas toutes les failles
Le composant vulnérable se trouve sous l’application du site web. Des chercheurs de Wiz ont démontré une exécution de code à distance sans authentification contre des déploiements WordPress, Drupal et Joomla, mais ont précisé que les faiblesses sous-jacentes se trouvaient dans PHP lui-même.
Pour les organisations habituées à répondre à l’exploitation de plugins WordPress, cela change la tâche de vérification. Mettre à jour un plugin ou un système de gestion de contenu ne suffit pas à démontrer que son environnement d’exécution PHP a reçu un correctif.
Joseph Perry, chercheur en cybersécurité et responsable des services avancés chez Arcova, a décrit la réponse comme une « fenêtre critique de mise à jour et de surveillance » pour les sites de commerce électronique et autres applications web pilotées par API.
« Pour toute personne qui tient un blog ou un site web, c’est une bonne raison de réduire la complexité, de tout mettre à jour et de rester au fait des bonnes pratiques », a déclaré Perry.
Une mesure pratique consiste à demander aux responsables de l’hébergement et des applications quel environnement d’exécution sert chaque site exposé, quel paquet fourni par l’éditeur corrige les failles et si les workers et conteneurs en service ont effectivement récupéré la mise à jour.
La recommandation de la National Security Agency recommande également de renforcer la journalisation et de remplacer les services PHP en fin de vie qui ne peuvent pas recevoir de correctifs compatibles. Lorsqu’une mise à jour immédiate n’est pas possible, elle recommande de mettre le système hors ligne jusqu’à ce qu’il puisse être entièrement protégé. Pour les administrateurs, cela fait de l’identification des systèmes non pris en charge un élément de la réponse — et pas seulement de la confirmation des mises à jour sur les déploiements pris en charge.
Les mesures de contrôle temporaires doivent elles aussi être examinées avec attention. Les recommandations d’AWS en matière d’atténuation décrivent les règles de pare-feu applicatif comme une protection complémentaire et soulignent que l’application des correctifs est la seule solution complète. Une requête bloquée ne doit pas servir de preuve pour clôturer un ticket de remédiation.
Cloudflare a signalé que des attaquants avaient modifié leurs charges utiles pour tenter de contourner ses protections, tandis que ses analystes continuaient de mettre à jour les règles de détection. Cette activité donne aux défenseurs une raison supplémentaire de revoir les contrôles temporaires tout au long de la remédiation, plutôt que de considérer leur déploiement initial comme la fin du travail.
L’IA modifie la rentabilité des exploits
La préoccupation plus générale de Perry concerne l’économie du développement des exploits.
« C’est aussi un cas intéressant où l’IA n’a pas tant rendu l’exploit possible que pratique », a-t-il déclaré. « Ce qui complique le développement d’un exploit de ce type, c’est la nécessité d’un débogage constant et exhaustif, d’une plateforme à l’autre et d’une version à l’autre. »
Les conclusions de Wiz vont dans le même sens. Les chercheurs ont décrit des tests et des adaptations répétés sur différentes versions de PHP, configurations et organisations de la mémoire, et ont indiqué que l’IA réduisait l’effort spécialisé nécessaire.
« Se protéger contre l’IA ne consiste pas à se prémunir contre des exploits futuristes qu’aucun humain ne pourrait imaginer. Il s’agit de se protéger contre le type d’exploits qu’aucun humain ne prendrait la peine d’utiliser », a déclaré Perry.
Cela ne permet pas d’établir que toutes les attaques observées ont utilisé l’IA. Mais cela remet en cause l’idée que les failles complexes de corruption mémoire resteront trop coûteuses à exploiter contre un grand nombre de cibles.
« Cela signifie que nous devons moins nous concentrer sur ce que l’IA rend possible et beaucoup, beaucoup plus sur ce qu’elle rend pratique », a déclaré Perry.
Le problème potentiel en aval est bien connu. Un article précédent consacré à l’opération de compromission de sites web de WP-SHELLSTORM a montré comment des attaquants avaient utilisé des vulnérabilités connues pour établir un accès persistant. Il s’agissait d’une campagne distincte, mais elle illustre pourquoi la remédiation doit prendre en compte ce qu’un attaquant pourrait laisser derrière lui.
Ce que les équipes de sécurité doivent établir avant de clore la réponse
Le résultat le plus utile après le mois noir d’octobre est une réponse documentée à trois questions : quels systèmes étaient exposés, quand leur protection a-t-elle pris effet et quels éléments permettent d’avoir confiance dans le fait qu’ils restent fiables ?
Les équipes de sécurité doivent relier chaque application accessible au public à son environnement d’exécution PHP réel et à un responsable clairement identifié. Pour les services hébergés, il faut obtenir une confirmation du fournisseur ; pour les conteneurs, il faut confirmer que les images mises à jour ont atteint les workloads en cours d’exécution. Une demande de changement clôturée constitue une preuve plus faible que la vérification du correctif déployé.
L’enquête doit être menée parallèlement à la remédiation. Examinez la télémétrie conservée du web, des applications et des terminaux à partir de la date de ciblage connue la plus ancienne au minimum, et remontez plus loin lorsque les éléments le justifient. Les processus inattendus lancés par des workers web, les modifications de fichiers non autorisées ou les connexions sortantes suspectes méritent une enquête, même si aucun de ces éléments ne prouve à lui seul une exploitation de PHP2Shell. L’absence de journaux doit être consignée comme une limite de la confiance accordée aux conclusions.
Lorsque les éléments indiquent une compromission, considérez l’application des correctifs comme une partie de la réponse à incident. Déterminez l’étendue de la compromission, éliminez la persistance et évaluez si les identifiants ou jetons accessibles doivent être remplacés avant de déclarer la récupération terminée.