PHP2Shell : les failles PHP critiques à corriger d'urgence

Cette semaine, le langage qui fait tourner une bonne partie du web a reçu deux correctifs d'urgence. Les failles PHP baptisées PHP2Shell permettent à un attaquant non authentifié d'exécuter du code sur un serveur, avant même que votre application ne traite la requête.

Je suis CTO hands-on : j'architecture, je code, je structure l'équipe technique. PHP fait partie de mes stacks de travail depuis des années, de Symfony à Laravel en passant par des bases legacy que personne n'osait plus toucher. Face à ce type d'alerte, la méthode est toujours la même : inventorier, patcher, vérifier. Voici ce qu'il faut savoir, et surtout ce qu'il faut faire, que vous ayez une équipe technique ou non.

En bref : ce qu'il faut retenir sur PHP2Shell

• Quoi : deux vulnérabilités du cœur de PHP, CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Elles permettent une exécution de code à distance (RCE) sans authentification.
• Gravité : 9.2 sur 10 en CVSS v4.0 selon l'équipe sécurité de PHP. Le score de 10.0 qui a circulé avant la publication n'était pas celui de PHP. ^1
• Qui est concerné : toute installation PHP qui sert des requêtes HTTP : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. Le risque est jugé le plus élevé pour mod_php. ^2
• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. ^2
• Exploitation : des tentatives ont été observées dès le 17 octobre, quatre jours avant la publication des correctifs. ^1
• Action : mettre à jour PHP. Les mesures de configuration temporaires réduisent l'exposition mais ne protègent pas complètement. ^3

Ce que sont les failles PHP2Shell, sans jargon

La particularité de PHP2Shell, c'est l'endroit où se trouve le problème. Ce n'est pas une faille dans WordPress, dans Symfony ou dans votre code : c'est une faille dans l'interpréteur PHP lui-même, dans la partie qui lit et découpe la requête HTTP avant de la passer à votre application.

Conséquence directe : votre authentification, vos middlewares, la validation de vos formulaires ne servent à rien ici. L'attaque se produit avant que la première ligne de votre code ne s'exécute. ^3

CVE-2026-109618 : une erreur mémoire mal nettoyée

Quand PHP manque de mémoire en plein milieu de la construction d'un tableau (par exemple en lisant les champs d'un formulaire), il interrompt l'opération. Le problème : un compteur interne a déjà été incrémenté, et le code de nettoyage de fin de requête considère comme valide un élément qui n'a jamais été initialisé. Un attaquant qui provoque volontairement ce manque de mémoire avec une requête POST bien construite peut transformer ce nettoyage en exécution de code. ^3

CVE-2026-109619 : un état partagé entre deux requêtes

Un même processus PHP (un worker FPM ou un processus Apache) traite plusieurs requêtes à la suite. La seconde faille vient d'un état global qui pointe encore vers la mémoire d'une requête précédente, déjà libérée. Une requête suivante peut alors lire ou réutiliser cette mémoire (ce qu'on appelle un use-after-free). Le chemin confirmé passe par le suivi de progression des uploads (session.upload_progress), activé par défaut, et qui fonctionne même si votre application n'appelle jamais session_start(). ^3

Datadog note un point qui mérite l'attention de toute équipe technique : le schéma de fond, une erreur mémoire qui interrompt une opération et un nettoyage qui fait confiance à un état incomplet, n'est pas totalement éliminé par le correctif. Il faut s'attendre à voir d'autres bugs de la même famille. ^3

Chronologie : une semaine très courte

La fenêtre entre la publication du correctif et l'exploitation de masse s'est réduite à quasiment zéro. Pour une startup, ça change la question : il ne s'agit plus de savoir si vous patcherez dans le mois, mais si vous savez patcher dans la journée.

Quelles versions de PHP sont vulnérables ?

Source : avis PHP repris par Tenable. Le code vulnérable le plus ancien remonte à PHP 5.4.0. ^1

Attention à un piège classique : les distributions Linux rétroportent les correctifs sans changer le numéro de version. Sur Ubuntu 24.04, par exemple, le paquet corrigé porte le numéro 8.3.6-0ubuntu0.24.04.13 : la version PHP reste 8.3.6, seul le suffixe Ubuntu change. ^5 Un php -v qui renvoie une « vieille » version ne veut donc pas forcément dire que vous êtes vulnérable, et l'inverse est vrai aussi. Vérifiez le numéro du paquet et le changelog de votre distribution.

Et WordPress, Drupal, Magento, Symfony, Laravel ?

La faille est dans PHP, pas dans le framework. Toute application qui tourne sur une version vulnérable de PHP exposée en HTTP est concernée, quel que soit le framework. Les chercheurs de Calif indiquent avoir confirmé une exécution de code sans authentification sur des versions précises de WordPress, Drupal, Joomla et Magento. ^1 Pour Symfony et Laravel, je n'ai pas vu de démonstration publique spécifique à ce jour, mais il n'y a aucune raison technique de les considérer comme protégés : mettre à jour Symfony ou Laravel ne corrige rien, c'est le runtime PHP qu'il faut mettre à jour.

Le plan d'action que j'applique

Voici, dans l'ordre, la méthode que j'applique face à une faille de ce type. Comptez une demi-journée pour une startup avec une infrastructure simple, davantage si personne ne sait exactement où tourne PHP.

1. Inventorier tous les endroits où PHP sert du HTTP

C'est l'étape que tout le monde sous-estime. Il ne suffit pas de regarder le serveur principal :

• les serveurs et VM, en vérifiant le binaire réellement utilisé par le serveur web (php-fpm -v ou une page phpinfo() temporaire), qui n'est pas toujours celui de la ligne de commande ;
• les images Docker, y compris celles des workers, des back-offices et des outils internes ;
• les hébergements mutualisés et les PaaS, où c'est l'hébergeur qui patche, mais où il faut vérifier qu'il l'a fait ;
• les « vieux » sites : le site vitrine de 2019, le WordPress marketing, l'outil d'administration que personne n'a touché depuis deux ans.

Datadog insiste sur ce point : les conteneurs et les applications qui embarquent leur propre interpréteur doivent être inventoriés séparément. ^3

2. Mettre à jour, puis redémarrer réellement les workers

Sur un serveur classique, une mise à jour du paquet puis un redémarrage de PHP-FPM ou d'Apache. Un reload qui garde des workers anciens en vie ne suffit pas : redémarrez.

Sur Docker, c'est là que les erreurs sont les plus fréquentes. Si votre Dockerfile commence par FROM php:8.3-fpm, il faut reconstruire l'image sans cache (docker build --pull --no-cache) et redéployer. Si vous avez figé une version précise comme php:8.3.30-fpm, vous devez modifier ce tag. Dans les deux cas, vérifiez la version dans le conteneur qui tourne en production, pas dans votre pipeline :

docker exec <conteneur> php -v

3. Si vous ne pouvez pas patcher aujourd'hui : réduire l'exposition

Pour les systèmes qui ne peuvent pas être mis à jour immédiatement, l'avis de PHP propose des mesures temporaires, à placer dans la configuration lue avant l'analyse des requêtes (le php.ini ou php_admin_value dans le pool FPM), puis redémarrage des workers : ^1 ^3

; CVE-2026-109619 (et CVE-2026-115560)
session.upload_progress.enabled = 0

; CVE-2026-109619, uniquement sur PHP 8.5
fatal_error_backtraces = 0

; CVE-2026-109618 : fixé au niveau administrateur pour que l'application ne puisse pas le surcharger
memory_limit = -1

Trois réserves importantes :

• Ce n'est pas un correctif. Datadog comme Tenable rappellent que ces réglages réduisent l'exposition sans rendre l'installation sûre. ^1 ^3
• memory_limit = -1 supprime une protection : sans limite mémoire au niveau du conteneur ou du cgroup, une requête malveillante peut épuiser la mémoire de la machine. Ajoutez une limite au niveau de l'infrastructure.
• Un WAF (Cloudflare a publié des règles, y compris pour les offres gratuites) aide, mais il ne voit pas tout ce que le moteur PHP interprète. C'est un filet, pas une solution. ^1

Pour les versions sans aucun correctif disponible, la CISA recommande de mettre hors ligne les systèmes PHP exposés, et le CERT-EU suggère de les isoler jusqu'à l'application d'un correctif. ^1 Au moins un gouvernement européen a coupé son site par précaution. ^6

4. Chercher des traces de compromission

Les tentatives ont commencé le 17 octobre. Si vos serveurs étaient exposés, patcher ne suffit pas : il faut vérifier qu'ils n'ont pas déjà été compromis. Les indicateurs publiés par Datadog sont un bon point de départ : ^3

• dans les logs PHP, des erreurs Allowed memory size ... exhausted attribuées à Unknown on line 0, signe d'un échec pendant l'initialisation de la requête ;
• dans les logs Apache, des segfaults (AH00052, signal 11) ;
• des requêtes multipart contenant des champs PHPSESSID ou PHP_SESSION_UPLOAD_PROGRESS alors que votre application ne les utilise pas, des noms de champs anormalement longs ou imbriqués, des noms de fichiers contenant <?php ;
• le signal le plus fort : un processus PHP ou serveur web qui lance sh, bash, curl ou wget.

Aucun de ces signaux n'est concluant seul, et une attaque réussie peut répondre un simple HTTP 200 sans faire planter quoi que ce soit. Si vous trouvez un processus shell lancé par PHP-FPM, traitez-le comme un incident : changez les secrets accessibles depuis ce serveur (clés d'API, accès base de données, variables d'environnement).

Ce dernier point n'est pas théorique. Unit 42 (Palo Alto Networks) décrit une intrusion où les attaquants avaient récupéré des hashs de mots de passe et des secrets MFA moins de deux heures après l'exploitation initiale, avec des signes d'un attaquant piloté par un agent IA : tâches courtes, enchaînées très vite, sorties formatées pour être lues par une machine. ^6

CVE-2026-115560 : la troisième faille, à ne pas confondre

Deux jours après les correctifs, le 23 octobre, PHP a publié un avis informatif sur une autre faille, CVE-2026-115560, elle aussi liée au suivi de progression des uploads. Elle n'est pas encore corrigée, mais son périmètre est beaucoup plus étroit : selon les comptes rendus de l'avis, elle ne concerne que les applications qui changent leur gestionnaire de sérialisation de session en php à l'exécution, via ini_set(), avant d'appeler session_start(). PHP juge le risque peu probable et la corrigera dans une version de maintenance classique. ^4

La recommandation est la même que pour CVE-2026-109619 : session.upload_progress.enabled = 0. Si vous l'avez déjà appliquée, vous n'avez rien de plus à faire. Et sauf besoin réel d'afficher la progression des uploads côté serveur, je vous conseille de garder ce réglage désactivé de façon permanente.

Ce que PHP2Shell révèle sur votre organisation technique

Au-delà du correctif, cette semaine est un test grandeur nature. Les équipes capables de réagir en une heure ont généralement trois choses en commun, et aucune n'est une question de budget.

Un inventaire à jour. Savoir où tourne PHP, dans quelle version, sur quelle image. Quand cet inventaire n'existe pas, la première journée de la crise sert à le construire, pendant que les serveurs restent exposés. C'est souvent le premier livrable d'un audit technique, et c'est la base de la méthode que je décris dans Reprendre une base de code legacy.

Des versions de runtime suivies comme de la dette. Une application qui tourne encore en PHP 8.0 ou 7.4 n'a aucun correctif officiel cette semaine. Rester sur une version en fin de vie, c'est un risque qui ne se voit pas dans la roadmap jusqu'au jour où il bloque tout. Je le traite comme n'importe quelle dette technique : avec une date et un responsable.

Un déploiement capable de livrer un correctif dans l'heure. Une image reconstruite, testée et déployée sans intervention manuelle. Si un correctif de sécurité demande une soirée de mise en production à la main, c'est le pipeline qu'il faut corriger, pas l'équipe. Et sans observabilité sur les processus lancés par vos serveurs, vous ne saurez jamais si vous avez été compromis avant le patch.

Dans une startup sans CTO, la vraie question est souvent plus simple : qui, dans l'équipe, était censé lire l'alerte du 21 octobre ? Si la réponse est « personne » ou « le prestataire, sans doute », c'est le signal qu'il manque quelqu'un pour porter la responsabilité technique. C'est exactement le rôle que je tiens en CTO à temps partiel : être celui qui lit l'alerte, sait où tourne chaque service, et patche lui-même.

FAQ : les failles PHP2Shell

Qu'est-ce que PHP2Shell ?

PHP2Shell est le nom donné à deux vulnérabilités critiques du cœur de PHP, CVE-2026-109618 et CVE-2026-109619, corrigées le 21 octobre 2026. Elles permettent à un attaquant non authentifié d'exécuter du code à distance sur un serveur qui fait tourner PHP, en envoyant une requête HTTP malveillante traitée avant le code de l'application.

Comment savoir si mon site PHP est vulnérable ?

Votre site est vulnérable s'il est servi par PHP 8.5 avant 8.5.12, 8.4 avant 8.4.27, 8.3 avant 8.3.36, 8.2 avant 8.2.35, ou par n'importe quelle version plus ancienne sans correctif de votre distribution. Vérifiez la version utilisée par le serveur web (PHP-FPM, Apache), pas seulement celle de la ligne de commande, et consultez le changelog de votre paquet, car les distributions Linux corrigent souvent sans changer le numéro de version.

Désactiver session.upload_progress suffit-il à se protéger ?

Non. Ce réglage bloque un chemin d'attaque de CVE-2026-109619 et la faille CVE-2026-115560, mais il ne protège pas contre CVE-2026-109618. L'équipe PHP et les chercheurs en sécurité sont unanimes : la seule correction complète est la mise à jour de PHP vers une version corrigée.

Mon site WordPress, Symfony ou Laravel est-il concerné ?

Oui, s'il tourne sur une version vulnérable de PHP. La faille se situe dans l'interpréteur PHP, pas dans le CMS ou le framework. Mettre à jour WordPress, Symfony ou Laravel ne corrige pas PHP2Shell : il faut mettre à jour PHP lui-même. Des chercheurs ont confirmé une exploitation sans authentification sur WordPress, Drupal, Joomla et Magento.

Mon hébergeur s'occupe-t-il de la mise à jour ?

Sur un hébergement mutualisé ou un PaaS, l'hébergeur met généralement PHP à jour pour vous, mais vérifiez-le : consultez son statut ou affichez la version via une page phpinfo() temporaire, à supprimer ensuite. Sur un serveur dédié, une VM ou des conteneurs Docker que vous gérez, la mise à jour est de votre responsabilité.

Que faire si j'utilise PHP 7.4, 8.0 ou 8.1 ?

Ces versions sont en fin de vie et ne reçoivent pas de version officielle corrigée. L'équipe PHP a publié des rétroportages minimaux en code source pour 7.4, 8.0 et 8.1, et certaines distributions ou éditeurs LTS fournissent des paquets corrigés. À défaut, isolez le service ou mettez-le hors ligne, et planifiez la migration vers une branche maintenue.

Ce que je recommande, en tant que CTO hands-on

Patchez aujourd'hui, pas lundi. Vérifiez la version réellement en production, pas celle de votre Dockerfile. Cherchez des traces d'exploitation depuis le 17 octobre. Puis, une fois la pression retombée, prenez une heure pour vous demander combien de temps il vous a fallu, et pourquoi.

La prochaine faille critique arrivera, dans PHP ou ailleurs. Ce qui fera la différence ce jour-là, ce n'est pas la stack : c'est de savoir où tourne quoi, qui est responsable, et combien de minutes il faut pour déployer un correctif.

Le même 21 octobre, deux autres correctifs critiques sont sortis : Node2Shell, la faille Brotli de Node.js, et CVE-2026-110264 sur GitLab auto-hébergé. Si votre stack inclut l'un ou l'autre, les plans d'action sont détaillés dans ces deux articles.

Sources et références

• Tenable, php2shell (CVE-2026-109618, CVE-2026-109619) : FAQ
• BleepingComputer, PHP ships emergency patches for critical PHP2Shell flaws
• Datadog Security Labs, PHP2Shell : detection, analysis, and remediation
• The Hacker News, PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches
• Unit 42 (Palo Alto Networks), Threat Brief : CVE-2026-109618, CVE-2026-109619
• Lilting, php2shell Needs the PHP Patch, Not Just session.upload_progress=0