Le projet PHP a récemment publié un bulletin de sécurité décrivant deux vulnérabilités graves, regroupées sous le nom de PHP2Shell. Elles touchent le cœur du moteur d’exécution et permettent, dans les meilleures conditions, l’exécution de code arbitraire sans authentification. Selon les estimations de l’équipe Unit42 de Palo Alto Networks, plus de 22 millions d’instances pourraient être exposées, soit environ 70 % des sites web qui traitent des requêtes HTTP.

Une première faille d’épuisement de mémoire (CVE‑2026‑109618)

Lorsque PHP dépasse la limite de mémoire pendant l’initialisation d’une requête, le moteur interrompt le traitement à l’aide de la fonction longjmp(). Cette interruption laisse la zone mémoire dans un état corrompu : la procédure d’arrêt lit des données invalides, ouvrant la porte à l’injection de code. La vulnérabilité se déclenche facilement en manipulant les en‑têtes HTTP, la taille du corps ou les métadonnées. Les environnements mod_php d’Apache et FrankenPHP sont particulièrement concernés, car ils exécutent inconditionnellement la procédure d’arrêt avant que le code applicatif ne prenne le relais.

Le correctif officiel supprime l’usage de longjmp() dans ce contexte et le remplace par un arrêt différé, déclenché au prochain point de contrôle sécurisé de la machine virtuelle. Si la consommation dépasse un seuil supérieur, PHP effectue un arrêt d’urgence avec _exit(). Pour les administrateurs qui ne peuvent pas appliquer immédiatement le patch, la recommandation principale est de réduire la directive memory_limit à la valeur minimale (par exemple 1 Mo). Cette configuration délègue la gestion de l’épuisement de mémoire au système d’exploitation. En complément, il est conseillé d’utiliser les cgroups (memory.max) ou tout mécanisme équivalent afin de limiter la consommation globale des processus PHP.

Détournement d’états globaux (CVE‑2026‑109619)

Les workers PHP persistants conservent des structures d’état globales (sessions, objets d’extensions, etc.) qui pointent vers la mémoire allouée à la requête en cours. Lorsque la requête se termine, la mémoire est libérée mais les pointeurs restent actifs. Une nouvelle requête traitée par le même worker accède alors à ces références résiduelles avant que l’initialisation standard ne s’effectue, ce qui permet de manipuler le tas mémoire et d’injecter du code.

Deux vecteurs d’exploitation ont été confirmés : le premier exploite la directive fatal_error_backtraces, qui stocke les traces d’appels d’une erreur fatale sans les réinitialiser lors de l’arrêt. Le second utilise le suivi de la progression des téléversements (session.upload_progress). En cas d’erreur fatale après l’initialisation du suivi, PHP libère la mémoire de la requête alors que le tableau PS(id) continue de la référencer.

Le CERT‑FR recommande de désactiver le suivi de la progression des uploads en réglant session.upload_progress.enabled à 0 dans le fichier php.ini ou dans la configuration du pool FPM. Sous PHP 8.5, la désactivation de fatal_error_backtraces élimine le premier vecteur. De façon plus générale, définir display_errors à 0 empêche l’exposition des messages d’erreur aux utilisateurs distants, limitant ainsi la surface d’attaque.

Déploiement des correctifs et réponses des fournisseurs

L’équipe de sécurité du projet PHP a publié des correctifs pour toutes les versions mineures encore supportées : 8.5, 8.4, 8.3 et 8.2. Des rétroportages limités sont disponibles pour 8.1, 8.0 et 7.4. Plusieurs fournisseurs de plateformes cloud ont réagi rapidement :

  • Scalingo a désactivé le suivi des uploads et bloqué les requêtes multipartes avant de proposer les versions corrigées.
  • Heroku a appliqué les correctifs rétroportés, mais uniquement pour PHP 8.1.
  • Upsun (ex‑Platform.sh) a déployé les correctifs jusqu’à PHP 7.4 et a automatiquement redéployé les environnements concernés.
  • Netgate propose le correctif pour les passerelles pfSense via ligne de commande, en rappelant que l’interface GUI n’est accessible que sur le LAN par défaut.
  • Palo Alto Networks classe PHP2Shell comme une urgence modérée pour PAN‑OS et Panorama, recommandant l’usage d’une jump box et, en attendant les correctifs, le virtual patching pour les clients ATP Plus.

Impact sur les CMS les plus répandus

Les vulnérabilités affectent directement les systèmes de gestion de contenu les plus utilisés. Drupal, Joomla et WordPress sont tous exposés à la faille d’épuisement de mémoire (CVE‑2026‑109618). La faille de détournement d’états globaux (CVE‑2026‑109619) touche Drupal via les backtraces et WordPress via une corruption d’état partagée dans l’OPcache.

Les administrateurs de ces CMS doivent d’abord vérifier la version de PHP en cours d’utilisation et appliquer les correctifs fournis par le projet PHP. En parallèle, il est recommandé de désactiver les extensions inutiles, de réduire les limites de taille de fichiers (post_max_size, upload_max_filesize) et de mettre en place des contrôles de segmentation réseau afin d’isoler les serveurs web des interfaces d’administration.

Vers une meilleure résilience

Ces incidents rappellent que la sécurité d’une application web dépend autant du cœur du langage que du code applicatif. Même si les correctifs sont disponibles, la diversité des environnements d’exécution rend la mise à jour difficile à 100 %. Une approche combinant correctifs rapides, durcissement des configurations (memory_limit, session.upload_progress, display_errors) et isolation réseau offre la meilleure défense contre les attaques PHP2Shell. La vigilance devra rester de mise, car d’autres vecteurs d’exploitation pourraient émerger à mesure que les chercheurs explorent les limites du moteur.