php2shell : pourquoi mettre WordPress à jour ne suffit pas

Deux vulnérabilités critiques du moteur PHP, CVE-2026-109618 et CVE-2026-109619, permettent une exécution de code à distance sans authentification dans certaines conditions. Elles sont regroupées sous le nom php2shell. Les correctifs sont disponibles depuis le 21 octobre 2026 et PHP demande une mise à jour immédiate.

Le piège, pour une entreprise, serait de chercher le problème au mauvais endroit. Un WordPress, un Drupal ou un Magento à jour peut encore fonctionner sur un runtime PHP vulnérable. À l’inverse, la présence de PHP sur un serveur ou dans un équipement ne prouve pas à elle seule que le service est exploitable. Il faut identifier la version réellement exécutée, la façon dont PHP sert les requêtes web et le correctif fourni par l’éditeur ou la distribution.

Les deux failles concernent la gestion de la mémoire lorsque PHP interrompt le traitement d’une requête, notamment après une erreur fatale ou un manque de mémoire. Dans un cas, le processus peut manipuler des données internes incomplètement initialisées pendant le nettoyage. Dans l’autre, un worker peut conserver une référence vers une zone mémoire déjà libérée et la réutiliser lors d’une requête suivante.

Une requête HTTP spécialement construite peut exploiter ces situations. L’impact confirmé par PHP est une exécution de code à distance sans authentification avec les droits du processus web. Les conséquences possibles sont donc sérieuses : accès aux fichiers lisibles par le service, modification du site, vol de secrets applicatifs, rebond vers d’autres ressources ou interruption du service. Les avis officiels évaluent les deux vulnérabilités à 9,2 sur 10 en CVSS v4.0.

Le mode d’exécution compte. L’avis technique de PHP confirme une exploitation complète par HTTP contre Apache avec mod_php. PHP-FPM, LiteSpeed et FrankenPHP restent concernés, mais les conditions et la fiabilité d’une exploitation varient selon la configuration, l’application, les extensions et le comportement du frontal web. Ce niveau de nuance est important : il ne faut ni minimiser une installation sous PHP-FPM, ni déclarer compromise toute machine qui contient un paquet PHP.

Le CERT-FR liste comme vulnérables toutes les branches 5.x, 6.x, 7.x, 8.0.x et 8.1.x, ainsi que les versions maintenues antérieures aux correctifs suivants :

PHP a aussi publié des rétroportages minimaux du code source pour les branches 7.4, 8.0 et 8.1. Ils peuvent aider certains mainteneurs, mais ne transforment pas ces anciennes branches en versions de nouveau supportées. Pour une entreprise, le bon repère reste le paquet de sécurité de sa distribution Linux, de son hébergeur, de son image de conteneur ou de l’éditeur de l’appliance.

Les CMS et les applications web s’exécutent au-dessus de PHP. Ici, le défaut se trouve sous l’application, dans le runtime. Mettre à jour le cœur de WordPress, les extensions ou le thème reste indispensable pour corriger leurs propres vulnérabilités, mais cela ne remplace pas la mise à jour de PHP.

Le même raisonnement vaut pour un conteneur. Reconstruire l’application sans rafraîchir son image de base peut conserver une version vulnérable. À l’inverse, tirer une image corrigée sans redéployer les workloads laisse les anciens workers en mémoire. Sur un hébergement mutualisé ou une plateforme managée, la version affichée dans un panneau d’administration ne suffit pas toujours : il faut obtenir la confirmation du correctif appliqué au runtime qui traite réellement les requêtes.

Enfin, PHP ne se limite pas aux sites vitrines. Le NCSC néerlandais rappelle qu’il peut être intégré à des interfaces d’administration, des appliances et des équipements réseau. Sa liste de produits est encore en construction : elle sert de piste d’inventaire, pas de preuve définitive de vulnérabilité pour chaque référence.

Cloudflare indique avoir activé automatiquement plusieurs protections pour les clients utilisant son WAF, y compris sur l’offre gratuite, dès le 21 octobre à 03 h 02 UTC. L’entreprise dit aussi avoir observé du trafic d’attaque et des variations de charges utiles destinées à contourner les règles.

Cette protection est utile. Elle ajoute une couche entre Internet et le serveur et peut bloquer une partie des tentatives pendant la mise à jour. Cloudflare a même introduit pour ce cas une détection qui rapproche les signaux de la requête et de la réponse du serveur.

Mais un WAF n’est ni un correctif, ni une preuve d’absence de compromission. Il peut être contourné, mal configuré, absent sur un sous-domaine oublié ou évité par un accès direct à l’origine. Cloudflare demande explicitement de mettre PHP à jour malgré ses règles. La bonne stratégie est donc WAF actif et vérifié, puis correctif du runtime sans attendre.

Commencez par les sites et services exposés à Internet, puis élargissez aux interfaces internes, outils métiers, conteneurs, machines virtuelles, hébergements managés et appliances. Pour chaque actif, relevez :

La commande php -v n’est qu’un indice. Un serveur peut avoir plusieurs versions installées, et la CLI peut différer du pool PHP-FPM relié au site. Il faut contrôler le processus ou le conteneur actif, sa configuration et la réponse du service concerné, sans exposer publiquement une page phpinfo().

Mettez les branches maintenues au niveau corrigé ou à une version ultérieure fournie par votre canal habituel. Pour une branche ancienne, appliquez uniquement un paquet rétroporté explicitement annoncé comme corrigé par un fournisseur de confiance, ou migrez vers une branche maintenue.

Lorsqu’un équipement embarque PHP sans permettre sa mise à jour séparée, attendez l’avis du constructeur et appliquez son firmware. Si aucun correctif n’est disponible, retirez l’interface d’Internet, limitez son accès aux réseaux et comptes strictement nécessaires, et surveillez l’avis éditeur.

Installer un paquet ne suffit pas si d’anciens processus continuent d’exécuter le binaire chargé en mémoire. Redémarrez les services concernés, renouvelez tous les workers PHP-FPM et redéployez les conteneurs à partir d’une image corrigée. Dans un environnement orchestré, vérifiez que toutes les répliques utilisent le nouvel artefact et qu’aucun ancien nœud ne reçoit encore du trafic.

Après le changement, relevez de nouveau la version au niveau du runtime qui traite chaque site. Contrôlez aussi la santé applicative : authentification, formulaires, téléversements, traitements asynchrones et tâches planifiées. Une mise à jour réussie sur un serveur d’administration ne prouve pas que tous les frontaux, pools et conteneurs ont été remplacés.

Conservez une preuve simple : actif, ancienne version, version corrigée, date, personne ayant validé et résultat du contrôle fonctionnel. Cette trace évite de confondre « paquet téléchargé » et « exposition réellement supprimée ».

Laissez le WAF actif, vérifiez que le trafic ne contourne pas le proxy et limitez les téléversements aux routes qui en ont besoin. Surveillez les requêtes multipart/form-data, les erreurs mémoire, les arrêts répétés de workers et les réponses inhabituelles. Ces mesures réduisent l’exposition et aident à repérer une activité anormale ; elles ne remplacent pas la mise à jour.

Cloudflare a observé des tentatives, mais une règle WAF déclenchée ne prouve pas que votre serveur a été compromis. Examinez les journaux du frontal, du WAF, de PHP et du système autour des événements suspects. Recherchez notamment des créations ou modifications inattendues de fichiers, des processus enfants inhabituels lancés par le compte web, des connexions sortantes nouvelles, des crashes répétés et des changements de configuration non expliqués.

Si plusieurs signaux concordent, isolez l’actif, préservez les journaux et artefacts utiles, puis traitez l’événement comme un incident. La rotation des secrets doit intervenir depuis un environnement sain, après avoir compris ce qui a pu être exposé.

PHP précise qu’aucune mesure de contournement n’est complète. Le CERT-FR relaie néanmoins deux pistes provisoires, sans les qualifier : désactiver session.upload_progress avant le traitement des requêtes et bloquer les requêtes multipart lorsqu’elles ne sont pas nécessaires. Le blocage global de multipart/form-data casse les formulaires avec pièces jointes et de nombreux téléversements ; il doit donc être testé et appliqué avec discernement.

La désactivation de session.upload_progress ne couvre que certains chemins d’exploitation. Elle doit être appliquée dans php.ini, dans la configuration du pool PHP-FPM ou du serveur, puis suivie d’un redémarrage complet des workers. Une modification faite avec ini_set() dans l’application ou dans un fichier lu trop tard ne protège pas le traitement initial de la requête.

L’avis PHP décrit d’autres réglages temporaires selon les versions et les modes d’exécution. Ils sont techniques, comportent des effets de bord et ne doivent pas devenir une excuse pour repousser le correctif. Si vous devez les utiliser, documentez leur périmètre, leur durée et le test permettant de les retirer après la mise à jour.

BoucheCousue peut vous aider à inventorier les services concernés, vérifier les protections réseau et organiser la mise à jour avec vos hébergeurs ou éditeurs. Contactez-nous pour cadrer l’intervention.