Faille critique PHP : deux vulnérabilités corrigées, voici ce qu’il faut savoir

Le 21 octobre 2026 à 16h (heure de Paris), l’équipe de sécurité de PHP a publié des mises à jour d’urgence pour corriger deux failles critiques référencées CVE-2026-109618 et CVE-2026-109619. Surnommées PHP2Shell, elles peuvent permettre à un attaquant non authentifié d’exécuter du code à distance sur un serveur web. Notées 9,2 sur 10 sur l’échelle CVSS v4.0, elles concernent un langage qui fait fonctionner une très large part du web, dont WordPress, WooCommerce, Magento ou Laravel.

Cet article détaille la nature de cette faille critique PHP, les versions corrigées, les mesures à appliquer et la chronologie d’une fuite qui a bousculé le calendrier prévu.

Faille critique PHP : ce que l’on sait des CVE-2026-109618 et CVE-2026-109619

D’après l’avis de sécurité publié sur php.net, les deux vulnérabilités permettent une exécution de code à distance sans authentification. Elles touchent toutes les installations PHP qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L’équipe PHP estime le risque le plus élevé pour mod_php, avec un exploit démontré dans lequel une requête non authentifiée déclenche l’attaque avant même l’exécution du code de l’application.

CVE-2026-109618 relève d’une corruption mémoire liée à la gestion des dépassements de mémoire. Lorsque la mémoire vient à manquer, PHP peut être interrompu alors que les données internes de la requête ne sont que partiellement initialisées. Le nettoyage de la requête traite ensuite ces données invalides comme valides.

CVE-2026-109619 repose sur un état global périmé : des données internes propres à une requête survivent à la libération de leur mémoire. Une requête ultérieure traitée par le même processus peut alors utiliser cet état obsolète avant la réinitialisation normale.

Selon PHP, l’exécution complète de code à distance a été validée en HTTP contre mod_php. Pour PHP-FPM, l’analyse du code source indique une exposition, sans qu’un exploit complet ait été présenté à ce stade.

Quelles versions de PHP corriger : 8.5.12, 8.4.27, 8.3.36 et 8.2.35

Les correctifs sont livrés dans quatre versions publiées le 21 octobre 2026. Les distributions Linux et les fournisseurs de support long terme ont reçu les patchs en avance : il convient de vérifier les paquets proposés par son éditeur.

Pour les branches en fin de vie, l’équipe PHP a fourni des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, destinés aux équipes qui compilent elles-mêmes. Certaines distributions et fournisseurs de support long terme proposent aussi leurs propres correctifs : le plus sûr reste de les contacter, ou de migrer vers une version maintenue.

Ce point pèse lourd sur l’écosystème. Selon les statistiques W3Techs relayées par MacGeneration, PHP 8 ne représente que 65 % des sites qui utilisent PHP, ce qui laisse une part importante de sites sur des versions plus anciennes, plus difficiles à mettre à jour dans l’urgence.

Comment se protéger : mettre à jour PHP en priorité

L’équipe PHP est claire : la mise à jour est la seule protection complète. Voici la marche à suivre selon l’environnement.

Inventorier les installations. Serveurs, conteneurs, images d’intégration continue, machines de développement : toute installation PHP doit être recensée avec sa version, par exemple avec la commande php -v. Cette démarche s’inscrit dans une politique de cybersécurité plus large, qui vise à protéger les données de l’entreprise. Sur WordPress, la version de PHP s’affiche dans Outils, Santé du site, onglet Infos, rubrique Serveur.

Mettre à jour selon son hébergement. Sur un hébergement mutualisé, c’est l’hébergeur qui déploie le correctif : il est utile de lui demander sa date de mise à jour. Sur un serveur dédié ou un serveur privé virtuel, il faut installer la nouvelle version via les paquets de la distribution ou depuis les sources. Avec Docker, le correctif ne s’installe pas tout seul : les images doivent être reconstruites à partir d’une image de base à jour, puis redéployées. L’équipe PHP précise aussi que le dépôt communautaire rpms.remirepo.net ne proposera pas de mise à jour le jour de la publication et recommande de passer par les paquets de la distribution ou de compiler depuis les sources.

Surveiller les signes d’exploitation. Un processus php-fpm ou apache2 qui lance soudain un interpréteur de commandes ou une requête réseau sans raison apparente doit alerter.

Lire plus : Formation WordPress : du débutant au professionnel

Les mesures temporaires si la mise à jour est impossible

Ces réglages réduisent l’exposition à certains chemins d’attaque, sans rendre l’installation sûre. Ils ne remplacent pas la mise à jour.

L’équipe PHP précise que ces mesures bloquent uniquement des chemins d’attaque confirmés et que d’autres variantes restent possibles. Ces ajustements ont aussi des effets de bord : la désactivation du suivi de progression des envois de fichiers supprime les barres de progression qui s’appuient sur cette fonction.

Une fuite avant l’heure : chronologie de PHP2Shell

L’affaire s’est accélérée à cause d’une fuite. Un message publié le 20 octobre sur un forum, depuis supprimé, annonçait deux vulnérabilités d’exécution de code à distance dans PHP, avec un outil baptisé PHP2Shell. Dans la journée, la société de sécurité watchTowr a confirmé que les failles étaient réelles et déclaré avoir reproduit la première, sans publier de détails techniques.

L’embargo prévu s’est donc fissuré. La date de divulgation coordonnée initiale était fixée au 22 octobre, selon SOCRadar. Le soir même de la fuite, l’équipe PHP a publié une annonce préalable et avancé sa sortie au 21 octobre à 14h UTC.

La société néerlandaise Sansec anticipait des attaques de masse rapides après la publication, car les attaquants comparent l’ancien et le nouveau code pour reconstituer l’exploit. À la date de rédaction, nous n’avons pas trouvé de confirmation sur source d’autorité d’une exploitation massive : la vigilance reste de mise dans les jours qui viennent.

Pourquoi cette faille critique PHP concerne tout le web

PHP propulse près de sept sites sur dix dont la technologie serveur est identifiable, d’après W3Techs. Les systèmes de gestion de contenu comme WordPress, Drupal ou Joomla, les solutions de commerce en ligne comme WooCommerce, Magento ou Shopware, et de nombreux frameworks comme Laravel ou Symfony reposent sur ce langage. Une faille située dans PHP lui-même touche donc l’ensemble de ces briques, quelle que soit la qualité du code applicatif. Les conséquences d’une compromission se mesurent dans les fuites de données récentes, comme celle de Hauts-de-France ou celle de McDonald’s.

La difficulté tient à la position de la faille : elle se situe avant le code de l’application. Un pare-feu applicatif ne suffit pas forcément, car l’attaque vise le moteur PHP avant que le site n’intervienne. Le CERT-EU recommande de se tenir prêt à patcher immédiatement et, pour les applications exposées à Internet qui ne peuvent pas être mises à jour tout de suite, d’envisager de les couper du réseau public.

Le précédent régulièrement cité est Log4Shell, en décembre 2021 : une bibliothèque omniprésente, une faille d’exécution de code à distance et des centaines de milliers de tentatives d’attaque en quelques jours. La différence cette fois tient au calendrier connu à l’avance, qui a laissé aux administrateurs quelques heures pour se préparer.

Lire plus : Claude Mythos : l’IA trop puissante pour être commercialisée

Questions fréquentes sur la faille critique PHP

Qu’est-ce que PHP2Shell ?

PHP2Shell est le nom donné aux deux failles CVE-2026-109618 et CVE-2026-109619 de PHP. Elles permettent, selon l’équipe PHP, une exécution de code à distance sans authentification sur les serveurs web qui exécutent PHP. Elles sont notées 9,2 sur 10 sur l’échelle CVSS v4.0.

Quelles versions de PHP faut-il installer ?

Il faut installer PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon la branche utilisée. Ces versions ont été publiées le 21 octobre 2026. Pour PHP 8.1 et les versions antérieures, aucune version officielle n’existe : il faut passer par un fournisseur proposant des rétroportages ou migrer.

WordPress est-il concerné par cette faille ?

WordPress s’exécute avec PHP : tout site WordPress dont le serveur utilise une version vulnérable de PHP est concerné. La protection passe par la mise à jour de PHP sur le serveur, pas par celle de WordPress ou de ses extensions. Sur un hébergement mutualisé, il revient à l’hébergeur de déployer le correctif.

Comment connaître sa version de PHP ?

Sur un serveur, la commande php -v affiche la version. Sur WordPress, elle apparaît dans Outils, Santé du site, onglet Infos, rubrique Serveur. Sur un hébergement géré, le tableau de bord de l’hébergeur indique la version active.

Existe-t-il une solution si la mise à jour est impossible ?

Des mesures temporaires existent (limites de mémoire et de taille des requêtes, désactivation du suivi de progression des envois de fichiers), mais elles ne protègent que contre certains chemins d’attaque. Selon PHP, seule la mise à jour constitue une solution complète.

Qui a découvert ces failles ?

Les détails de la découverte restent à confirmer. Un chercheur, Kirill Firsov, a évoqué les failles sous le nom php2shell et watchTowr a confirmé leur existence et reproduit la première, mais la chaîne exacte de la découverte n’est pas documentée à ce stade sur une source primaire.

Ce qu’il faut retenir

Les deux failles critiques PHP CVE-2026-109618 et CVE-2026-109619 permettent une exécution de code à distance sans authentification et concernent tous les serveurs web exécutant PHP. Les correctifs sont disponibles depuis le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les versions 8.1 et antérieures ne reçoivent aucune mise à jour officielle et exigent un rétroportage par un fournisseur ou une migration. Les mesures temporaires réduisent l’exposition sans la supprimer : la priorité reste d’inventorier, de mettre à jour et de surveiller les serveurs dans les prochains jours.