Vérifier PHP2Shell : votre serveur PHP est-il vulnérable ?

Au lendemain des correctifs du 21 octobre, la question n'est plus de savoir ce qu'est PHP2Shell, que nous avons présenté dans notre article sur les deux failles critiques de PHP, mais de savoir si vos serveurs sont encore exposés. Vérifier PHP2Shell consiste à confirmer trois points : la version de PHP réellement servie par le serveur web, la présence du correctif dans le paquet installé, et l'absence de traces d'exploitation.

Ce guide fait le point au 22 octobre 2026, avec les commandes à lancer, les options pour les versions en fin de vie et les mesures provisoires recommandées par le CERT-FR.

Où en est la menace au 22 octobre ?

Les signaux sont contrastés. La société watchTowr indique observer l'exploitation des deux failles (CVE-2026-109618 et CVE-2026-109619) depuis le 21 octobre sur son réseau de pots de miel. Elle précise qu'au 22 octobre, la CISA n'avait inscrit aucune des deux CVE dans son catalogue des vulnérabilités activement exploitées (KEV), selon sa FAQ consacrée à PHP2Shell. Sophos rapporte de son côté qu'Amazon Threat Intelligence a repéré une tentative dès le 17 octobre, avant la divulgation publique.

À l'inverse, Sansec a revu son analyse le 22 octobre. Selon sa mise à jour, une attaque exige une connaissance précise du serveur visé et des conditions particulières, et les preuves de concept publiques ne fonctionnent pas contre une installation PHP par défaut : la plupart supposent déjà une faille d'inclusion de fichier local dans l'application. L'éditeur juge donc une exploitation de masse moins probable qu'annoncé le jour de la publication.

Ces deux lectures ne s'opposent pas. L'exploitation reste difficile à industrialiser, mais elle existe et progressera à mesure que les analyses du correctif circulent. La mise à jour reste la seule réponse complète.

Comment vérifier PHP2Shell sur votre serveur ?

Étape 1 : identifier la version de PHP

Selon l'alerte CERTFR-2026-ALE-014 du CERT-FR, toutes les versions 5.x à 8.1.x sont affectées, ainsi que les branches maintenues avant les versions suivantes :

La commande php -v donne une première indication, mais elle interroge l'interpréteur en ligne de commande. Sur un serveur, plusieurs versions coexistent souvent : celle de la console n'est pas forcément celle qu'exécutent PHP-FPM ou Apache. Vérifiez la version utilisée par le pool PHP-FPM ou par le module Apache, et si vous passez par une page phpinfo() temporaire, protégez-la puis supprimez-la aussitôt.

Étape 2 : chercher le correctif dans le paquet

Le numéro de version ne suffit pas. Les distributions rétroportent souvent le correctif sans changer la version amont : un PHP 8.1 de distribution peut être corrigé, alors qu'un PHP compilé à la main reste vulnérable. Sansec recommande de rechercher la CVE dans le journal des modifications du paquet :

# Debian, Ubuntu (remplacez 8.1 par votre version)
zgrep CVE-2026-109618 /usr/share/doc/php8.1-common/changelog.Debian.gz
# RHEL, AlmaLinux, Rocky Linux
rpm -q --changelog php-common | grep CVE-2026-109618

Une fois le paquet mis à jour, redémarrez PHP-FPM ou Apache : tant que les anciens workers tournent, l'ancien code reste en mémoire. Si votre PHP est géré par un hébergeur ou un panneau d'administration (cPanel, Plesk, DirectAdmin), demandez quelle version corrigée a été déployée et vérifiez le journal des modifications proposé par le panneau.

Étape 3 : contrôler l'exposition depuis l'extérieur

Pour un premier contrôle sans accès au serveur, notre vérificateur de version PHP lit la version annoncée par le site (en-têtes X-Powered-By et Server, pages d'erreur) et indique si elle est exposée à PHP2Shell. Ce contrôle a ses limites : un site qui masque sa version ne peut pas être évalué de l'extérieur, et une version de distribution qui paraît ancienne peut être corrigée par rétroportage. Il sert à repérer les serveurs oubliés, pas à certifier qu'un hôte est sain.

Le 22 octobre, Searchlight Cyber a publié php2shell-scanner, un outil libre qui provoque volontairement la condition de manque de mémoire et observe la réaction du serveur, au lieu de se fier à la version affichée. Ses auteurs préviennent que ce test est risqué par nature : il envoie jusqu'à 29 Mio de requêtes par chemin testé et fait planter un worker, en général sans interruption de service.

Ne l'utilisez que sur vos propres serveurs, de préférence en dehors des heures de pointe. Méfiez-vous aussi des dépôts de « preuves de concept » qui circulent : Tanium rappelle que les faux exploits de CVE médiatisées contiennent souvent un logiciel malveillant.

Versions en fin de vie : quelles options ?

Le projet PHP ne publie aucune version corrigée pour PHP 8.1 et les branches antérieures. Son équipe de sécurité a toutefois diffusé des correctifs source pour les branches 7.4, 8.0 et 8.1, que plusieurs mainteneurs ont intégrés à leurs paquets, selon Sansec :

• Ubuntu 22.04 : PHP 8.1 corrigé gratuitement ; les versions 14.04 à 20.04 passent par Ubuntu Pro.
• Debian et Ubuntu : dépôt deb.sury.org d'Ondřej Surý, pour PHP 5.6, 7.4, 8.0 et 8.1.
• RHEL, AlmaLinux, Rocky Linux, Fedora : dépôt de Remi pour PHP 7.4, 8.0 et 8.1 ; AlmaLinux corrige toutes les versions qu'il distribue.
• cPanel sur CloudLinux : paquets ea-php52 à ea-php85.
• Image Docker officielle php : aucun correctif pour PHP 8.1 et les versions antérieures.

Ces paquets font gagner du temps, sans régler le problème de fond. Le CERT-FR recommande d'isoler les équipements concernés puis de migrer vers une version maintenue. Notre base de données de CVE permet de suivre les autres failles qui touchent ces branches anciennes.

Que faire si vous ne pouvez pas mettre à jour tout de suite ?

Le CERT-FR propose deux contournements, qu'il précise ne pas avoir qualifiés.

1. Désactiver la progression des envois de fichiers dans php.ini :

session.upload_progress.enabled = Off

Avec PHP-FPM, la valeur doit aussi être imposée dans chaque pool, par exemple php_admin_flag[session.upload_progress.enabled] = off, puis les workers redémarrés. Selon Tanium, un réglage par ini_set() ou dans un fichier .user.ini ne s'applique pas. Cette mesure ne réduit la surface d'attaque que pour l'une des deux failles.

2. Bloquer les requêtes dont l'en-tête Content-Type vaut multipart, au niveau du serveur web ou d'un pare-feu applicatif, ou à défaut les surveiller de près.

Sansec rappelle que tous les déclencheurs connus passent par des requêtes multipart/form-data, le format des envois de fichiers. Le blocage casse donc les téléversements, et parfois des formulaires de commande : testez vos parcours critiques après l'avoir activé, et retirez la règle une fois PHP à jour. Sansec conseille aussi d'y associer memory_limit = -1, en surveillant la consommation de mémoire du serveur pendant cette période.

Comment repérer une tentative d'exploitation ?

Une exploitation réussie de PHP2Shell aboutit à l'exécution de commandes par le serveur web. Elastic Security Labs recommande donc de surveiller le résultat plutôt que le déclencheur : un processus php-fpm, php-cgi, lsphp, apache2 ou httpd qui lance un interpréteur de commandes est suspect par nature, selon son analyse. Les signes à rechercher :

• des commandes de reconnaissance lancées par le serveur web : id, whoami, uname -a ;
• des téléchargements par curl ou wget, souvent envoyés directement à sh ou bash ;
• de nouveaux fichiers .php ou .phtml dans la racine web, signe d'un webshell ;
• des tâches cron, des services systemd ou des clés SSH ajoutés sans raison ;
• la lecture de fichiers .env ou du service de métadonnées cloud (169.254.169.254).

Tanium conseille aussi de rechercher dans les journaux récents des plantages inexpliqués de workers PHP-FPM et des requêtes multipart inhabituelles. Si vous trouvez un indice, traitez le serveur comme compromis : isolez-le, conservez les journaux et les indicateurs de compromission, puis renouvelez les secrets qu'il détenait (mots de passe de base de données, clés API, certificats).

Points clés

• Vérifier PHP2Shell, c'est contrôler la version servie au web, la présence du correctif dans le paquet et l'absence de traces d'exploitation.
• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 ; toutes les versions 5.x à 8.1.x sont affectées selon le CERT-FR.
• Au 22 octobre, watchTowr observe une exploitation des failles, mais Sansec juge une exploitation de masse moins probable et la CISA n'a inscrit aucune des deux CVE à son catalogue KEV.
• Pour les versions en fin de vie, des paquets corrigés existent (Ubuntu, deb.sury.org, Remi, CloudLinux) en attendant une migration.
• Sans correctif immédiat : session.upload_progress.enabled = Off imposé dans chaque pool, blocage ou surveillance des requêtes multipart, puis redémarrage des workers.