Vulnérabilités critiques de PHP : qui est concerné, ce qui pourrait arriver et comment corriger en toute sécurité

Illustration de TechiesJournal représentant l’idée de l’article. Les deux piles exécutent une application à jour. Seule la couche PHP de droite dispose du correctif, et elle seule bloque donc la requête.

Deux vulnérabilités critiques de PHP ont exposé des sites web et des applications à une possible exécution de code à distance et à la divulgation de données sensibles. Des chercheurs en sécurité ont démontré leur exploitation, et des attaques actives ont été observées. Voici ce que les organisations doivent comprendre avant de mettre à jour leurs systèmes.

Une application corrigée peut encore tourner sur un environnement d’exécution vulnérable

Imaginez que votre organisation exploite un site client construit sur WordPress. Ses extensions sont à jour, les contrôles d’accès sont activés et l’équipe de développement corrige régulièrement les faiblesses de sécurité de l’application. Le site pourrait pourtant rester exposé à une attaque qui contourne ces précautions.

Le problème ne se situe peut-être pas du tout dans WordPress. Il peut se trouver dans PHP, le logiciel qui exécute l’application et traite les requêtes web entrantes.

Le 21 octobre 2026, le projet PHP a annoncé des mises à jour de sécurité d’urgence pour deux vulnérabilités critiques. Elles montrent pourquoi la sécurité applicative doit aller au-delà du code de l’application. Ces vulnérabilités, désignées collectivement sous le nom de PHP2Shell, peuvent permettre une exécution de code à distance sans authentification (un attaquant sans identifiant de connexion peut exécuter du code sur le serveur depuis Internet) ou l’exposition d’informations sensibles issues de la mémoire du processus PHP.

Deux failles critiques se trouvent dans PHP lui-même

Les vulnérabilités sont référencées comme suit :

• CVE-2026-109618 : un problème de corruption de mémoire lié à la façon dont PHP gère les erreurs de mémoire insuffisante (out-of-memory).
• CVE-2026-109619 : un problème dans lequel l’état interne d’une requête précédente peut rester accessible après la libération de sa mémoire.

Les deux sont classées critiques, avec un score CVSS 4.0 de 9,2 sur 10 (CVSS est l’échelle standard de gravité des vulnérabilités) dans l’annonce préalable de l’équipe de sécurité de PHP.

En fonctionnement normal, PHP alloue de la mémoire pendant le traitement d’une requête et la libère lorsqu’elle n’est plus nécessaire. Ces vulnérabilités concernent des situations dans lesquelles PHP peut tenter d’utiliser des données internes qui n’ont pas été initialisées de manière sûre ou qui n’appartiennent plus à une mémoire valide. Dans certaines conditions, des requêtes web spécialement construites peuvent déclencher ces faiblesses.

Un attaquant qui parvient à les exploiter peut exécuter du code avec les privilèges du processus worker PHP, accéder à la mémoire sensible du processus ou perturber l’application. Ces vulnérabilités se trouvent dans PHP lui-même : une application peut donc être touchée même si son propre code source ne contient aucun défaut de sécurité correspondant.

Plusieurs équipes de recherche ont trouvé les failles, et les mainteneurs de PHP les ont corrigées

La découverte est le fruit de plusieurs travaux de recherche en sécurité, indépendants et collaboratifs. Wiz Research cite publiquement Sagi Tzadik, Shir Tamari, Nir Ohfeld et Tomer Schwartz parmi ses chercheurs. Sa chronologie de divulgation publiée indique que son équipe a découvert la première vulnérabilité le 19 août 2026, a vérifié l’exécution de code à distance contre Drupal et WordPress dans les jours suivants, puis a signalé ses résultats aux mainteneurs de PHP le 24 août.

Calif a identifié de manière indépendante une faille critique de PHP dans le cadre de l’initiative de sécurité Patch the Planet d’OpenAI, à l’aide de GPT-5.6 Sol. Le rapport de divulgation coordonnée d’OpenAI attribue également à Wiz la découverte et le signalement indépendants des deux vulnérabilités. La divulgation a aussi mobilisé des chercheurs et des fournisseurs de sécurité, dont Cloudflare et Quarkslab, et le site de recherche PHP2Shell crédite Amy Burnett, d’OpenAI, et Ryan A., de Calif. Ce sont les mainteneurs de PHP qui ont mené les correctifs de sécurité proprement dits et les publications.

Des outils d’IA ont joué un rôle documenté dans l’enquête. Wiz indique avoir utilisé Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol. Les éléments disponibles permettent de parler de recherche en sécurité assistée par l’IA, et non de suggérer qu’un système d’IA autonome aurait découvert, validé et corrigé seul toutes les vulnérabilités.

La chronologie montre aussi pourquoi la divulgation coordonnée est importante. Les chercheurs avaient besoin de temps pour travailler avec les mainteneurs et les fournisseurs de sécurité avant de publier des détails techniques que des attaquants pourraient exploiter.

Les systèmes concernés exécutent un environnement d’exécution PHP non corrigé

PHP est utilisé par une part importante du Web. Parmi les logiciels courants fondés sur PHP figurent WordPress, Drupal, Joomla, Moodle, MediaWiki, Nextcloud et les applications construites avec Laravel ou Symfony. Cela ne signifie pas que chaque installation de ces produits est vulnérable. La vraie question est de savoir si le système déployé utilise un environnement d’exécution PHP concerné et si un correctif de sécurité applicable a été installé.

Wiz Research a démontré l’exécution de code à distance dans des environnements contrôlés exécutant WordPress, Drupal et Joomla. Ces démonstrations établissent une exploitabilité crédible dans des déploiements représentatifs, mais ne prouvent pas que les organisations à l’origine de ces produits ont été compromises.

L’annonce de sécurité de PHP cite comme environnements de service web concernés Apache mod_php (PHP exécuté à l’intérieur du serveur web Apache), PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. L’équipe PHP estime que le risque est le plus élevé pour mod_php, car le chemin d’attaque peut être déclenché avant l’exécution du moindre code applicatif. Les vulnérabilités peuvent aussi toucher des applications métier sur mesure, des systèmes hébergés dans le cloud, des images de conteneurs et des produits qui embarquent PHP en interne.

Versions de PHP corrigées

La première version amont corrigée de PHP pour chaque branche

Branche PHP	Première version amont corrigée
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35
PHP 8.1 et versions antérieures	Pas de version de sécurité amont régulière : vérifiez les rétroportages de votre fournisseur ou migrez

Le tableau indique la première version corrigée de chaque branche, telle que donnée dans l’annonce de PHP et dans l’alerte du Centre canadien pour la cybersécurité. Les versions antérieures contiennent aussi du code concerné. Selon Wiz, toutes les versions de PHP publiées au cours de la dernière décennie sont touchées par au moins l’une des failles, et Cloudflare indique que le problème concerne les serveurs web exécutant PHP 5.4 ou une version ultérieure.

Certaines distributions Linux et certains fournisseurs de support à long terme peuvent rétroporter (backport) les correctifs nécessaires sans modifier le numéro de version amont visible de PHP. Les administrateurs doivent donc confirmer l’état des correctifs auprès de leur fournisseur de logiciels plutôt que de se fier entièrement à php -v. Pour PHP 7.4, 8.0 et 8.1, l’équipe de sécurité de PHP a aussi fourni des rétroportages minimaux du code source pour les personnes qui compilent depuis les sources ou qui n’ont pas accès à un fournisseur de support à long terme. Selon l’annonce de PHP, PHP 8.2 atteint sa fin de vie amont le 31 décembre 2026 : les organisations qui mettent à jour cette branche doivent donc aussi prévoir une migration vers une version prise en charge.

Des attaquants sondaient PHP2Shell avant la publication des correctifs

Des tentatives actives sont documentées, y compris une activité antérieure à la divulgation publique des vulnérabilités. Amazon Threat Intelligence a indiqué avoir détecté une tentative d’exploitation de PHP2Shell contre son infrastructure de pots de miel (honeypots) MadPot le 17 octobre 2026, quatre jours avant la divulgation publique. Le 21 octobre, AWS a observé d’autres tentatives, avec des charges utiles et des infrastructures différentes, et a déclaré que PHP2Shell était largement exploité en conditions réelles. AWS a aussi précisé que l’analyse technique se poursuivait et qu’on ignorait si l’une ou l’autre de ces tentatives aurait réussi contre des systèmes réels.

Cloudflare a également signalé du trafic d’attaque visant ses clients pendant la période de divulgation. L’entreprise a décrit comment les attaquants modifiaient leurs charges utiles pour tenter de contourner les protections qu’elle venait de déployer. Ces constats sont importants, car ils montrent que la menace ne se limite pas à une preuve de concept de laboratoire.

Les rapports divergent sur la chronologie. L’alerte du Centre canadien pour la cybersécurité du 21 octobre indiquait qu’aucune exploitation active n’avait été identifiée à ce moment-là, mais que la situation pouvait évoluer rapidement, tandis qu’AWS et Cloudflare signalaient du trafic d’attaque. Il reste une différence entre détecter une tentative d’exploitation et confirmer que les systèmes de production d’une organisation ont été compromis. Au moment de cet examen des sources, les rapports publics examinés n’établissaient pas de liste vérifiée d’organisations nommément identifiées et compromises avec succès par ces vulnérabilités. La conclusion appropriée est que des attaques actives ont été observées, tandis que le nombre et l’identité des organisations effectivement compromises restent incertains. Les organisations ne doivent pas considérer l’absence de liste publiée de victimes comme la preuve que leurs systèmes sont sûrs.

Une exploitation réussie pourrait aller bien au-delà du serveur web

Les conséquences dépendent de la configuration vulnérable, du chemin d’attaque et des privilèges dont dispose le processus PHP. Une exploitation réussie peut avoir plusieurs conséquences.

Exécution de code non autorisée. Un attaquant peut exécuter des commandes sous le compte qui fait tourner PHP. Selon les permissions de ce compte, cela pourrait permettre de modifier les fichiers du site, d’installer du code malveillant ou d’accéder à des systèmes connectés.

Divulgation de mémoire sensible. La mémoire du processus PHP peut contenir des jetons d’authentification, des mots de passe, des clés d’API ou des informations provenant d’autres requêtes. Certains chemins d’attaque peuvent exposer la mémoire sans passer d’abord par une exécution de code à distance générale.

Perturbation du site. Une corruption de mémoire ou un épuisement délibéré peut faire tomber des workers, interrompre le traitement ou réduire la disponibilité du service.

Exposition de données et compromission plus étendue. Si un attaquant obtient l’accès à des identifiants de base de données, à des secrets applicatifs ou à des intégrations privilégiées, les conséquences peuvent dépasser le serveur web d’origine.

Ce sont des conséquences possibles, et non la preuve que chaque installation concernée les a subies. Les dégâts réels dépendent de la configuration, des permissions, de l’accès réseau et d’une exploitation réussie.

La bonne source de correctif dépend de la façon dont PHP a été installé

Pour les installations de PHP gérées directement, les versions officielles et les informations d’installation sont disponibles sur la page de téléchargement de PHP, dans le journal des modifications de PHP 8 et, pour Windows, sur windows.php.net. Sur les serveurs Linux, les administrateurs doivent normalement obtenir les mises à jour de sécurité auprès de la distribution de leur système d’exploitation ou du fournisseur de paquets PHP de confiance qui maintient déjà l’installation.

Pour les systèmes conteneurisés, les équipes doivent choisir une image de base officielle ou prise en charge par le fournisseur et mise à jour, reconstruire l’image de l’application et déployer l’environnement d’exécution corrigé. Pour l’hébergement géré, l’hébergement mutualisé ou les environnements SaaS, c’est parfois le fournisseur qui contrôle la mise à jour : les clients doivent donc obtenir la confirmation que l’environnement d’exécution PHP concerné a été corrigé.

Ne téléchargez pas de binaires de correctif non officiels au seul motif qu’ils prétendent résoudre PHP2Shell. Vérifiez la source, les informations de publication et l’intégrité du paquet.

Une mise à jour sûre commence par un inventaire

La remédiation doit commencer par un inventaire plutôt que par une modification immédiate et non vérifiée en production. Identifiez d’abord où PHP s’exécute, y compris les sites web publics, les API, les applications internes, les conteneurs applicatifs, les machines virtuelles, les panneaux d’hébergement web et les appliances tierces. Déterminez ensuite la version de PHP installée, le fournisseur qui la livre et si le correctif de sécurité nécessaire est inclus.

Traitez en priorité les systèmes exposés à Internet. L’équipe de sécurité de PHP énumère des réglages qui réduisent l’exposition à certains chemins d’attaque, mais précise qu’ils ne rendent pas une installation sûre et que seule une mise à jour constitue une solution complète. L’installation d’un environnement d’exécution corrigé est donc le remède indispensable. Avant de modifier les systèmes de production, conservez les configurations nécessaires, effectuez des sauvegardes vérifiées et consignez l’état actuel du déploiement.

Appliquez les paquets mis à jour ou déployez les nouvelles images de conteneurs selon le processus de gestion approprié. Redémarrez ou remplacez les processus workers PHP pour que le code corrigé s’exécute réellement. Enfin, vérifiez la version de PHP ou l’état des correctifs du fournisseur depuis l’environnement opérationnel, confirmez que l’application fonctionne et examinez les journaux (logs) pertinents à la recherche de signes d’exploitation.

Un paquet mis à jour sur le disque ne suffit pas si le service en cours d’exécution utilise encore l’ancien processus PHP.

Les mises à jour dans la même branche présentent le plus faible risque de compatibilité

Pour une application qui utilise déjà une branche de PHP prise en charge, appliquer la version corrective dans cette même branche présentera généralement moins de risque de compatibilité que de passer immédiatement à une version majeure ou mineure plus récente de PHP. Un risque moindre n’est pas un risque nul. Les versions de sécurité modifient le comportement interne de l’environnement d’exécution de PHP, et les journaux des modifications peuvent inclure d’autres corrections de bogues. Les applications qui dépendent d’extensions particulières, de fonctionnalités héritées ou d’un comportement d’exécution inhabituel peuvent nécessiter des tests.

Les administrateurs doivent vérifier plusieurs points avant de déclarer la mise à jour réussie.

Fonctionnement de l’application. Vérifiez la connexion, l’authentification, les transactions métier importantes, les points de terminaison d’API, les envois de fichiers, les tâches en arrière-plan et les interactions avec la base de données.

Extensions PHP. Confirmez que les extensions telles que les pilotes de base de données, les modules de mise en cache, les bibliothèques de traitement d’images et les modules binaires tiers restent disponibles et compatibles.

Sessions et traitement des requêtes. Comme les vulnérabilités touchent à l’état lié aux requêtes, testez le comportement des sessions, les envois de fichiers et le traitement des requêtes dans les applications qui en dépendent fortement.

Conteneurs et infrastructure. Confirmez que les images reconstruites incluent la version corrigée de PHP et que les services déployés utilisent réellement ces images.

Performances et stabilité. Surveillez les erreurs applicatives, les plantages des workers PHP, l’utilisation de la mémoire, la latence et la disponibilité du service après le déploiement.

Les modifications en production doivent suivre une procédure de déploiement ou de maintenance contrôlée, avec une surveillance et un plan de reprise. Si l’application tombe en panne après la mise à jour, revenir à un environnement d’exécution concerné et l’exposer publiquement n’est pas une solution permanente sûre. L’équipe doit plutôt résoudre le problème de compatibilité, utiliser un paquet pris en charge et corrigé par le fournisseur, ou isoler le système pendant la remédiation.

Aucun élément crédible issu des sources examinées n’établit que ces versions de sécurité de PHP provoquent de manière générale des pannes d’applications ou une dégradation importante des performances dans les déploiements existants. Toute affirmation de régression précise doit s’appuyer sur des notes de version, des tests reproductibles ou un incident documenté par le fournisseur.

Un correctif bouche la faille mais n’efface pas une compromission existante

Une mise à jour de sécurité ferme le chemin d’exploitation de la vulnérabilité concernée. Elle ne supprime pas automatiquement les fichiers malveillants, n’annule pas les modifications non autorisées, ne révoque pas les identifiants volés et n’établit pas que l’activité antérieure était sans danger. Comme des tentatives d’exploitation ont été observées avant la divulgation publique, les organisations dont les systèmes étaient exposés auparavant doivent examiner leurs éléments de sécurité. AWS conseille de faire remonter ces investigations au moins au 17 octobre plutôt qu’à la date de divulgation. L’article connexe de TechiesJournal, « Corrigé » ne veut pas dire « sain » (en anglais), traite plus en détail du problème de la remise en état.

Les équipes de sécurité peuvent enquêter sur les erreurs de mémoire PHP inhabituelles, les arrêts anormaux de workers, les processus enfants inattendus, les fichiers applicatifs modifiés, les connexions sortantes suspectes et les requêtes HTTP inhabituelles. Une alerte ou une requête suspecte ne prouve pas à elle seule une compromission : les constats doivent donc être examinés en contexte et recoupés avec les autres éléments disponibles.

Lorsqu’une compromission est établie ou raisonnablement suspectée, la réponse peut exiger l’isolement, la préservation des preuves, le renouvellement des identifiants, la reconstruction des systèmes touchés et une enquête sur l’incident.

Les règles de pare-feu et de CDN réduisent l’exposition mais ne remplacent pas le correctif

Des fournisseurs de sécurité comme Cloudflare ont déployé des protections contre les schémas d’attaque connus de PHP2Shell. Selon Cloudflare, les clients gratuits et payants de son pare-feu applicatif web (WAF) étaient protégés par défaut à partir de 3 h 02 UTC le 21 octobre, environ neuf heures avant la divulgation publique. Ces protections peuvent contribuer à réduire l’exposition pendant que les organisations installent les mises à jour nécessaires.

Les règles WAF ne garantissent toutefois pas que tous les chemins d’exploitation possibles sont bloqués. Les attaquants peuvent modifier leurs requêtes, découvrir d’autres techniques ou atteindre les systèmes par des voies qui contournent la couche de protection, et Cloudflare a lui-même observé des attaquants modifier leurs charges utiles. C’est pourquoi les règles de pare-feu doivent être considérées comme des contrôles défensifs supplémentaires, et non comme un substitut à la correction de l’environnement d’exécution PHP.

La leçon dépasse PHP

PHP2Shell illustre un problème de sécurité qui va au-delà de PHP. Les applications modernes reposent sur des couches logicielles que les équipes de développement ne maintiennent pas forcément elles-mêmes. Une application peut suivre de bonnes pratiques de sécurité tout en dépendant d’un environnement d’exécution, d’un système d’exploitation, d’une bibliothèque ou d’un composant d’hébergement vulnérable. Cela crée des responsabilités pour les équipes de développement, d’exploitation, d’infrastructure et de sécurité.

Les organisations doivent savoir quels logiciels s’exécutent, d’où ils viennent, qui les maintient et à quelle vitesse une mise à jour de sécurité vérifiée peut atteindre la production. Pour PHP2Shell, les priorités immédiates sont d’identifier les systèmes concernés, installer des correctifs vérifiés, confirmer que l’environnement d’exécution corrigé est bien en service et enquêter sur une éventuelle compromission.

La leçon plus générale est que sécuriser le code applicatif est essentiel, mais ne remplace pas la sécurisation du logiciel qui l’exécute.

Pour aller plus loin

Recherches examinées le 22 octobre 2026. L’activité des menaces, la disponibilité des correctifs et les recommandations des fournisseurs peuvent évoluer rapidement : consultez les sources primaires avant d’agir.

Sources des éditeurs, des pouvoirs publics et de la recherche

• PHP Security Team, official security announcement, 21 octobre 2026 : la source des correctifs de sécurité, des environnements d’exécution concernés et des recommandations officielles de mise à jour.
• Canadian Centre for Cyber Security, AL26-026, 21 octobre 2026 : l’évaluation du gouvernement canadien et les mesures recommandées.
• Wiz Research, PHP2Shell investigation, 21 octobre 2026 : historique de la découverte, recherche technique et démonstrations en environnement contrôlé.
• OpenAI, coordinated disclosure of critical vulnerabilities, 21 octobre 2026 : découverte indépendante, recherche assistée par l’IA et coordination de la réponse.
• PHP2Shell, joint research resource : crédits de recherche, présentation technique et périmètre des démonstrations.

Attaques observées et protections

• AWS Security Blog, early exploitation attempts, 21 octobre 2026 : éléments sur les attaques observées, y compris l’activité antérieure à la divulgation.
• Cloudflare, PHP2Shell mitigations, 21 octobre 2026 : trafic malveillant observé et déploiement de contrôles de protection.

Obtenir le correctif

• PHP downloads and installation : ressources officielles de téléchargement et d’installation.
• PHP 8 changelog : détail des modifications de chaque version, pour l’analyse de compatibilité et de régression.

Les organisations qui évaluent leur exposition éventuelle doivent consulter les bulletins actuels des fournisseurs et leurs propres procédures de réponse aux incidents. Les rapports publics examinés n’établissent pas que toutes les installations ont été compromises.

À lire aussi sur TechiesJournal

• « Corrigé » ne veut pas dire « sain » : que faire après la correction d’un équipement de périphérie exploité (en anglais), TechiesJournal, octobre 2026 : pourquoi corriger une vulnérabilité ne supprime pas automatiquement une compromission existante.
• Quand une application cloud de confiance devient un vecteur d’attaque (en anglais), pour un autre cas où un composant de confiance, plutôt que le propre code des défenseurs, est devenu la porte d’entrée.