PHP2Shell : une nouvelle faille critique découverte, mais aucun correctif d'urgence prévu

A hand about to touch a phone. Superimposed on top of it is a pink triangle with exclamation mark inside it. Behind it is a computer display with code on it
(Crédit photo: Getty Images)

  • PHP a révélé une nouvelle vulnérabilité permettant potentiellement l'exécution de code à distance, mais son exploitation exige une configuration rare et très précise.
  • Contrairement aux deux failles PHP2Shell, cette nouvelle vulnérabilité sera corrigée dans une mise à jour régulière, plutôt que par un correctif d'urgence.
  • Les attaques PHP2Shell semblent avoir provoqué relativement peu de compromissions à ce stade, mais l'installation rapide des mises à jour reste indispensable.

L'équipe de sécurité de PHP a découvert une nouvelle vulnérabilité permettant potentiellement l'exécution de code à distance, ou RCE (remote code execution), dans le langage de programmation désormais associé à PHP2Shell. Mais comme ce nouveau défaut est particulièrement difficile à exploiter, aucun correctif d'urgence ne sera publié en dehors du calendrier habituel.

L'organisation a récemment diffusé un nouvel avis de sécurité concernant un problème lié au suivi de progression des téléversements dans les sessions PHP, référencé CVE-2026-115560. Selon cet avis, la faille ne peut être exploitée que dans le cadre d'une « combinaison inhabituelle de configuration et de code applicatif ».

« Une application doit configurer session.serialize_handler sur php_binary ou php_serialize, puis basculer vers php à l'exécution avec ini_set() avant d'appeler session_start(). Le suivi de progression des téléversements doit également être activé. Les applications qui ne modifient jamais le gestionnaire de sérialisation à l'exécution peuvent conserver cette fonctionnalité activée », précise l'avis.

En conséquence, seules les installations utilisant précisément cette combinaison de paramètres sont exposées à cette vulnérabilité particulière. L'équipe de sécurité de PHP recommande également de définir session.upload_progress.enabled=0 jusqu'à la prochaine mise à jour corrective régulière. Cette mesure permet de neutraliser le vecteur d'exécution de code, jugé « peu probable ». Elle figurait déjà parmi les protections recommandées contre CVE-2026-109619. Les administrateurs l'ayant appliquée à cette occasion n'ont donc pas besoin de la modifier.

PHP2Shell

CVE-2026-109619 est l'une des deux vulnérabilités critiques permettant potentiellement l'exécution de code à distance récemment découvertes dans PHP et regroupées sous le nom de PHP2Shell. Leur découverte a provoqué une vive inquiétude dans le secteur de la cybersécurité, tant leurs conséquences potentielles semblaient considérables.

PHP est un langage de programmation extrêmement répandu, utilisé pour concevoir des sites et applications web. Selon certaines estimations, environ 70 % des sites Internet s'appuient sur ce langage, notamment dans les secteurs bancaire, éducatif, médical et gouvernemental. Lorsque les premières informations sur PHP2Shell ont circulé, l'équipe de sécurité de PHP travaillait déjà à la publication de correctifs, en collaboration avec plusieurs organisations spécialisées. Les vulnérabilités pouvaient théoriquement permettre à des pirates de prendre complètement le contrôle de sites vulnérables.

Les organisations informées devaient respecter un embargo jusqu'à la publication des correctifs, afin d'éviter d'avertir les cybercriminels. Mais des informations ont fuité, et les équipes d'Amazon Web Services ont observé des tentatives d'exploitation quatre jours avant la date prévue pour les mises à jour.

Quelques heures avant la publication officielle, le dirigeant de l'entreprise de cybersécurité Chainguard a diffusé des images de conteneurs intégrant déjà les corrections, rompant de fait l'embargo. Une partie de la communauté de la sécurité lui a reproché cette initiative. Le nombre de tentatives d'exploitation a ensuite augmenté rapidement, passant de quelques centaines à plusieurs milliers, puis à des millions en quelques heures autour de la publication du correctif.

L'équipe de sécurité de PHP a cherché à limiter les conséquences en diffusant une alerte préventive. Elle demandait aux équipes informatiques de se préparer à appliquer les correctifs dont la publication était prévue le 21 octobre.

La protection ASLR a-t-elle limité les dégâts ?

Cette vaste campagne d'exploitation, apparemment menée par plusieurs groupes malveillants, explique en grande partie la panique provoquée par PHP2Shell. Selon différentes sources, des organismes de santé, des administrations et des établissements d'enseignement européens ont décidé de suspendre préventivement leurs sites en attendant les correctifs. Pourtant, malgré la gravité des vulnérabilités et la rapidité avec laquelle les attaquants s'en sont emparés, relativement peu de compromissions ont été confirmées.

L'exploitation de PHP2Shell semble en réalité beaucoup plus complexe qu'on pouvait le penser. L'une des explications pourrait être une protection appelée ASLR (Address Space Layout Randomization). Elle modifie aléatoirement l'emplacement du code et des données d'un programme en mémoire à chaque exécution, ce qui complique les attaques.

« PHP2Shell ne semble pas simple à exploiter. Je pense que l'une des raisons pour lesquelles nous avons encore observé si peu d'exploitations réussies est qu'une exécution fiable de code impose de contourner l'ASLR, une protection mémoire qui rend aléatoire la position du code », explique Yotam Perkal, directeur de la recherche en sécurité chez Pluto Security. « C'est difficile à réaliser à distance, et la plupart des démonstrations publiques qui circulent, dont beaucoup ont été créées par vibe coding, ne fonctionnent tout simplement pas de manière fiable sur les véritables systèmes. »

C'est une nouvelle rassurante, mais Perkal estime que l'ASLR ne fait probablement que donner un peu de temps supplémentaire aux équipes de sécurité. « Je ne compterais toutefois pas sur le maintien de cette situation. Les exploits vont s'améliorer, et la plupart des serveurs PHP ne sont toujours pas corrigés. Les équipes doivent donc installer les mises à jour et redémarrer leurs processus PHP dès maintenant. Mais comparée à toute l'agitation avant et après la publication des correctifs, l'exploitation réelle semble pour l'instant assez limitée. »


Adrien Bar Hiyé
Senior Editor

Quand je ne suis pas en train de plonger dans le monde fascinant de la finance et des nouvelles technologies, vous me trouverez probablement en train de parcourir le globe ou de conquérir de nouveaux mondes virtuels sur ma console de jeux.

Avec la contribution de