Un chercheur en sécurité rapporte avoir détecté une exploitation réussie de la faille PHP2Shell, alors que des millions d'hôtes PHP tardent à appliquer les correctifs

Et restent exposés en ligne

La faille de sécurités PHP2Shell ferait actuellement l'objet d'exploitations actives par des pirates informatiques. PHP2Shell exploite les vulnérabilités CVE-2026-109618 et CVE-2026-109619. Des experts en cybersécurité ont enregistré des tentatives d'attaque ciblant des configurations Apache mod_php. En réaction à ces menaces, l'équipe de développement de PHP a rapidement déployé des correctifs d'urgence pour neutraliser ces vulnérabilités majeures. Toutefois, la maintenance du projet semble à bout de souffle. Un manque de ressources financières et humaines serait à l’origine des défaillances de sécurité de PHP. Il ne compte qu'un seul employé à temps plein.

Le langage PHP a récemment été touché par plusieurs failles de sécurité, dont deux majeures répertoriées sous les noms CVE-2026-109618 et CVE-2026-109619, et évaluées à 9,2 sur 10 sur l'échelle de gravité. Ces deux vulnérabilités ont déclenché une alerte de sécurité mondiale et des correctifs ont été déployés en urgence. De nombreuses entreprises et administration publiques ont mis leurs sites Web hors ligne par mesure de précaution.

CVE-2026-109618 et CVE-2026-109619 ont été regroupées sous le nom collectif PHP2Shell. La directrice exécutive de la Fondation PHP, Elizabeth Barron, a déclaré à Reuters que l'organisation ne dispose d'aucune preuve d'exploitation par des pirates, mais un chercheur en cybersécurité affirme en avoir trouvé.

Analyse technique et validations par d'autres chercheurs

L'activité malveillante a été capturée par Adel Karimi, responsable de la détection et de la réponse chez Perplexity AI, dont les pots de miel ont enregistré des preuves confirmées d'exécution de code à distance (RCE) ciblant une installation Apache mod_php sous PHP 8.4.26. « Il s’agit d’une RCE confirmée accompagnée d’une divulgation de mémoire exploitable, et non plus simplement d’un plantage suivi d’un processus suspect », a-t-il expliqué.


« La réponse a fourni un dump de cookie décodé de 800 KiB, et une adresse de fonction dérivée de ce dump à l’aide des décalages de l’exploit public apparaît dans la charge utile d’exécution suivante », a ajouté Adel Karimi. Les conclusions d'Adel Karimi ont également été confirmées par Marcus Hutchins, chercheur en cybersécurité chez Expel, qui suit de près une série de rapports faisant état d’exploitations présumées réussies de PHP2Shell.

« C’est de loin la confirmation la plus fiable d’une exploitation de php2shell en milieu réel que j’ai vue jusqu’à présent. Il s’agit d’une analyse technique approfondie d’une tentative d’exploitation réussie contre une installation Apache mod_php fonctionnant sous PHP 8.4.26 », a déclaré l'expert Marcus Hutchins.

Adel Karimi a toutefois nuancé la portée du test en précisant : « les éléments démontrent cette chaîne d’exploitation sur le profil mod_php à processus unique, volontairement favorable ; ils ne constituent pas une mesure de la fiabilité de l’exploit avec d’autres nombres de processus, d’autres versions de PHP ou d’autres applications ». D'autres tentatives d'exploitation ont été signalées sur la toile, mais elles n'ont pas été confirmées officiellement.

Calendrier des correctifs et tentatives d'attaque préalables

Sur le plan institutionnel, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a publié une règle de détection SIGMA pour contrer les tentatives d'exploitation de la la faille PHP2Shell, sans pour autant avoir encore formellement répertorié ces failles comme étant exploitées dans la nature au moment du rapport. L'équipe de sécurité du langage a déployé des correctifs le 21 octobre, un jour après lancé l'alerte mondiale.

Avant la publication officielle de ces correctifs, des informations sur les vulnérabilités avaient fuité sur Internet et quelques preuves de concept avaient été publiées. Bien que plusieurs sociétés de cybersécurité, comme Cloudflare, Hadrian, watchTowr, Previdian ou Patchstack, aient repéré des tentatives de ciblage plusieurs jours avant la sortie des patchs, ces actions restaient limitées à un simple balayage et à des exploitations non fonctionnelles.

L'équipe de sécurité PHP a signalé l'existence d'une autre vulnérabilité d'exécution de code à distance, répertoriée sous le nom CVE-2026-115560, pour laquelle aucun correctif n'est disponible actuellement. Elle ne peut être exploitée que sur des systèmes présentant un assemblage très particulier de configurations et de code applicatif. L'équipe a recommandé de définir la variable « session.upload_progress.enabled=0 » afin de bloquer d'éventuelles attaques.

La portée de ces menaces demeure considérable puisque le langage PHP propulse environ 70% de l'ensemble des sites Web sur Internet. Selon les estimations de VirusTotal, plus de 5,1 millions d'hôtes PHP sont exposés en ligne, dont près de 3,8 millions possèdent au moins un port ouvert aux attaques.

Le projet manque de ressources financières et humaines

Les vulnérabilités se sont multipliées au fil des versions et pourraient résulter des difficultés de la Fondation PHP. Et les récentes défaillances ont mis en évidence le manque criant de ressources financières et humaines affectées au développement du projet. La fondation ne compte qu'une seule employée à plein temps, sa directrice exécutive Elizabeth Barron, accompagnée d'environ 14 prestataires qui travaillent principalement à temps partiel.

« Nous comptons un employé à temps plein (c’est-à-dire moi-même) et 14 collaborateurs, pour la plupart à temps partiel », a expliqué Elizabeth Barron dans un courriel envoyé à Reuters. Les membres du conseil d’administration sont des bénévoles non rémunérés, et le financement provient de dons et de subventions. Selon la directrice, le manque de moyens financiers suffisants a directement influé sur leur réactivité face aux menaces.

Cette organisation contraste avec celle d'autres grands projets open source comme le noyau Linux, lequel s'appuie sur de nombreux développeurs employés à temps plein par divers groupes et entreprises. « Ah, alors tout Internet repose sur une seule femme. WordPress, Drupal, Joomla, Magento, Shopify et tous ces projets qui existent grâce à PHP jouent aux aveugles en attendant la mort du langage principal du Web », s'interroge un critique.

Laxisme de l'écosystème et maintien de versions obsolètes

Au-delà des fragilités du code source, la crise révèle un problème majeur au niveau de la gestion des serveurs sur Internet. En théorie, tout serveur exécutant la version 8.x actuelle du langage aurait dû pouvoir être mis à jour en quelques minutes grâce aux correctifs publiés, mais la réalité s’est avérée bien différente, les sites Web ayant été mis hors ligne pendant des heures, voire des jours, par crainte d’une exploitation de la faille PHP2Shell.


Près de 73 % des installations PHP utilisaient des versions dont la date de fin de vie (End of Life - EOL) était largement dépassée, ce qui signifie qu’il est désormais bien plus difficile d’obtenir des correctifs. Bon nombre de ces serveurs fonctionnaient sous PHP 7, une version dont la fin de vie a été annonce il y a plus de quatre ans, après plusieurs années d’avertissement préalable, et qui avait initialement été lancée fin 2015, il y a près de onze ans.

Si cela ne vous paraît pas assez absurde, sachez qu’environ 7,7 % des sites PHP fonctionnent encore sous la version 5.x, lancée il y a 22 ans, en 2005, et dont la fin de vie a été définitive en 2018. On peut affirmer sans risque de se tromper que tout le monde a eu largement le temps de s’y préparer.

Le passage de PHP 5 à 7, puis de 7 à 8, a nécessité de modifier certaines parties du code des sites Web, mais la grande majorité de ces modifications sont faciles à repérer et à appliquer. Elles consistaient à supprimer la prise en charge de fonctions et de bibliothèques obsolètes pour lesquelles des avertissements annonçant leur dépréciation étaient déjà en place depuis longtemps. Il existe de nombreux outils automatisés de correction du code.

Peu de fonctionnalités linguistiques fondamentales ont été modifiées, et l'équipe de développement a ajouté de nombreuses syntaxes pratiques pour aider à clarifier un code fastidieux et source d’erreurs. Selon les spécialistes de la sécurité, le constat actuel démontre que la complaisance, la paresse et les coupes budgétaires des organisations constituent un risque bien plus grand pour la sécurité du réseau que les cyberattaques automatisées.

Sources : la Fondation PHP, billets de blogue (1, 2, 3, 4)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du manque de ressources financières et humaines dont souffre le projet PHP ?
Comment en est-on arrivé là en dépit du nombre impressionnant de projets qui dépendent du langage PHP ?
Que pensez-vous de l'omniprésence des versions obsolètes du langage PHP sur les serveurs Web ?

Voir aussi

La fondation à but non lucratif qui s'occupe de PHP, un langage de programmation très vulnérable qui alimente jusqu'à 70 % des sites Web dans le monde, ne compte qu'un seul employé à temps plein

PHP corrige des vulnérabilités critiques PHP2Shell détectées par l'IA et touchant des millions de sites, OpenAI indique que des recherches en sécurité assistées par l'IA ont permis de les identifier

Des centaines de sites Web mis hors ligne alors que deux failles de sécurité majeures dans PHP sèment la panique dans le monde : « mettez-les hors ligne si vous n'avez pas encore installé le correctif »