Par Axel Legay — 24 octobre 2026
Le 21 octobre 2026, deux vulnérabilités critiques affectant PHP ont attiré l’attention de la communauté de la cybersécurité. Identifiées sous les références CVE-2026-109618 et CVE-2026-109619 et regroupées sous le nom de PHP2Shell, elles concernent directement la gestion de la mémoire du moteur PHP. Leur particularité est importante : dans certaines configurations, un attaquant peut parvenir à exécuter du code sur un serveur sans disposer d’un compte utilisateur et sans exploiter une erreur dans le code de l’application web.
PHP est utilisé par une multitude de sites et d’applications, notamment WordPress, Drupal, Joomla et de nombreux outils professionnels. Une vulnérabilité dans son moteur d’exécution peut donc avoir des conséquences bien plus larges qu’une faille affectant un site particulier. Pour comprendre PHP2Shell, il faut revenir sur le fonctionnement interne de PHP et sur deux problèmes classiques en sécurité informatique : la corruption mémoire et le Use-After-Free.
PHP et Zend : comprendre ce qui se passe derrière une page web
Lorsqu’un utilisateur consulte une page PHP, son navigateur envoie une requête HTTP à un serveur web. Ce dernier fait intervenir PHP pour traiter la demande et produire la réponse.
PHP s’appuie sur un composant appelé Zend Engine. C’est son moteur d’exécution, développé principalement en langage C. Zend interprète les instructions PHP, manipule les variables et gère la mémoire nécessaire au fonctionnement du programme.
Prenons un exemple simple :
<?php
$nom = "Axel";
echo "Bonjour " . $nom;
?>Avant d’afficher « Bonjour Axel », PHP doit notamment réserver de la mémoire pour stocker la variable, préparer les opérations à effectuer et gérer les ressources utilisées. Une fois certaines données devenues inutiles, les zones mémoire correspondantes peuvent être libérées.
Ces opérations sont réalisées automatiquement. Le développeur PHP n’a généralement pas à s’en préoccuper, contrairement à ce qui se passe dans des langages de plus bas niveau comme le C.
Cependant, une erreur dans la gestion de ces opérations peut provoquer une corruption mémoire. C’est précisément le type de problème rencontré avec PHP2Shell.
Il faut également comprendre que PHP commence à travailler avant même d’exécuter le programme demandé. Lorsqu’un navigateur transmet un formulaire, par exemple, PHP doit analyser les données reçues et les organiser en mémoire. Une vulnérabilité présente dans cette phase préparatoire peut donc être déclenchée avant que l’application n’ait eu l’occasion d’effectuer ses propres contrôles de sécurité.
CVE-2026-109618 : quand PHP manque de mémoire au mauvais moment
La première vulnérabilité concerne la manière dont PHP réagit lorsqu’une allocation mémoire échoue.
Un programme informatique réserve régulièrement de nouvelles zones de mémoire pour stocker des informations. Si cette réservation échoue, notamment parce qu’une limite a été atteinte, le programme doit interrompre l’opération et nettoyer correctement les ressources déjà utilisées.
C’est une situation normale qu’un logiciel robuste doit savoir gérer.
Le problème apparaît lorsque l’interruption survient au milieu de la création d’une structure interne. Imaginons que PHP prépare un tableau destiné à stocker les informations reçues dans une requête HTTP. Le moteur commence à créer un nouvel élément, modifie certaines informations internes, puis rencontre un problème de mémoire avant d’avoir terminé.
PHP doit alors abandonner l’opération et libérer les ressources concernées. Mais si les informations décrivant le tableau ne correspondent plus à son contenu réel, le moteur risque de manipuler des données qui n’ont pas été correctement initialisées.
Dans le scénario d’exploitation décrit pour cette vulnérabilité, un attaquant peut provoquer cette situation à l’aide d’une requête HTTP spécialement construite. Il cherche à influencer l’organisation de la mémoire, puis à déclencher un échec d’allocation à un moment précis.
Lorsque PHP tente de nettoyer les structures concernées, certaines données peuvent être interprétées comme des informations internes valides alors qu’elles ne devraient pas l’être.
C’est ce qui rend la vulnérabilité dangereuse. Il ne s’agit pas simplement de provoquer un plantage du serveur : dans des conditions particulières, la corruption mémoire peut être exploitée pour détourner le fonctionnement du moteur PHP et obtenir une exécution de code.
Des chercheurs ont notamment démontré qu’il était possible de provoquer l’exécution d’une commande système pendant les opérations de nettoyage de PHP, avant même que le script de l’application ne commence son travail.
CVE-2026-109619 : le problème du Use-After-Free
La seconde vulnérabilité repose sur un mécanisme différent, appelé Use-After-Free, ou UAF.
Le principe est relativement simple. Lorsqu’un programme n’a plus besoin d’une zone mémoire, il la libère afin qu’elle puisse être réutilisée. Mais il peut arriver qu’il conserve accidentellement une référence vers cette zone et tente de l’utiliser plus tard.
Prenons un exemple en langage C :
char *p = malloc(100);
p[0] = 'A';
free(p);
p[0] = 'B';La première instruction réserve 100 octets de mémoire. Le programme y écrit ensuite une lettre, puis libère cette mémoire avec free().
La dernière instruction constitue l’erreur : elle tente d’écrire dans une zone mémoire qui a déjà été libérée.
Ce type de défaut peut simplement faire planter le programme. Mais il peut aussi avoir des conséquences plus graves si la zone libérée a été réattribuée entre-temps à une autre structure.
Imaginons qu’une première opération libère un emplacement mémoire et qu’une seconde opération y stocke de nouvelles informations. Si le programme utilise ensuite son ancienne référence, il risque de modifier ces nouvelles informations sans en avoir conscience.
Un attaquant capable d’influencer les données placées dans cette zone peut parfois exploiter cette confusion pour modifier le comportement du programme.
Dans le cas de CVE-2026-109619, le problème concerne la conservation de certaines informations internes après la fin d’une requête PHP. Des références peuvent subsister alors que les zones mémoire correspondantes ont été libérées.
Lorsqu’une nouvelle requête arrive et qu’elle est traitée par le même processus PHP, ces références peuvent être réutilisées alors qu’elles ne sont plus valides.
Le caractère particulier de cette vulnérabilité est donc qu’elle peut faire intervenir plusieurs requêtes successives. Une première requête contribue à créer un état mémoire incorrect, puis une autre peut déclencher son utilisation.
Il ne faut toutefois pas en conclure que toutes les installations PHP sont exploitables de la même manière. Le comportement dépend notamment de la version, de la configuration et de la manière dont les processus PHP traitent les requêtes.
Deux vulnérabilités différentes, pas nécessairement une attaque combinée
La publication simultanée de deux vulnérabilités critiques peut laisser penser qu’un attaquant doit obligatoirement les combiner pour compromettre un serveur.
Ce n’est pas le cas.
CVE-2026-109618 concerne principalement une corruption mémoire provoquée lorsqu’une opération est interrompue par un échec d’allocation. CVE-2026-109619 concerne l’utilisation d’une référence vers une mémoire déjà libérée.
Les mécanismes sont différents et les vulnérabilités peuvent être exploitées indépendamment dans les conditions appropriées.
Il faut néanmoins distinguer le déclenchement d’une vulnérabilité de son exploitation complète. Une erreur mémoire ne donne pas automatiquement le contrôle du serveur. L’attaquant doit réussir à transformer cette erreur en un comportement exploitable, ce qui peut nécessiter une connaissance précise de l’organisation de la mémoire et du fonctionnement interne du moteur PHP.
C’est notamment ce qui distingue un simple plantage d’une véritable exécution de code à distance.
Comment une requête HTTP peut-elle provoquer une exécution de code ?
C’est probablement l’aspect le plus surprenant de PHP2Shell.
Dans une attaque classique par injection de commandes, le développeur a généralement commis une erreur en utilisant directement une donnée fournie par l’utilisateur dans une commande système.
Avec PHP2Shell, le scénario est différent. L’attaquant n’a pas besoin de trouver une fonction dangereuse dans le code du site. Il cherche à provoquer un comportement anormal dans le moteur PHP lui-même.
L’attaque peut se dérouler en plusieurs phases.
Dans un premier temps, l’attaquant envoie une ou plusieurs requêtes HTTP contenant des données conçues pour influencer les allocations mémoire effectuées par PHP. Le moteur traite ces informations comme il le ferait pour n’importe quel formulaire ou téléchargement.
Ensuite, l’attaquant cherche à provoquer la situation particulière correspondant à la vulnérabilité : un échec d’allocation pendant l’initialisation d’une structure dans le premier cas, ou la réutilisation d’une référence mémoire invalide dans le second.
Enfin, si les conditions nécessaires sont réunies, le moteur PHP peut interpréter des données mémoire incorrectes comme des informations internes légitimes. Dans les scénarios les plus graves, cela peut conduire à détourner le déroulement normal du programme et à exécuter une commande sur le serveur.
Cette commande s’exécute avec les droits du processus PHP concerné. Il ne s’agit donc pas automatiquement d’un accès administrateur, mais ces droits peuvent déjà être suffisants pour lire certains fichiers, accéder à des paramètres de configuration ou compromettre l’application.
L’élément essentiel est que l’attaque peut intervenir avant l’exécution du code PHP du site. Même une application correctement développée peut donc être exposée si elle fonctionne sur une version vulnérable du moteur.
Pourquoi ces problèmes ont-ils pu rester présents pendant des années ?
Les erreurs de gestion mémoire comptent parmi les vulnérabilités les plus difficiles à identifier.
Un programme peut fonctionner correctement pendant des années sans rencontrer les circonstances nécessaires au déclenchement d’un défaut particulier. Dans le cas d’une corruption mémoire, il faut parfois une succession très précise d’allocations, de libérations et d’opérations interrompues pour faire apparaître le problème.
Les tests fonctionnels classiques ne recherchent pas nécessairement ces situations. Ils vérifient qu’une application produit les résultats attendus, mais pas toujours qu’elle se comporte correctement lorsqu’une allocation échoue au milieu d’une opération interne.
Les outils spécialisés, comme les fuzzers, AddressSanitizer ou les débogueurs mémoire, permettent de découvrir certaines de ces anomalies. Ils consistent notamment à soumettre des données inhabituelles aux logiciels ou à surveiller les accès mémoire incorrects.
Mais la complexité du moteur PHP, développé principalement en C et maintenu depuis plusieurs décennies, rend l’analyse particulièrement exigeante.
Une vulnérabilité découverte en 2026 peut donc avoir été introduite bien auparavant. Cela ne signifie pas pour autant que son exploitation était connue depuis son introduction, ni qu’elle était possible dans toutes les configurations.
Quels environnements sont exposés ?
Les vulnérabilités concernent le moteur PHP et non un CMS particulier. Des applications WordPress, Drupal, Joomla ou développées sur mesure peuvent donc être concernées si elles reposent sur une version vulnérable.
Plusieurs environnements d’exécution doivent être examinés, notamment Apache avec mod_php, PHP-FPM et les autres configurations qui intègrent le moteur PHP.
Le risque réel dépend cependant de plusieurs facteurs : la version installée, les correctifs éventuellement appliqués par le fournisseur, les paramètres mémoire, le traitement des requêtes et le fonctionnement des processus.
Les premières versions corrigées des branches maintenues concernées sont les suivantes :
| Branche | Version corrigée |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Pour les installations plus anciennes, il est indispensable de consulter les avis de sécurité du fournisseur ou de la distribution Linux. Certains correctifs peuvent être intégrés sans modification du numéro de version principal.
La simple mise à jour d’un site WordPress ou de ses extensions ne suffit pas si le moteur PHP sous-jacent reste vulnérable.
Peut-on détecter une exploitation de PHP2Shell ?
La détection est délicate parce que les attaques peuvent intervenir très tôt dans le traitement d’une requête HTTP.
Les journaux applicatifs ne contiennent donc pas nécessairement les informations permettant d’identifier le problème.
Certains comportements peuvent néanmoins être révélateurs : des requêtes POST inhabituelles, des erreurs mémoire répétées, des arrêts inattendus de processus PHP ou encore le lancement de commandes système qui ne correspondent pas au fonctionnement normal du site.
L’analyse des journaux du serveur web, des événements système et des processus exécutés peut contribuer à identifier une activité suspecte. Un dispositif de surveillance capable de détecter les commandes lancées par les processus PHP peut également fournir des indices précieux.
Un pare-feu applicatif peut bloquer certaines requêtes malveillantes, mais il ne remplace pas la correction du moteur PHP. Une règle de filtrage adaptée à une technique d’exploitation particulière ne garantit pas une protection contre toutes les variantes possibles.
La mesure prioritaire reste donc l’installation des versions corrigées, suivie d’une vérification des environnements réellement utilisés.
Ce que PHP2Shell nous apprend sur la sécurité des applications
PHP2Shell rappelle qu’une application web ne peut pas être considérée comme sécurisée uniquement parce que son code respecte les bonnes pratiques de développement.
La sécurité dépend également des composants sur lesquels elle repose : moteur d’exécution, serveur web, bibliothèques système et environnement d’hébergement.
Les deux vulnérabilités illustrent aussi deux mécanismes fondamentaux de la sécurité des logiciels. Le premier montre comment une interruption au mauvais moment peut laisser des structures mémoire incohérentes. Le second montre comment la réutilisation d’une référence après libération peut conduire à manipuler des données qui ne devraient plus être accessibles.
Dans les deux cas, une erreur qui pourrait sembler limitée à un problème de stabilité peut, dans certaines circonstances, devenir une vulnérabilité permettant l’exécution de code à distance.
C’est toute la difficulté de la sécurité mémoire : un programme ne doit pas seulement produire le bon résultat lorsqu’il fonctionne normalement, il doit également préserver l’intégrité de ses structures internes lorsque quelque chose se passe mal.
Avec PHP2Shell, le danger ne vient pas nécessairement de ce que le développeur a demandé à PHP de faire, mais de la manière dont PHP gère lui-même certaines opérations. Et c’est précisément ce qui rend ces vulnérabilités particulièrement importantes pour l’ensemble de l’écosystème web.