PHP2Shell (CVE-2026-109618/109619) : risques et correctifs

Ce qui s'est passé

Le 21 octobre 2026, l'équipe de sécurité de PHP a publié en urgence les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Elles corrigent deux vulnérabilités réunies sous le nom de PHP2Shell : CVE-2026-109618 et CVE-2026-109619, notées toutes deux 9,2 sur 10 (CVSS 4.0). Elles permettent d'exécuter du code à distance sur un serveur, sans compte ni mot de passe.

La particularité de PHP2Shell, c'est son emplacement. La faille n'est pas dans un plugin ou dans une application, mais dans le moteur PHP lui-même, dans la façon dont il gère la mémoire d'une requête. Or PHP fait tourner près de sept sites sur dix parmi ceux dont le langage serveur est connu (W3Techs) : WordPress, Drupal, Joomla, Laravel, Symfony, mais aussi les panneaux d'hébergement cPanel et Plesk et de nombreux équipements réseau.

Qui l'a découverte, et comment

Les failles ont été trouvées en août 2026 par des chercheurs de Wiz Research et de la société Calif (dont Ryan Austin, qui travaillait dans le cadre du programme « Patch the Planet » d'OpenAI). Les deux équipes les ont divulguées conjointement. Leur méthode : un audit du code source de PHP assisté par des modèles d'IA, suivi d'une démonstration d'exécution de code contre WordPress et Drupal. Le signalement à l'équipe PHP date du 24 août, et la publication coordonnée était fixée au 22 octobre.

Selon plusieurs sources, l'une des erreurs avait déjà été repérée lors d'un audit en 2024, sans être corrigée faute d'accord sur la solution et d'exploit connu. En deux mots, voici le mécanisme :

CVE-2026-109618 : PHP manque de mémoire au milieu de la préparation d'une requête et laisse des données à moitié construites. Le code de nettoyage les traite ensuite comme valides.
CVE-2026-109619 : un état interne survit à la fin d'une requête alors que la mémoire qu'il désigne a été libérée. La requête suivante, traitée par le même processus, peut s'en servir (use-after-free).

Comment elle s'est répandue

La divulgation coordonnée n'a pas tenu. Les heures sont données en UTC, soit l'heure de Conakry.

17 octobre : les pièges à attaquants d'Amazon enregistrent une première tentative d'exploitation, quatre jours avant le correctif.
20 octobre : les identifiants CVE circulent sur les réseaux sociaux et une vidéo de démonstration est publiée par erreur. Elle est retirée, mais des copies circulent déjà. PHP avance la publication au lendemain.
21 octobre : Cloudflare active des règles de pare-feu applicatif avant même la sortie du correctif. PHP publie les versions corrigées vers 14 h. L'agence américaine CISA appelle à corriger immédiatement et, à défaut, à mettre les serveurs hors ligne.
22 octobre : Cloudflare fait état de millions de tentatives, dont des essais infructueux d'installation d'une variante du botnet Mirai.
23 octobre : PHP publie un avis sur une voie d'attaque voisine, CVE-2026-115560 (progression d'upload en session), sans correctif à cette date.

Par précaution, plusieurs grandes organisations ont coupé temporairement des services : la fondation Wikimedia, Internet Archive, des sites gouvernementaux en France, aux Pays-Bas, en Finlande et au Canada. Au Japon, la Première ministre a elle-même appelé les éditeurs de sites à vérifier leurs serveurs.

Autour de la faille s'est aussi développé un écosystème opportuniste : faux sites « php2shell », cryptomonnaies parodiques, prétendus exploits vendus 150 dollars sur Telegram, et des centaines de dépôts GitHub dont beaucoup contiennent du code inopérant, voire piégé. Ne téléchargez jamais un « exploit » pour tester votre propre serveur.

Au 23 octobre, les éditeurs de sécurité divergeaient sur le nombre d'intrusions réussies, et les deux CVE ne figuraient pas encore au catalogue des vulnérabilités exploitées de la CISA. Mais plusieurs équipes, dont CrowdStrike, ont construit des exploits fonctionnels : la question n'est plus de savoir si l'attaque marche.

Les risques encourus

Prise de contrôle du serveur. L'attaquant exécute des commandes avec les droits du processus PHP, dépose une porte dérobée (webshell), installe un mineur de cryptomonnaie ou enrôle la machine dans un botnet.
Vol de secrets. Les chercheurs ont démontré la lecture de la mémoire des processus PHP sans authentification : mots de passe, jetons de session, clés d'API, contenu des fichiers .env.
Fuite de données. Tout ce que l'application peut lire devient lisible : fichiers clients, commandes, données de santé ou de paiement.
Rebond. Depuis le serveur web, l'attaquant cherche à atteindre la base de données, le réseau interne ou les comptes cloud.

Pourquoi c'est particulièrement dangereux

Aucune condition préalable côté victime. Ni authentification, ni clic d'un utilisateur.
Une attaque invisible pour l'application. Elle se joue sous WordPress ou Laravel, dans le moteur. Selon CrowdStrike, une exploitation réussie renvoie une réponse HTTP 200 normale et laisse des journaux applicatifs propres.
Apache avec mod_php en première ligne. C'est la configuration la plus exposée : une seule requête POST anonyme peut suffire, avant même l'exécution du code de l'application. PHP-FPM, php-cgi, LiteSpeed et FrankenPHP sont aussi concernés, selon la configuration et le comportement de l'application.
Un parc vieillissant. D'après Qualys, 71 % des 156 millions d'installations PHP observées chez ses clients tournent sur des branches en fin de vie (5.4 à 8.1), qui n'auront pas de version officielle corrigée.

Une nuance honnête : la note CVSS retient une complexité d'attaque élevée, et l'exploitabilité varie selon la configuration. Ce n'est pas une raison d'attendre.

Les correctifs disponibles

PHP 8.5 : version 8.5.12
PHP 8.4 : version 8.4.27
PHP 8.3 : version 8.3.36
PHP 8.2 : version 8.2.35
PHP 7.4, 8.0 et 8.1 : pas de version officielle. PHP a publié des correctifs source, repris par les distributions et les hébergeurs (cPanel, CloudLinux, dépôts d'Ondřej Surý). Sinon, migration.
PHP 7.3 et antérieurs, dont PHP 5 : aucun correctif. La migration est la seule issue.

Les distributions Linux (Debian, Ubuntu, Red Hat…) livrent souvent le correctif sous l'ancien numéro de version. Fiez-vous à leur bulletin de sécurité, pas seulement au numéro affiché.

Comment les appliquer, étape par étape

1. Inventorier. Listez tous les serveurs et conteneurs qui exécutent PHP, y compris les panneaux d'hébergement et les logiciels tiers. Attention : php -v en ligne de commande peut indiquer une autre version que celle qui sert vos pages. Vérifiez aussi php-fpm8.3 -v (adaptez le numéro) ou le panneau de votre hébergeur.
2. Mettre à jour. Sous Debian ou Ubuntu : sudo apt update && sudo apt install --only-upgrade 'php8.3*'. Sous Red Hat, Rocky ou AlmaLinux : sudo dnf upgrade 'php*'. Sous cPanel : mettez à jour les paquets EasyApache ea-php*. Avec Docker : reconstruisez vos images depuis une image de base corrigée (docker build --pull --no-cache), puis redéployez. Une image figée sur une ancienne étiquette reste vulnérable.
3. Redémarrer tous les processus PHP. Sans redémarrage, l'ancien code reste en mémoire : sudo systemctl restart php8.3-fpm et, selon le cas, sudo systemctl restart apache2 ou httpd.
4. Vérifier la version réellement servie, par exemple avec une page phpinfo() temporaire, supprimée aussitôt après contrôle.
5. Désactiver la progression d'upload en session, même après la mise à jour, tant que CVE-2026-115560 n'est pas corrigée : session.upload_progress.enabled = 0 dans le php.ini ou le pool FPM (pas via ini_set() ni .user.ini), puis redémarrage. Seules les barres de progression qui lisent la session sont affectées : testez vos formulaires d'envoi.
6. Chercher des traces de compromission depuis le 17 octobre : fichiers PHP créés ou modifiés (find /var/www -name "*.php" -newermt 2026-10-17), tâches cron inconnues, nouveaux comptes, connexions sortantes inhabituelles, erreurs « Allowed memory size » terminées par « in Unknown on line 0 », redémarrages en rafale des processus PHP.
7. En cas de doute, changer les secrets : mots de passe de base de données, clés d'API, jetons du fichier .env. Pour la clé APP_KEY de Laravel (version 11 et plus), utilisez APP_PREVIOUS_KEYS pour ne pas rendre illisibles les données déjà chiffrées.

Si vous ne pouvez pas mettre à jour tout de suite, ces mesures réduisent l'exposition sans la supprimer :

restreindre l'accès public au serveur, ou le mettre hors ligne, comme le recommandent la CISA et la NSA ;
placer le site derrière un pare-feu applicatif : Cloudflare, Imperva et d'autres ont publié des règles ;
réduire post_max_size (8M sans envoi de fichiers, 32M avec) et limiter la taille des requêtes au niveau du proxy ;
sous PHP-FPM, envisager pm.max_requests = 1 si les performances le permettent.

PHP le dit sans détour : aucune modification de configuration ne protège complètement. Seule la mise à jour corrige.

Ce que nous en retenons

Le délai se compte désormais en heures. Ces failles ont été trouvées par des chercheurs assistés d'IA. Les attaquants disposent des mêmes outils, et la première tentative a précédé le correctif de quatre jours.

Une version en fin de vie n'est pas « stable », elle est sans filet. Les sites restés sur PHP 7 n'ont reçu aucune version corrigée officielle.

La sécurité est une routine, pas un événement. Un inventaire à jour, des mises à jour automatisées, des images reconstruites régulièrement et des sauvegardes testées font la différence le jour où la faille tombe.

Vous ne savez pas quelle version de PHP fait tourner votre site, ou votre application tourne encore sur PHP 7 ? Nous auditons votre parc, appliquons les correctifs, vérifions l'absence de compromission et planifions la migration vers une version supportée. Parlez-nous de votre projet.

Sources : PHP Security Team, CISA, Wiz, Qualys, watchTowr, Recorded Future, Imperva, Brandefense (avis publiés du 20 au 24 octobre 2026).