PHP2Shell : deux failles critiques dans PHP, mettez à jour dès maintenant

C’est le genre d’alerte qui ne laisse pas de place à l’attentisme. Le 21 octobre 2026, l’équipe de sécurité de PHP a publié des mises à jour d’urgence pour deux failles qui touchent le cœur même du langage, celui qui fait tourner une part considérable du web. Le constat tient en une phrase : des attaques sont déjà observées, et il faut mettre à jour sans attendre.

Ce qui a changé le 21 octobre : correctifs, attaques et appel des autorités

La journée du 21 octobre a fait basculer le dossier en trois temps.

• Des correctifs publiés. L’équipe PHP a diffusé des mises à jour d’urgence pour les deux failles critiques regroupées sous le nom « PHP2Shell ».
• Des premières attaques observées. Cloudflare a détecté des tentatives d’exploitation avant même la publication des correctifs.
• Un appel des autorités. Le NCSC britannique demande de mettre à jour immédiatement ou, à défaut, de déconnecter les systèmes jusqu’à leur mise à jour.

Ce dernier point mérite qu’on s’y arrête. Il est rare qu’un centre national de cybersécurité envisage explicitement la mise hors ligne de serveurs. Le CERT-EU avait d’ailleurs formulé une recommandation du même ordre en amont de la publication des correctifs. Côté protection périmétrique, Cloudflare indique avoir déployé en amont des règles WAF contre les vecteurs d’exploitation connus, tout en précisant que les seules règles basées sur les requêtes ne suffisent pas à couvrir ces failles.

Deux failles, une même cause : une mémoire PHP laissée dans un état corrompu

Les deux vulnérabilités partagent le même point de départ. PHP peut laisser sa mémoire dans un état corrompu lorsqu’une requête se termine de manière anormale, et un attaquant peut exploiter cette situation pour exécuter du code.

CVE-2026-109618 : corruption mémoire (OOM). Cette faille découle de la gestion des erreurs de mémoire insuffisante. Elle permet une exécution de code à distance avec les droits du compte du serveur web. Selon les analyses publiées, la gestion de ces erreurs peut interrompre PHP alors que des données internes de la requête ne sont initialisées que partiellement.

CVE-2026-109619 : état global obsolète. Il s’agit ici d’un use-after-free : un état interne propre à la requête survit à la libération de la mémoire qui le soutenait. Les conséquences sont une divulgation de mémoire et une exécution de code à distance. La lecture de la mémoire des processus PHP est loin d’être anodine, puisqu’elle peut contenir des mots de passe, des jetons ou des clés d’API.

Dans les deux cas, aucune authentification n’est requise. Les deux failles sont notées 9,2/10 en CVSS v4.0.

Qui est concerné ? Toutes les installations PHP qui traitent des requêtes web

Le périmètre est vaste. Toutes les installations PHP qui traitent des requêtes web sont concernées :

• Apache avec mod_php : c’est le cas présentant le risque le plus élevé ;
• PHP-FPM ;
• php-cgi ;
• FrankenPHP et LiteSpeed.

Sur mod_php, l’attaque fonctionne par une simple requête, avant même l’exécution du code de l’application. Le CMS ou le framework utilisé n’y change donc rien : WordPress, Drupal, Joomla, Magento ou application métier, tout site PHP est exposé.

Pour mesurer l’ampleur, quelques repères issus de la presse spécialisée : PHP serait utilisé par environ 70 % du web, et Palo Alto Networks a recensé plus de 22,6 millions d’instances exposées potentiellement vulnérables.

Les versions à installer

Quatre branches maintenues disposent d’une version corrigée. Il faut viser, selon la branche en production, l’une des versions suivantes :

PHP 7.4, 8.0 et 8.1 (fin de support). Il n’existe pas de version officielle pour ces branches : la recommandation est de demander un correctif rétroporté à votre distribution ou à votre éditeur LTS. Selon plusieurs sources, l’équipe de sécurité de PHP a toutefois publié des rétroportages sources minimaux pour ces trois branches, destinés à ceux qui compilent PHP eux-mêmes ou qui n’ont pas de fournisseur LTS. Les distributions Linux et les éditeurs LTS ayant reçu les correctifs avant la publication, leurs paquets sont à vérifier en priorité.

PHP 7.3 et versions antérieures. Aucun correctif n’est disponible : la migration est la seule solution.

Un détail qui compte : le numéro de version affiché ne dit pas toujours tout. Lorsqu’un système d’exploitation rétroporte lui-même les correctifs de sécurité, une version « ancienne » peut être déjà corrigée. D’où l’importance de s’appuyer sur le paquet de sécurité de la distribution plutôt que sur la seule lecture d’un numéro.

Comment mettre à jour : les quatre réflexes

1. Installer la version corrigée. Ou le paquet de sécurité de votre distribution, de votre hébergeur ou de votre éditeur.
2. Redémarrer tous les processus PHP. Apache, PHP-FPM… Sans redémarrage, l’ancienne version reste en mémoire et la faille aussi.
3. Vérifier la version réellement chargée. Il faut contrôler la version utilisée par le serveur web, pas seulement celle qui est installée sur la machine. Les deux peuvent différer, notamment quand la ligne de commande et le serveur web s’appuient sur des installations distinctes.
4. Commencer par les serveurs exposés. La priorité va aux serveurs accessibles depuis Internet et à ceux qui fonctionnent avec mod_php.

En pratique, cela suppose de commencer par un inventaire : serveurs, conteneurs, images, hébergements gérés. Viennent ensuite la planification des mises à jour et l’analyse des journaux.

Impossible de mettre à jour tout de suite ? Les mesures temporaires

Quand une mise à jour immédiate n’est pas envisageable, plusieurs mesures peuvent réduire l’exposition le temps de procéder :

• upload_progress.enabled=0, puis redémarrage des processus PHP ;
• sous PHP 8.5 : fatal_error_backtraces=0 ;
• post_max_size bas : 8M si l’application n’accepte pas d’envoi de fichiers, 32M dans le cas contraire ;
• supprimer les paramètres PHP invalides ou obsolètes appliqués par requête ;
• mettre en place des règles WAF et bloquer les requêtes multipart inutiles.

Aucune de ces mesures ne protège complètement. Seule la mise à jour corrige réellement les failles. En dernier recours, il reste la solution la plus radicale : mettre le serveur hors ligne jusqu’à sa mise à jour. Un point de vue partagé par un développeur du noyau PHP cité par la presse, qui rappelle qu’aucun contournement ne bloquerait toutes les attaques.

Ce que les équipes IT doivent retenir

Le message tient en une ligne : mettez à jour PHP dès aujourd’hui. Les attaques ont commencé, et les serveurs exposés sur Internet ainsi que les versions obsolètes sont à traiter en premier. Pour les organisations qui s’appuient sur des CMS, des sites e-commerce ou des applications métier en PHP, c’est un chantier à ouvrir sans délai : inventaire, vérification des versions réellement chargées, redémarrage des processus, puis surveillance des journaux.

Pour les branches en fin de support, l’épisode rappelle surtout le coût d’une dette technique que l’on repousse : lorsqu’une faille de cette gravité apparaît, la migration cesse d’être un projet de confort pour devenir une urgence.