Il est complexe de généraliser l’exploitation des vulnérabilités de mémoire… mais les LLM peuvent aider.
Wiz fait la remarque dans son tour d’horizon de PHP2Shell.
La filiale de Google n’a pas découvert à elle seule cette famille de failles critiques qui touchent le cœur de PHP. Elle a toutefois pris le lead sur la narration, allant jusqu’à créer le site web php2shell.com – et vantant, au passage, la contribution « inestimable » du modèle Gemini 4 Argon.
Le projet PHP propose un point de vue plus neutre dans son bulletin de sécurité. Il ne minimise cependant pas l’urgence de la situation : toutes les installations qui servent des requêtes web sont exposées à des exécutions de code arbitraire sans authentification. Wiz parle de 70 % des sites web. L’équipe Unit42 de Palo Alto Networks, de 22,6 millions d’instances potentiellement vulnérables.
L’équipe sécurité de PHP a patché toutes les versions mineures encore prises en charge (8.5, 8.4, 8.3 et 8.2). Vu la gravité, elle fournit des rétroportages minimaux du code source pour PHP 8.1, 8.0 et 7.4.
Deux vulnérabilités, beaucoup de chemins d’attaque
1. Épuiser la mémoire (CVE-2026-109618)
Lorsqu’un dépassement de mémoire survient, un saut longjmp() interrompt le traitement. Seulement, si cette saturation se produit pendant la phase d’initialisation de la requête, PHP ne gère pas correctement la sortie anticipée : il laisse la mémoire dans un état corrompu. La procédure d’arrêt de la requête peut ensuite lire ces données invalides, ouvrant la voie à l’exécution de code arbitraire.
Plusieurs stratégies permettent de déclencher cette condition, en jouant entre autres sur les en-têtes, la longueur de contenu ou les métadonnées. Apache mod_php et FrankenPHP sont particulièrement vulnérables, car ils exécutent inconditionnellement la procédure d’arrêt, avant que le moindre code propre à l’application ne s’exécute.
La fiabilité de l’exploit dépend de la compilation de PHP, des extensions activées, du comportement du serveur front-end et de l’agencement de l’allocateur mémoire.
Le correctif supprime l’usage de longjmp() en cas de dépassement de mémoire. Il lui substitue un arrêt différé, déclenché au prochain point de contrôle sécurisé de la VM. Ou bien, si la consommation mémoire franchit un seuil plus élevé, un arrêt d’urgence immédiat utiliant _exit().
Les principales méthodes de contournement
Dans l’impossibilité d’installer une version patchée, la principale mesure consiste à définir la valeur memory_limit=1. Cela neutralise certains chemins d’attaque. En contrepartie, on délègue au système d’exploitation la gestion de l’épuisement de mémoire. Aussi, on utilisera volontiers la directive memory.max des cgroups (ou un mécanisme équivalent disponible) pour contenir la consommation de ressources et circonscrire l’impact sur la disponibilité aux seuls processus PHP. Dans tous les cas, on s’assurera qu’aucun paramétrage de pool, de répertoire ou d’application ne rétablit une limite finie de mémoire.
Cette mesure ne résout pas tout. Si mmap() ou une autre allocation sous-jacente échoue, PHP peut encore utiliser longjmp() tandis que la mémoire incomplète de la requête reste accessible.
Autre méthode d’atténuation : conserver une valeur prudente pour post_max_size. Pour les applications qui ne nécessitent pas de téléverser des fichiers, on peut régler à 8M. Sinon, à 32 M. En parallèle, on peut envisager de réduire le niveau d’imbrication (max_input_nesting_level). Et de plafonner le nombre de variables d’entrée, de parties multipart, d’en-têtes par partie et de fichiers téléversés.
2. Détourner les états globaux (CVE-2026-109619)
Dans PHP, un worker persistant conserve des structures d’état globales (sessions, objets, extensions…), mais qui pointent vers des zones mémoire allouées pour la requête en cours.
Cette mémoire est libérée sans que les états globaux soient correctement remis à zéro au préalable. Lorsque le même worker prend en charge une nouvelle requête, des opérations précoces (traitement d’entrées, application de configurations, levée d’erreurs…) s’exécutent avant l’initialisation standard. Elles accèdent alors à ces pointeurs résiduels.
En contrôlant l’agencement du tas mémoire, on peut manipuler les données réallouées à cet emplacement. Et ainsi détourner le flux d’instructions pour exécuter du code arbitraire.
Deux RCE confirmées
Il y a là aussi plusieurs stratégies de déclenchement. Au moins deux RCE ont été confirmées. L’une repose sur la directive fatal_error_backtraces. Lorsqu’elle est activée, le signalement des erreurs fatales stocke un état de traces d’appels appartenant à la requête. La réinitialisation de cet état global est systématiquement omise lors de la phase d’arrêt. Ce scénario, que le projet PHP considère comme le plus solide, est le fondement de l’exploitation confirmée sur mod_php.
L’autre chemin de RCE, validé sur mod_php et sur FPM, passe par le suivi de progression des téléversements. Le traitement peut initialiser l’état de session à un stade précoce et publier un identifiant de session dans PS(id). Si une erreur fatale survient pas après, PHP peut détruire le tas mémoire de la requête alors PS(id) continue d’y faire référence.
Les principales méthodes de contournement
Principale mesure de contournement, que le CERT-FR met d’ailleurs en avant : régler à 0 la valeur session.upload_progress.enabled. Ce en utilisant le fichier .ini, la configuration d’un pool FPM oou une configuration serveur s’appliquant avant l’analyse des requêtes. Le réglage a pour effet de désactiver le suivi de la progression des uploads.
Sous PHP 8.5 spécifiquement, on peut désactiver fatal_error_backtraces. Autre possibilité, applicable à toutes les versions : paramétrer display_errors=0 pour empêcher l’exposition des messages d’erreur PHP aux utilisateurs distants.
En aval, des correctifs diversement mis en œuvre
Le CERT néerlandais (NCSC-NL) tient une liste des logiciels tiers potentiellement concernés.
Les fournisseurs de PaaS se sont révélés particulièrement réactifs. Scalingo en fait partie. En complément à l’annonce du déploiement des versions corrigées, il revient sur sa démarche de remédiation, amorcée pour la désactivation du suivi des uploads puis le blocage des requêtes multipart pour toutes les applications.
Heroku a également fait le nécessaire, en utilisant les correctifs rétroportés… mais uniquement pour PHP 8.1. Upsun (ex-Platform.sh) est remonté jusqu’à PHP 7.4. Au contraire de Scalingo et d’Heroku, il a automatiquement redéployé les environnements concernés.
Chez Netgate, le correctif est disponible pour les passerelles de sécurité pfSense. Il faut toutefois passer par la ligne de commande pour l’appliquer. L’entreprise rappelle que par défaut, le GUI n’est accessible que sur le LAN, tandis que le portail captif (destiné aux utilisateurs externes) est désactivé.
Palo Alto Networks classe PHP2Shell comme une urgence modérée pour ses produits. Les vulnérabilités touchent toutes les versions de PAN-OS et de Panorama actuellement prises en charge. Dans le même esprit que Netgate, l’entreprise signale que le risque est plus élevé si des adresses IP externes peuvent accéder à l’interface de gestion. Aussi recommande-t-elle d’intercaler une jump box.
En attendant des versions corrigées de PAN-OS et de Panorama, Palo Alto Networks recommande des atténuations… dont le virtual patching restreint à ses clients ATP Plus.
Les CMS, cobayes de PHP2Shell
Parmi les logiciels confirmés vulnérables figurent beaucoup de CMS. À commencer par Drupal, Joomla et WordPress. C’est sur eux que Wiz a concentré sa démonstration des exploits.
La vulnérabilité CVE-2026-109618 touche les trois CMS. La CVE-2026-109619 affecte Drupal via les backtraces et WordPress à travers une corruption d’état PHP partagé (confusion de type sur OPcache).
La filiale de Google affirme avoir été la première à découvrir PHP2Shell, le 19 août et l’avoir signalée au projet PHP le 24. Parmi les quelques chercheurs externes qu’elle remercie pour leur contribution, il en est un qui avance une autre chronologie. Pas forcément en conflit, mais qui témoigne d’une convergence de travaux.
Le chercheur en question travaille chez Calif, société spécialisée dans la sécurité offensive. Il replace ses découvertes dans le contexte du programme Daybreak d’OpenAI. Et plus précisément de l’initiative Patch the Planet, qu’on l’avait invité à rejoindre fin juillet. PHP faisait alors partie des cibles d’intérêt. Il a signalé un premier bug au projet le 11 août, lui transmettant le 14 un PoC confirmé fonctionnel le lendemain.
Illustration générée par IA
The post PHP2Shell : la situation à J+1 appeared first on Silicon.fr.