Cybersécurité

PHP2Shell : comprendre les failles critiques de PHP et agir maintenant

Deux failles critiques de PHP permettent de prendre le contrôle d'un serveur web sans authentification. Ce qui est touché, y compris vos pare-feu et appliances, et le plan d'action à suivre.

BigMind · 23 octobre 2026

Le 21 octobre 2026, l'équipe de PHP a publié des correctifs pour deux failles critiques, rapidement baptisées PHP2Shell (CVE-2026-109618 et CVE-2026-109619). Elles permettent à un attaquant d'exécuter du code à distance sur un serveur web, sans authentification. Notées 9,2 sur 10 par l'équipe de PHP, elles concernent un langage qui fait tourner, selon W3Techs, environ 70 % des sites web. En France, l'ANSSI recense plus de 600 000 serveurs PHP exposés sur Internet.

Par précaution, plusieurs administrations européennes ont mis hors ligne des sites publics le temps d'appliquer les correctifs, dont les sites des préfectures en France. Cet article explique ce qui se passe, ce qui est réellement concerné dans une entreprise et comment réagir de façon ordonnée.

Ce qui s'est passé

20 octobre : des détails sur deux failles critiques fuitent sur Internet avant la date prévue. L'équipe de PHP annonce une mise à jour de sécurité.
21 octobre, vers 16 h (heure de Paris) : publication des versions corrigées, un jour plus tôt que l'embargo initial. Des chercheurs publient dans la foulée leurs analyses techniques.
Les jours suivants : des millions de tentatives d'exploitation sont observées. Amazon indique avoir détecté une première tentative dès le 17 octobre, soit avant la publication des correctifs.

À la date de rédaction, plusieurs acteurs de la sécurité indiquent qu'aucune compromission réussie n'a été confirmée publiquement. Cela ne veut pas dire qu'il n'y en a pas : une tentative réussie est difficile à distinguer sans analyse du serveur. Il faut donc traiter le sujet comme une urgence.

Comprendre les deux failles

Sans entrer dans le code, les deux failles touchent la gestion de la mémoire de PHP au moment où il prépare une requête web.

CVE-2026-109618 : lorsque PHP manque de mémoire pendant la préparation des données d'une requête, certaines structures restent à moitié initialisées. Au moment du nettoyage, PHP les traite comme valides, ce qui ouvre un chemin vers l'exécution de code.
CVE-2026-109619 : un processus PHP peut conserver des références vers de la mémoire déjà libérée. Si ce même processus traite ensuite une autre requête, il peut lire cet état périmé avant qu'il soit réinitialisé. Cela peut mener à une fuite de mémoire (mots de passe, jetons, clés d'API) et à l'exécution de code.

Le code exécuté a les droits du processus web. Ce n'est pas forcément un accès administrateur, mais c'est souvent suffisant pour lire la configuration de l'application, ses identifiants de base de données et les secrets présents dans l'environnement.

Répondre à PHP2Shell en 6 étapes

Répondre à PHP2Shell en 6 étapes

Qui est concerné

Selon l'équipe de PHP, toutes les installations qui servent des requêtes web sont à risque : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque le plus élevé concerne mod_php, où l'attaque peut aboutir avant même l'exécution du code de l'application. Des démonstrations ont été faites contre WordPress, Drupal et Joomla.

Deux points sont souvent mal compris :

Mettre à jour WordPress, ses thèmes ou ses extensions ne corrige rien. La faille est dans PHP lui-même, pas dans l'application.
Le numéro de version affiché peut tromper. Les distributions Linux appliquent souvent le correctif sur une version plus ancienne sans changer le numéro principal. Il faut vérifier le paquet installé auprès de l'éditeur de la distribution, pas l'en-tête HTTP.

Les versions corrigées

PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35

Les versions 8.1 et antérieures ne sont plus maintenues. L'équipe de PHP a publié des correctifs minimaux pour les versions 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes. Pour tous les autres, la seule réponse durable est la migration vers une version maintenue.

Le risque caché : PHP dans vos équipements

PHP n'est pas seulement présent sur vos sites web. On le trouve dans de nombreux produits : interfaces d'administration de pare-feu, consoles de gestion, NAS, panneaux d'hébergement comme cPanel ou Plesk, outils de supervision et logiciels Windows. Ces PHP embarqués ne sont pas mis à jour par le système d'exploitation : il faut attendre le correctif de chaque éditeur.

Voici la situation annoncée par trois constructeurs que nous déployons souvent :

Palo Alto Networks : PAN-OS (versions 10.2, 11.1, 11.2, 12.1 et 12.2) et Panorama sont concernés, uniquement sur l'interface web d'administration et l'API XML. GlobalProtect, Prisma Access et Cloud NGFW ne sont pas touchés. Les correctifs sont annoncés entre le 26 et le 30 octobre selon les versions. En attendant, l'éditeur recommande de limiter l'accès à l'interface d'administration à des adresses internes de confiance et de vérifier les interfaces sur lesquelles un profil d'administration est activé. Des signatures de prévention (Threat ID 543004 et 97622 à 97625) sont disponibles pour les clients abonnés.
Cisco : certains produits sont confirmés vulnérables, comme Expressway et Duo Access Gateway. Cisco indique qu'ISE n'est pas concerné. D'autres produits sont encore en cours d'analyse : consultez l'avis de sécurité pour chaque équipement.
Fortinet : selon l'éditeur, FortiOS n'est pas concerné. Des signatures IPS permettent de protéger d'autres services qui utilisent un PHP vulnérable, mais elles ne remplacent pas leur mise à jour.

Retenez une règle simple : un produit indiqué « en cours d'analyse » n'est ni sûr ni vulnérable. Tant que l'éditeur n'a pas tranché, appliquez les mesures de réduction d'exposition.

Le plan d'action

1. Inventorier tout ce qui exécute PHP

Serveurs web, applications métier, intranets, outils internes, appliances, panneaux d'hébergement, postes de développeurs. Sans inventaire, vous corrigerez les serveurs connus et oublierez ceux qui posent problème.

2. Prioriser ce qui est exposé sur Internet

Les systèmes accessibles depuis Internet passent en premier, puis ceux accessibles depuis le réseau interne. Les interfaces d'administration d'équipements ne devraient jamais être joignables depuis Internet : c'est le moment de le vérifier.

3. Appliquer le correctif

Installez la version corrigée ou le paquet fourni par votre distribution. Pour un équipement, appliquez la mise à jour de l'éditeur dès qu'elle est disponible, sans remplacer vous-même le PHP embarqué.

4. Redémarrer réellement les services

Un correctif installé mais non chargé ne protège rien. Redémarrez PHP-FPM, Apache et tous les processus de travail, puis vérifiez que la nouvelle version est bien celle qui répond aux requêtes.

5. Réduire l'exposition si vous ne pouvez pas corriger tout de suite

Ces mesures réduisent le risque, mais ne rendent pas un système non corrigé sûr. L'agence américaine CISA recommande même de mettre hors ligne les systèmes qui ne peuvent pas être mis à jour rapidement.

Désactiver session.upload_progress.enabled dans le fichier php.ini, puis redémarrer tous les processus. Un réglage dans l'application ou dans un fichier .user.ini ne suffit pas.
Limiter la taille des requêtes (post_max_size, upload_max_filesize) et utiliser des limites de mémoire au niveau du conteneur ou du système.
Bloquer les requêtes multipart/form-data devant PHP si l'application n'en a pas besoin, après avoir vérifié l'impact sur les fonctions légitimes.
Activer les règles dédiées de votre pare-feu applicatif (WAF). Les principaux fournisseurs cloud en ont publié.
Restreindre l'accès aux applications internes par VPN ou par une solution d'accès Zero Trust.

Une troisième faille, CVE-2026-115560, liée au suivi d'envoi de fichiers dans les sessions, a été signalée. L'équipe de PHP la considère comme peu probable en pratique, car elle suppose une configuration particulière. La désactivation de session.upload_progress.enabled la neutralise également.

6. Chercher des traces de compromission

Corriger ne supprime pas une intrusion déjà réalisée. Amazon recommande d'analyser l'activité depuis au moins le 17 octobre. Les signaux à surveiller :

un processus PHP ou Apache (php-fpm, php-cgi, httpd, apache2) qui lance un shell ou des outils comme curl, wget, python, perl ou PowerShell ;
des commandes de reconnaissance lancées depuis le serveur web (whoami, id, uname) ;
de nouveaux fichiers dans les répertoires du site, en particulier des scripts PHP inconnus ;
de nouvelles tâches planifiées, de nouveaux comptes ou des connexions sortantes inhabituelles ;
des requêtes qui tentent de lire les variables d'environnement ou les fichiers de configuration.

La présence de requêtes malveillantes dans les journaux ne prouve pas une compromission : il faut une preuve d'exécution, de modification de fichiers ou de connexion sortante. En cas de doute, isolez le serveur, conservez les journaux et changez tous les secrets qu'il pouvait lire : mots de passe de base de données, clés d'API, certificats.

Les leçons à retenir

Le délai entre divulgation et attaque est désormais de quelques heures. Ici, les attaques ont même commencé avant le correctif. Un processus de mise à jour d'urgence doit exister avant la crise.
L'inventaire est la première mesure de sécurité. On ne protège pas ce que l'on ne connaît pas, et PHP se cache dans beaucoup d'équipements.
Les interfaces d'administration doivent rester privées. Les équipements dont l'interface n'était joignable que depuis un réseau d'administration dédié étaient beaucoup moins exposés.
La défense en profondeur fait gagner du temps. WAF, segmentation, EDR sur les serveurs et supervision permettent de tenir en attendant le correctif.

Sources

BigMind aide les entreprises à inventorier leurs serveurs et équipements, à appliquer les correctifs en urgence et à vérifier l'absence de compromission. Parlons de votre situation.