PHP2Shell est le nom donné à deux vulnérabilités critiques du moteur PHP : CVE-2026-109618 et CVE-2026-109619. Dans certaines conditions, elles peuvent permettre à un attaquant sans compte ni connexion préalable d’exécuter du code sur un serveur. Le 21 octobre 2026, PHP a publié des versions corrigées : 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
5
36
Pour les responsables de sites et de systèmes, l’urgence est de mettre à jour le moteur PHP qui traite les requêtes web — ou d’installer le correctif fourni par l’éditeur d’un produit qui embarque PHP — puis de vérifier que la correction est bien active.
Deux failles dans PHP, pas seulement dans les sites web
Les vulnérabilités concernent la gestion de la mémoire par PHP lui-même, et non nécessairement le code d’une application particulière. Les recherches décrivent des scénarios où de la mémoire libérée ou un état interne périmé peuvent être réutilisés pendant le fonctionnement du moteur.
6
9
- CVE-2026-109618 est liée au traitement de la progression des téléversements. Wiz décrit une vulnérabilité de type « use-after-free » — l’utilisation d’une zone mémoire après sa libération — susceptible d’exposer la mémoire d’un processus PHP et, dans les conditions démontrées, de contribuer à une corruption mémoire puis à l’exécution de code.
6
- CVE-2026-109619 concerne la gestion de la mémoire lors de la création de traces d’erreur fatale et le fonctionnement d’OPcache. L’avis de PHP évoque un état interne périmé qui peut être réutilisé par une requête ultérieure traitée par le même processus.
6
36
Les deux vulnérabilités sont notées 9,2 sur l’échelle CVSS dans les sources citées.
2
37 Wiz estime que PHP est utilisé par environ 70 % du Web. Ce chiffre concerne la diffusion de cette technologie : il ne signifie pas que 70 % des sites sont vulnérables de la même façon, ni qu’ils ont été compromis.
6
Versions concernées et correctifs disponibles
Les sources citées situent la plage vulnérable entre PHP 5.4 et 8.5.11.
56 Les versions corrigées publiées par PHP sont 8.2.35, 8.3.36, 8.4.27 et 8.5.12.
36
Si votre système utilise une version plus ancienne ou qui n’est plus prise en charge, vérifiez auprès de votre distributeur PHP ou de l’éditeur du produit si une mise à jour adaptée ou un correctif rétroporté est disponible. Ne partez pas du principe qu’une mise à niveau classique de PHP sera possible.
17
54
Mettre à jour un paquet PHP ne suffit pas toujours : un site, une appliance ou un autre logiciel peut embarquer son propre moteur. Identifiez l’installation qui répond effectivement aux requêtes web et suivez les consignes de l’éditeur pour les produits qui intègrent PHP.
5
54
Une découverte assistée par IA, avec des dates qui varient selon les sources
La découverte est attribuée à Calif, OpenAI et Wiz, et plusieurs récits indiquent que des modèles d’IA ont contribué aux recherches.
4
16 Les dates rapportées ne concordent toutefois pas entièrement : USA Today parle d’une première découverte par Calif en juillet, puis d’une découverte indépendante par Wiz en août. The Register situe le travail des chercheurs entre août et septembre.
4
47 D’autres articles mentionnent aussi des modèles de Google, sans établir précisément le rôle de chaque modèle ni la part de travail autonome.
50
La nuance est importante : les éléments disponibles étayent l’idée d’une recherche assistée par IA, pas celle d’un système d’IA ayant découvert, vérifié et corrigé seul les deux failles. Les chercheurs et les responsables de la maintenance de PHP ont également participé à la découverte et à la réponse rapportées.
4
16
Que signifie l’avis concernant PAN-OS ?
Palo Alto Networks a publié un avis sur les conséquences possibles des deux vulnérabilités PHP pour ses produits, dont des familles de produits PAN-OS.
34
35 Cela ne prouve pas, à lui seul, que toutes les installations PAN-OS sont exposées au même scénario d’attaque qu’un serveur web PHP. Le produit, sa configuration et le correctif applicable doivent être vérifiés.
Les administrateurs doivent consulter l’avis à jour de Palo Alto Networks pour leur produit et leur version, puis suivre les instructions du fournisseur. Ne prenez pas un calendrier de correctifs tiers pour une confirmation de disponibilité : un outil de suivi en circulation précise que ses informations sur les fournisseurs sont générées par IA et doivent être vérifiées.
21
Tentatives d’exploitation : elles ne prouvent pas une compromission
Des renseignements sur les menaces font état d’une tentative d’exploitation enregistrée le 17 octobre, avant la divulgation technique publique et la publication des correctifs, le 21 octobre.
53 Selon Nextgov, le trafic observé par Cloudflare serait ensuite passé de milliers de tentatives à des millions.
22 Ces chiffres comptabilisent des tentatives, pas des prises de contrôle réussies.
Les informations sur d’éventuelles exploitations réussies ont varié. Le 22 octobre, la BBC rapportait qu’aucune exploitation réussie n’avait alors été signalée.
18 Par la suite, Unit 42, l’équipe de renseignement sur les menaces de Palo Alto Networks, a indiqué ne pas pouvoir confirmer que l’activité initialement associée à PHP2Shell provenait de ces CVE précises et a retiré sa mise à jour précédente.
30 Au vu des éléments disponibles ici, des tentatives sont rapportées, mais les compromissions confirmées attribuables à PHP2Shell restent incertaines.
Des administrations et des entreprises auraient temporairement mis certains services hors ligne le temps de préparer ou d’appliquer les correctifs.
26
51 Une interruption préventive n’est pas une preuve de piratage.
Les mesures à prendre
- Recensez tous les moteurs PHP. Vérifiez les sites web, serveurs applicatifs, conteneurs, environnements d’hébergement et appliances. Demandez à votre hébergeur ou prestataire de confirmer la version utilisée et le correctif applicable.
- Installez une mise à jour vérifiée. Utilisez une version corrigée de PHP ou un paquet fourni par l’éditeur qui intègre les correctifs. Pour les appliances et logiciels qui embarquent PHP, suivez les instructions de leur fournisseur.
17
36
54
- Vérifiez le service en production. Assurez-vous que le moteur exposé sur le Web a bien été mis à jour, et pas seulement une installation distincte en ligne de commande. Vérifiez également que les processus ou services nécessaires tournent avec la version corrigée.
- Limitez l’exposition si vous ne pouvez pas corriger immédiatement. La NSA recommande de donner la priorité aux correctifs des fournisseurs et de mettre un système hors ligne si une mise à jour immédiate n’est pas possible.
17 Selon Nextgov, le FBI et la CISA ont également appelé les organisations américaines à traiter rapidement ces failles.
25
- Distinguez correction et enquête. La mise à jour corrige la vulnérabilité, mais ne permet pas de savoir si une intrusion antérieure a eu lieu. En cas de soupçon, examinez les journaux et l’activité du système séparément.
Si vous possédez un site sans administrer son serveur, contactez votre hébergeur ou le responsable technique et demandez si le moteur PHP a été mis à jour. N’installez pas de correctif reçu par message non sollicité : utilisez les consignes officielles de votre prestataire.
À retenir : un système peut être vulnérable, faire l’objet de tentatives d’attaque ou avoir été compromis — ce sont trois situations différentes. Corrigez le moteur PHP concerné, vérifiez auprès du fournisseur la situation des produits comme PAN-OS et traitez toute suspicion d’intrusion à part.