Des attaquants ont tenté d'exploiter PHP2Shell quatre jours avant la divulgation publique et la mise à disposition des correctifs, selon un article de Pierluigi Paganini publié le 24 octobre sur Security Affairs, qui s'appuie sur les observations de pots de miel (honeypots) menées par des chercheurs d'AWS. Les tentatives détectées ne permettent pas d'établir que des serveurs ont été compromis avec succès.
Les deux avis officiels de PHP, publiés le 21 octobre 2026, décrivent des vulnérabilités critiques de gestion de la mémoire pouvant permettre l'exécution de code à distance. Les deux indiquent des correctifs dans PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, les versions antérieures des branches concernées étant touchées. Les conditions précises d'exploitation varient selon la vulnérabilité, l'interface serveur, l'application et la configuration.
Une exploitation réussie pourrait permettre à un attaquant d'exécuter des commandes avec les droits du compte du worker web. Paganini a évoqué des conséquences possibles, notamment le vol de données, l'installation de logiciels malveillants, la modification de sites web et l'interruption de service. Il s'agit d'impacts potentiels, et non de conséquences confirmées des tentatives signalées.
La saturation de la mémoire peut exposer un état de requête invalide
La première vulnérabilité, CVE-2026-109618, concerne l'utilisation par PHP de longjmp() pour abandonner le traitement d'une requête après une erreur de mémoire insuffisante. Si cette sortie survient alors que la mémoire de la requête n'est que partiellement initialisée, le traitement de fermeture peut rencontrer un état invalide et conduire à une exécution de code à distance.
L'avis décrit plusieurs moyens par lesquels des requêtes multipart peuvent épuiser la mémoire malgré des limites apparentes sur les données entrantes. Il s'agit notamment des requêtes sans longueur de contenu déclarée exploitable, des en-têtes non limités dans chaque partie, et des contrôles de fichiers vides qui créent des métadonnées sans être comptabilisés dans max_file_uploads. Le traitement propre à l'application de données contrôlées par l'attaquant peut également épuiser la mémoire.
L'avis de PHP indique que l'exécution de code à distance sans authentification a été validée via HTTP sur Apache mod_php, avec les limites d'entrée et de mémoire par défaut de PHP et des configurations prefork classiques avec plusieurs workers. Le traitement automatique du corps des requêtes peut déclencher le problème avant que le code de l'application ne s'exécute. Des workers supplémentaires et du trafic sans rapport peuvent augmenter le nombre de tentatives nécessaires, tandis que la fiabilité dépend de la build de PHP, des extensions, du comportement du frontend et de la disposition de l'allocateur.
Les éléments diffèrent pour d'autres types de déploiement. FPM met fin à un processus enfant lorsque le démarrage de la requête échoue, ce qui empêche ce chemin de démarrage de consommer un état invalide. L'analyse du code source indique néanmoins une sensibilité après un démarrage normal, bien qu'aucun exploit complet pour FPM n'ait été démontré. L'avis considère que FrankenPHP est probablement vulnérable à des attaques indépendantes de l'application, tandis que l'exploitation spécifique à l'application via LSAPI est jugée probable mais reste non validée.
Un état obsolète peut franchir les limites des requêtes
La seconde vulnérabilité, CVE-2026-109619, concerne un état au niveau du worker qui conserve des références à de la mémoire appartenant à une requête terminée.
L'exploitation nécessite une opération qui laisse un état propre à la requête accessible après la libération de cette mémoire, suivie d'une autre opération qui utilise cet état obsolète avant que l'initialisation normale ne le réinitialise. Dans le cas démontré, ces opérations ont lieu dans deux requêtes HTTP distinctes traitées par le même worker.
Les erreurs fatales, y compris l'épuisement de la mémoire, peuvent interrompre le nettoyage. Des diagnostics non fatals peuvent aussi repeupler un état d'erreur après qu'il a été vidé. Un tas (heap) soigneusement préparé peut transformer le use-after-free qui en résulte en exécution de code à distance. L'accessibilité dépend de l'état concerné, de l'application, des extensions et de la configuration.
Les mises à jour constituent le correctif complet
Les deux avis invitent les administrateurs à passer aux versions corrigées de leurs branches PHP respectives :
- PHP 8.2 : 8.2.35
- PHP 8.3 : 8.3.36
- PHP 8.4 : 8.4.27
- PHP 8.5 : 8.5.12
L'éditeur indique que la mise à jour est la seule mesure d'atténuation complète contre le défaut d'épuisement de la mémoire, et la seule mesure fiable contre le défaut lié à l'état obsolète.
Pour les installations qui ne peuvent pas être mises à jour, imposer de manière administrative memory_limit=-1 supprime la limite prévisible par requête utilisée par l'exploit confirmé d'épuisement de la mémoire. Chaque worker PHP doit être redémarré, et les administrateurs doivent s'assurer que les paramètres du pool, du répertoire ou de l'application ne rétablissent pas une limite finie. Il s'agit d'une protection incomplète, car des échecs d'allocation sous-jacents peuvent toujours déclencher le chemin vulnérable.
PHP met explicitement en garde contre l'utilisation de RLIMIT_AS ou RLIMIT_DATA, car ils peuvent provoquer des échecs de mmap() qui déclenchent ce chemin. Les limites de mémoire des conteneurs ou des cgroups sont également des mesures incomplètes et peuvent tuer plusieurs workers ou le processus maître.
Pour PHP 8.5, définir fatal_error_backtraces=0 de manière administrative et redémarrer chaque worker supprime le générateur utilisé dans le cas confirmé d'exécution de code à distance par état obsolète. Cette mesure ne couvre pas les autres états globaux ou ceux des extensions, et l'avis indique qu'aucune modification générique de configuration n'offre une protection complète.
L'éditeur recommande également des valeurs prudentes pour post_max_size, des limites de taille des requêtes décodées appliquées indépendamment au niveau du frontend, ainsi que des bornes sur l'imbrication des entrées, le nombre de variables, les parties multipart, les en-têtes de chaque partie et les envois de fichiers. Les applications qui n'utilisent pas de données de formulaire multipart peuvent bloquer ce type de requêtes au niveau du frontend. Ces contrôles réduisent le risque, sans remplacer les mises à jour.
Dans son rapport du 24 octobre, Paganini a invité les exploitants à examiner l'activité suspecte remontant au 17 octobre. Il a aussi évoqué la manière dont l'IA pourrait accélérer le développement d'exploits, tout en mettant en garde contre l'idée que les attaques soient automatiquement attribuables à l'IA.
