PHP2Shell : failles critiques de PHP, mettez à jour

Le 21 octobre, l'équipe PHP a publié des versions de sécurité d'urgence pour corriger deux vulnérabilités critiques dans le cœur du langage, surnommées « PHP2Shell ». Les failles, CVE-2026-109618 et CVE-2026-109619, permettent d'exécuter du code sur le serveur via une requête web non authentifiée et touchent toutes les versions de PHP de la 5.4 à la 8.5.11. Les détails ont fuité la veille du correctif et des preuves de concept publiques existent déjà.

Contrairement à la plupart des alertes de sécurité de l'écosystème PHP, qui concernent un plugin ou une application précise, le problème se trouve ici dans l'interpréteur lui-même. Peu importe donc que le serveur fasse tourner WordPress, Drupal, Laravel ou une application maison : s'il sert des requêtes web avec une version vulnérable, il est exposé.

Ce qui s'est passé

20 octobre, le matin : une publication sur Hacker News annonce deux vulnérabilités critiques de PHP avant leur divulgation. Elle est retirée, mais les captures circulent déjà et watchTowr confirme la fuite.
20 octobre : PHP avance son calendrier et annonce une version de sécurité hors cycle pour le lendemain à 14 h UTC. L'embargo initial courait jusqu'au jeudi.
21 octobre : sortie de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Le même après-midi, Calif et Wiz Research publient les détails techniques.

Les deux failles

CVE-2026-109618 (mémoire épuisée) : si PHP manque de mémoire pendant la préparation des données d'une requête, le processus est interrompu et ces données ne sont que partiellement initialisées. Le nettoyage qui suit les traite comme valides, ce qui ouvre une voie vers l'exécution de code.
CVE-2026-109619 (état qui survit) : une partie de l'état interne d'une requête subsiste après la libération de sa mémoire. La requête suivante traitée par le même processus PHP peut utiliser cet état obsolète avant sa réinitialisation, un use-after-free classique qui permet de faire fuiter de la mémoire ou d'exécuter du code avec les droits du serveur web.

Le projet PHP leur attribue un score CVSS 4.0 de 9,2 sur 10 : attaque réseau, sans authentification ni interaction de l'utilisateur, mais de complexité élevée. Les premières fuites évoquaient un 10. Les détails divulgués pointent vers la fonction session.upload_progress, activée par défaut.

Qui est concerné

Selon PHP, toute installation qui sert des requêtes web est à risque : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP a en outre confirmé l'existence d'un exploit pour mod_php dans lequel la requête malveillante agit avant même l'exécution du code de l'application : un WordPress parfaitement à jour ne protège donc pas à lui seul.

Wiz a démontré l'exécution de code à distance contre WordPress, Drupal et Joomla, ainsi qu'une voie distincte de fuite mémoire permettant de lire des mots de passe, jetons, clés d'API ou certificats présents dans la mémoire du processus.

Le problème des anciennes versions

Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et antérieures ne sont plus maintenues et n'auront pas de nouvelle version ; le projet a seulement publié des correctifs minimaux du code source pour 7.4, 8.0 et 8.1, destinés à ceux qui compilent PHP eux-mêmes.

Les chiffres de VirusTotal donnent une idée de l'ampleur. Parmi les serveurs PHP qui affichent leur version dans les en-têtes HTTP, environ 272 000 utilisent des branches maintenues, contre quelque 758 000 encore sur des versions de la 5.4 à la 8.1 ; PHP 7.4 en compte à lui seul environ 187 000. Et comme quatre serveurs sur cinq masquent leur version, le chiffre réel est nettement plus élevé.

Nuance importante : de nombreuses distributions Linux (Debian, Ubuntu, Red Hat) appliquent les correctifs à leurs propres paquets sans changer le numéro de version. Un PHP Debian affichant 8.2.x peut être corrigé même s'il n'indique pas 8.2.35 ; il faut consulter l'avis de sécurité de la distribution.

Exploitation

Des preuves de concept publiques existent depuis avant le correctif. En fin de journée le 21 octobre, Huntress n'avait pas encore observé d'attaques réelles sur les systèmes qu'il surveille, même si d'autres sources signalent déjà des tentatives. Cloudflare a ajouté des règles d'urgence à ses jeux de règles gérés, y compris ceux de l'offre gratuite.

Que faire dès maintenant

Mettre à jour PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou vers le paquet corrigé de la distribution, puis redémarrer PHP-FPM ou le serveur web. Commencer par tout ce qui est exposé à Internet.
Vérifier les images Docker : un conteneur figé sur une étiquette PHP ne se corrige pas tout seul. Il faut reconstruire ou télécharger la nouvelle image et recréer le conteneur. Pour connaître la version : docker exec <conteneur> php -v.
Faire l'inventaire : PHP se cache dans des endroits inattendus, comme les panneaux d'hébergement (cPanel, Plesk), phpMyAdmin, Nextcloud, Roundcube ou des logiciels tiers.
Si la mise à jour n'est pas encore possible : définir session.upload_progress.enabled = Off dans php.ini et redémarrer. C'est un palliatif qui ne couvre peut-être pas tous les vecteurs, mais il réduit fortement le risque.
Retirer d'Internet ce qui ne peut pas être corrigé : les installations en PHP 8.1 ou antérieur devraient passer derrière un VPN ou un WAF le temps de la migration.
Surveiller les signes de compromission : processus PHP lançant sh, bash, curl, wget ou nc, nouveaux fichiers à la racine web, tâches cron inconnues ou nouveaux utilisateurs. Et, en raison de la fuite mémoire, envisager de renouveler les clés et mots de passe des serveurs exposés.

Ce qu'il faut surveiller ensuite

L'apparition de campagnes d'exploitation de masse, fréquentes quelques jours après un correctif accompagné d'un exploit public.
Les avis des distributions Linux et des hébergeurs mutualisés, qui concentrent des milliers de sites sur d'anciennes versions.
Les correctifs tiers pour les versions non maintenues, dont l'efficacité n'a pas encore été évaluée.

Ce n'est pas la première alerte récente dans l'écosystème PHP : relisez l'attaque de la chaîne d'approvisionnement qui a compromis plus de 700 versions de Laravel-Lang.

Conclusion : PHP2Shell fait partie de ces failles qui justifient de tout laisser tomber pour mettre à jour. Elle touche l'interpréteur et non une application, fonctionne sans mot de passe et les détails sont déjà publics. Ceux qui sont encore sur PHP 7.4 ou antérieur ont désormais la raison ultime de migrer.