Post cover image

October 28, 2026

PHP2Shell : deux failles critiques, et un parc que personne ne peut corriger

La version vidéo en 1 min 30 : https://youtu.be/X6zL6jissfM

By Jonathan Mwamba

4 min read

Le 21 octobre 2026, PHP a publié des correctifs pour deux vulnérabilités d'exécution de code à distance, sans authentification, dans le moteur lui-même : CVE-2026–109618 et CVE-2026–109619, surnommées PHP2Shell. Six jours plus tard, l'exploitation est confirmée et les deux failles sont au catalogue KEV de la CISA. Pour les versions récentes, la réponse est simple : mettre à jour. Pour les serveurs qui tournent encore en PHP 7.x, 8.0 ou 8.1, il n'y a pas de version corrigée à installer. C'est cette partie du parc qui mérite qu'on s'y arrête.

Versions vulnérables, d'après le CERT-FR :

  • toutes les versions 5.x, 7.x, 8.0.x et 8.1.x ;
  • 8.2.x avant 8.2.35, 8.3.x avant 8.3.36, 8.4.x avant 8.4.27, 8.5.x avant 8.5.12.

Le plus ancien code concerné remonte à PHP 5.4.0.

Les deux failles touchent le cœur de PHP, pas une extension ni un framework. Votre code peut être propre : si le moteur est vulnérable, l'application l'est aussi. Magento, WooCommerce, Shopware, un intranet maison ou un CMS oublié sont exposés de la même façon.

Toute installation qui sert des requêtes web est concernée : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed. PHP juge le risque le plus élevé avec mod_php, où une requête non authentifiée suffit, avant même que le code applicatif ne s'exécute.

Des chercheurs ont aussi montré une fuite de la mémoire des workers, qui peut exposer mots de passe, jetons et clés d'API.

Confirmé :

  • des tentatives dès le 17 octobre, puis une exploitation que Amazon qualifie de large ;
  • une exploitation réussie sur des honeypots en PHP 8.4.26 avec mod_php, rapportée le 24 octobre (CVE-2026–109618) ;
  • des exploits fonctionnels confirmés par Trail of Bits le 26 octobre ;
  • l'inscription au catalogue KEV de la CISA le 26 octobre.

À prendre avec prudence :

  • beaucoup de " preuves de concept " publiques circulent. La PHP Foundation n'en avait validé aucune au moment de l'analyse de Tenable, et certaines contiennent des logiciels malveillants. Ne lancez pas un exploit trouvé sur GitHub pour " tester " votre serveur.
  • CVE-2026–115560, la troisième faille, n'est exploitable selon PHP que dans une combinaison rare de configuration et de code : une application qui passe session.serialize_handler à php avec ini_set() juste avant session_start(). Elle n'a pas encore de correctif et reste présente dans les versions du 21 octobre. PHP la corrigera dans sa prochaine version régulière.

C'est le cœur du sujet. PHP 8.1 et les versions plus anciennes ne reçoivent plus de mises à jour du projet PHP. En pratique, trois situations :

La liste illustre bien la voie des distributeurs : Plesk, par exemple, a publié dès le 21 octobre des paquets corrigés pour PHP 7.4, 8.0 et 8.1 (7.4.33, 8.0.30 et 8.1.34 reconstruits).

Compiler un backport ou installer un paquet rétroporté peut dépanner. Ce n'est pas une stratégie. La faille suivante n'aura peut-être pas de backport.

Le CERT-FR recommande d'isoler les systèmes touchés, puis de migrer vers une version maintenue. La CISA va plus loin : si vous ne pouvez pas corriger tout de suite, ou si vous êtes en PHP 8.1 ou plus ancien, mettez les systèmes hors ligne jusqu'à leur mise à jour. Les contournements publiés par PHP réduisent l'exposition, mais PHP le dit lui-même : ils " ne rendent pas l'installation sûre ".

Contre CVE-2026–109618 :

  • memory_limit=-1, imposé via php_admin_value dans le pool FPM ou la configuration Apache, en vérifiant qu'aucune application ne le redéfinit ;
  • des limites côté serveur web ou proxy : taille des requêtes, nombre de champs, nombre de parties multipart, nombre d'en-têtes ;
  • une limite mémoire par conteneur ou cgroup qui ne tue que le worker fautif. N'utilisez pas RLIMIT_AS ni RLIMIT_DATA, qui peuvent déclencher la faille.

Contre CVE-2026–109619 (et CVE-2026–115560) :

  • session.upload_progress.enabled=0 dans php.ini, le pool FPM ou la configuration serveur. Ni ini_set() ni .user.ini ne conviennent ;
  • corriger les erreurs fatales et les dépassements de délai qu'un attaquant peut provoquer.

Dans tous les cas, redémarrez tous les workers. Installer un paquet ou modifier un fichier ne change rien pour les processus déjà lancés.

Autour :

On ne protège pas ce qu'on ne voit pas. L'inventaire doit couvrir :

  • Les serveurs.php -v en CLI ne suffit pas : la version de FPM ou de mod_php peut être différente. Vérifiez php-fpm -v et la page phpinfo() d'un environnement de test.
  • Les images de conteneurs. Recherchez les images de base php:7.*, php:8.0*, php:8.1*, et scannez vos registres (Trivy, Grype ou l'outil de votre registre).

Classez ensuite : exposé et non corrigeable d'abord, interne et corrigeable ensuite.

La migration d'un PHP 7 vers 8.3 ou 8.4 n'est pas une mise à jour de paquet. C'est un projet :

Attention aussi aux versions corrigées : PHP 8.4.27 et 8.5.12 ont une régression qui fait planter certaines applications utilisant SimpleXML. Le correctif est fusionné mais pas encore publié au 26 octobre. Testez avant de déployer partout.

  1. Listez toutes vos versions de PHP : serveurs, FPM, mod_php, images de conteneurs, produits tiers.
  2. Mettez à jour tout ce qui est en 8.2 à 8.5 vers 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, puis redémarrez les workers.
  3. Pour le reste : isolez ou mettez hors ligne, appliquez les contournements, redémarrez les workers.
  4. Cherchez des traces de compromission sur les serveurs exposés depuis le 17 octobre.
  5. Ouvrez le projet de migration, avec un responsable et une date.

Une dette de version est une vulnérabilité qui attend son CVE. Les contournements achètent du temps. Ils ne le remplacent pas.

La situation évolue vite : relisez l'alerte du CERT-FR avant d'agir.

Merci de faire partie de notre communauté ! Avant de partir :

Originally published at https://cindanojonathan.substack.com on October 28, 2026.

Peace ✌️

Cindano Jonathan

Merci de faire partie de notre communauté ! Avant de partir :