« Preuve de concept : oui. Exécution de code à distance : non. » : Ce que la communauté underground pense réellement des exploits PHP2Shell publics

Par Olivier Bilodeau, directeur de la recherche en cybersécurité

Dans les heures qui suivent PHP2Shell (CVE-2026-109618 et CVE-2026-109619) aller en publicGitHub s'est rempli de preuves de concept d'exploits, et la communauté underground s'est mise en quête d'une faille fonctionnelle. Nous avons suivi les discussions sur PHP2Shell sur Exploit.in, XSS, Dread, BreachForums et quatre autres forums underground pendant les 48 premières heures suivant la divulgation.

Le verdict des intervenants les plus techniques était sans appel : les preuves de concept publiques provoquent des plantages de PHP bien plus fréquemment que l’ouverture de shells. Ce verdict comporte toutefois une exception notable : de nombreux appareils et systèmes embarqués risquent d’être vulnérables car ils ne disposent pas de mesures de protection essentielles.

Principales conclusions du débat sur la preuve de concept de PHP2Shell

• Les utilisateurs les plus experts des forums techniques affirment que les preuves de concept publiques ne fonctionnent pas sur des cibles réelles. Les exploits nécessitent des décalages spécifiques à la version du système dans la bibliothèque libphp.so de la cible, décalages qui ne peuvent être connus à l'avance ni obtenus par force brute.
• Les utilisateurs du forum considèrent le code public comme un amas de déchets générés par l'IA. Ils qualifient les preuves de concept (PoC) de GitHub de « bricoles d'IA », de « code improvisé » et de « copier-coller ».
• L'obstacle réside dans une adresse manquante, et non dans une technique inconnue. Un rapport de test détaillé sur Exploit.in identifie l'adresse de base aléatoire du code PHP comme l'élément manquant et propose une version non-PIE comme solution de repli.
• Les tentatives infructueuses continuent de mettre les sites hors service. Une mauvaise réponse provoque le plantage du processus PHP, et les utilisateurs du forum considèrent cela comme une maigre consolation.
• Les systèmes dépourvus d'ASLR constituent le point faible de ces systèmes. Un chercheur en sécurité signale que de nombreux équipements déployés sont livrés avec PHP désactivé. Ils devraient être prioritaires pour la mise à jour des correctifs.

« Preuve de concept : oui. Exécution de code à distance : non. »

Le sujet PHP2Shell sur Exploit.in s'est ouvert sur une question simple : quelqu'un l'a-t-il ? En quelques heures, les contributeurs les plus expérimentés ont douché les espoirs des participants. Un membre, écrivant en anglais, a résumé la situation en quatre mots :

« L’IA ne prendra pas tout en charge. C’est très complexe. Preuve de concept, oui. Exécution de code à distance, non. » — Ch4se, Exploit.in

Capture d'écran effectuée Extrait d'Exploit.in : un utilisateur rejette les preuves de concept publiques de PHP2Shell.

Sur XSS, un message célébrant la divulgation par un simple « Wow, juste wow » a suscité une réponse plus cinglante :

Capture d'écran issue d'une attaque XSS montrant un utilisateur déclarant PHP2Shell « inexploitable » sur des cibles réelles

« Quel est l'intérêt, au juste ? En pratique, c'est une faille inexploitable. Pour exploiter de vraies cibles, il faut les décalages de libphp.so, qui sont uniques à chaque version et impossibles à trouver par force brute. Vous pouvez reproduire le problème sur votre propre banc d'essai, ou si vous avez déjà accès au système de fichiers de la cible. » — c0d3x, XSS (traduit du russe)

Le lendemain, un membre d'Exploit.in a confirmé : « En laboratoire, oui, ça fonctionne. […] Je n'ai encore vu personne y parvenir à grande échelle. »

« À ce stade, chaque preuve de concept est un échec en matière d'IA. »

La deuxième plainte concernait le code lui-même :

« Je reçois constamment des erreurs HEAP_LEAK_FAILED. J'ai l'impression que chaque preuve de concept actuelle est un assemblage bâclé d'IA qui ne fonctionne pas correctement. » — Masamune, XSS

« GitHub regorge d'exploits de piètre qualité, codés à l'arrache et non testés. » — Flaw0, PwnForums

Capture d'écran issue d'une vulnérabilité XSS signalée par un utilisateur, indiquant que les preuves de concept publiques échouent.

L'administration d'Exploit.in rencontre le même problème. Le 19 octobre, deux jours avant la publication des correctifs, elle a indiqué que le programme de primes aux bogues du forum avait été « submergé par une quantité considérable de rapports inutiles générés par l'IA ».

La pièce manquante du puzzle PHPocalypse est une adresse.

L'explication technique la plus claire de l'absence d'exploitation massive provient d'un membre d'Exploit.in qui a tenté de rédiger une preuve de concept :

« Beaucoup de bruit pour rien. […] Tout se résume à des décalages qu'on ne peut pas connaître à l'avance. […] Toutes les failles actuelles (y compris celle de Wiz) sont conçues pour des conditions de laboratoire, où les décalages sont connus à l'avance. […] Si vous ne devinez pas le décalage du premier coup, vous ferez planter PHP. C'est loin d'être une solution miracle pour pirater n'importe quel site PHP. » — XDev, Exploit.in (traduit du russe)

Capture d'écran tirée d'Exploit.in montrant un utilisateur expliquant pourquoi les preuves de concept publiques ne fonctionnent qu'en laboratoire.

Le compte rendu le plus complet était un « mini-rapport » structuré d'astrotrain sur Exploit.in, présentant ses propres résultats de tests sur des versions patchées et non patchées. Il fait état de plantages sur 8 tentatives avec PHP 8.4.26 et d'aucun plantage avec la version 8.4.27, ainsi que d'une exécution de code à distance (RCE) fonctionnelle via un fichier de session malgré une mauvaise configuration du serveur. La conclusion de ce compte rendu explique clairement pourquoi l'exploitation massive de PHP reste rare.

« Ce qui manque : la base PIE. Nous avons le tas, mais pas le code. […] Une exécution de code à distance (RCE) « propre » avant authentification sur une configuration par défaut exploite PIE. Solution de repli : une version non-PIE. » — astrotrain, Exploit.in (traduit du russe)

Capture d'écran extraite d'Exploit.in montrant le rapport de test structuré d'un utilisateur sur PHP2Shell

En clair, l'exploit nécessite de connaître l'emplacement mémoire du code PHP. L'ASLR et les exécutables indépendants de la position (PIE) déplacent ce code vers une adresse aléatoire à chaque démarrage ; il faut donc d'abord le révéler, et c'est cette fuite que l'Astrotrain n'a pas pu résoudre. Sur une version où l'adresse reste fixe, il n'y a rien à révéler.

L'autre moitié de la formule présente une lacune similaire. Les décalages sont uniques pour chaque version, tandis qu'une version standard est identique partout où elle est exécutée. Sur Exploit.in, des membres publiaient déjà les décalages des versions LiteSpeed ​​préconfigurées. En dehors des forums, l'auteur d'un dépôt public affirme avoir exploité une chaîne d'exécution de code à distance (RCE) unique contre l'image Docker officielle php:8.4.26-apache.

Même les sceptiques admettent que cela fait planter les sites web.

« Cette faille est exploitable dans le scénario suivant : un administrateur système est licencié et décide de se venger. Deux méthodes : 1) Si le fichier libphp.so est présent, obtenir une exécution de code à distance (RCE). 2) S'il est absent, faire planter le site 😂 » — XDev, Exploit.in (traduit du russe)

Les tentatives qui n'aboutissent jamais à l'exécution de code peuvent tout de même mettre hors service un site non patché, mais chaque tentative infructueuse laisse derrière elle des processus PHP défaillants, et c'est un signal d'alarme à prendre en compte.

Un budget de 10 000 $ et une discussion pleine de rires

Tout le monde n'a pas été découragé. SafeHarbor, membre d'Exploit.in, a offert un budget de 10 1 $ à quiconque serait capable de développer un exploit fonctionnel, a déclaré préparer une liste de cibles et de méthodes de monétisation, et a promis un minimum de plus d'un million de dollars par semaine en cas de succès.

Capture d'écran tirée d'Exploit.in montrant un utilisateur proposant un budget de 10 000 $ pour une faille PHP2Shell

Le fil de discussion n'a pas été impressionné :

« Si c'était possible, ça ne coûterait certainement pas 10 1 $. Et bien sûr, on gagnerait au minimum plus d'un million de dollars par semaine ! 😂 » — Source : Exploit.in (traduit du russe)

L'appétit est bien réel. Plus tôt dans la même discussion, un autre membre a qualifié PHP2Shell de « clé en or » : quiconque dispose désormais d'une exécution de code à distance fonctionnelle « exploitera Internet jusqu'à son dernier souffle, jusqu'à ce que des failles de sécurité publiques apparaissent ».

Le métro aussi est en train d'être réparé.

PHP2Shell pose également problème à l'infrastructure même du milieu underground. Le matin même où les correctifs étaient attendus, un membre d'Exploit.in a publié une demande urgente sur le forum dédié aux primes aux bogues : « Le correctif pour les vulnérabilités CVE-2026-109618 et CVE-2026-109619 doit être déployé de toute urgence. » Le support a répondu dans l'heure : « Nous y travaillons déjà. »

Capture d'écran tirée d'Exploit.in montrant un utilisateur demandant au forum de corriger PHP2Shell

Sur Dread, l'administrateur Paris a publié une mise à jour signée PGP :

« J'en ai vraiment marre de devoir redéployer le noyau presque toutes les deux semaines. […] On utilise PHP pour le noyau. […] Il y a plein d'isolation, de conteneurisation et de confinement des processus, mais on ne peut pas faire de miracles quand les dépendances sur lesquelles on compte sont elles-mêmes vulnérables. » — Paris, Dread

Capture d'écran tirée du forum Dread montrant l'administrateur annonçant un redéploiement d'urgence

Là où la barrière disparaît : les systèmes sans ASLR

Le consensus du forum se vérifie pour une configuration PHP moderne et typique compatible ASLR. Il ne s'applique pas aux systèmes où le code PHP est installé à une adresse fixe. Ces systèmes offrent aux attaquants l'élément manquant selon astrotrain, et ils ont tendance à exécuter des configurations identiques sur chaque machine déployée.

Le 22 octobre, Kevin Beaumont a signalé précisément ce type de système :

« De plus, la page d'accueil de gestion système HP (installée sur les serveurs HPE ProLiant) est livrée avec PHP… sans ASLR. Il ne semble pas y avoir de correctif pour cela ; vous pouvez l'utiliser pour naviguer sur les réseaux plats car elle vous connecte en tant que SYSTEM/root. » Kevin Beaumont, 22 octobre 2026

Plus tôt dans la même discussion, il dit la même chose à propos des machines virtuelles du pare-feu Palo Alto Networks (« ASLR désactivé, ce qui rend l'exploitation triviale ») et de Citrix NetScaler, en particulier lorsque l'interface de gestion est exposée à Internet.

Les appliances, les interfaces de gestion et les systèmes embarqués sont souvent les derniers à être mis à jour, et ils sont rarement surveillés comme les serveurs web. Pour PHP2Shell, c'est là que le principe « preuve de concept oui, exécution de code à distance non » cesse d'être valable.

Que peuvent faire les défenseurs maintenant

• Commencez par installer les correctifs sur les équipements et les systèmes embarqués. Réalisez un inventaire complet des composants PHP livrés : interfaces de gestion de serveurs, pare-feu, plans de gestion ADC, NAS, systèmes de gestion de bâtiments. Appliquez les mises à jour du fournisseur. En l’absence de mises à jour, déconnectez l’interface de gestion d’Internet et isolez le périphérique.
• Ensuite, corrigez tous les autres problèmes. Passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Commencez par utiliser les images Docker et les paquets de distribution officiels, dont la configuration est identique partout, puis redémarrez les processus PHP.
• Ne vous fiez pas à session.upload_progress.enabled=Off. La communauté PHP et les utilisateurs des forums s'accordent à dire que cela ne bloque pas les deux vulnérabilités.
• Limitez les actions que PHP peut exécuter. Recommandations pour une défense en profondeur : profils AppArmor ou SELinux empêchant PHP d’exécuter des commandes.
• Alerte concernant les plantages des processus PHP. Des séries d'erreurs de segmentation ou d'abandons provenant des processus Apache, PHP-FPM ou LiteSpeed ​​sont les signes les plus probables d'une tentative infructueuse.
• Recherchez les chaînes de caractères par défaut des PoC. Un PoC publié sur Exploit.in envoie les agents utilisateurs php2shell-109618 / php2shell-109619 et les limites multipart B7kQpoc618 / B7kQpoc619, sauf modification. VulnCheck a publié l'agent utilisateur du scanner php2shell-scan/109618.

En clôture

Ce n'est pas terminé, comme l'a dit un jour Bruce Schneier :

Les attaques s'améliorent toujours, elles ne s'aggravent jamais.

Les preuves de concept s'amélioreront. En quelques heures/jours, mais il semble que nous ayons évité que tout Internet ne prenne feu, cette fois-ci.

Pour en savoir plus sur la proportion d'Internet qui utilise encore du PHP non pris en charge, consultez notre Analyse de l'exposition PHP2Shell.

Références

• Kevin Beaumont, fil de discussion Mastodon sur PHP2Shell et les appareils désactivés ASLR, 20-22 octobre 2026 : https://cyberplace.social/@GossiTheDog/117486883716972165
• PHP Group, annonce de mise à jour de sécurité, 21 octobre 2026 : https://www.php.net/index.php#2026-10-21-5
• Wiz Research, « PHP2Shell : Exécution de code à distance PHP » : https://www.wiz.io/blog/php2shell-php-rce
• 9bie, php2shell-bypass-aslr-exp (GitHub) : https://github.com/9bie/php2shell-bypass-aslr-exp