Une alerte de sécurité exceptionnelle touche PHP ce 21 octobre 2026. L’équipe officielle du langage vient de publier en urgence des correctifs pour deux vulnérabilités critiques notées 9,2 sur 10. Référencées CVE-2026-109618 et CVE-2026-109619, elles peuvent permettre à un attaquant d’exécuter du code à distance sur un serveur vulnérable, sans authentification.
L’enjeu est considérable : PHP reste utilisé par environ 69 % des sites dont le langage serveur est identifié. WordPress, Drupal, Joomla, Magento, Laravel ou encore de nombreuses applications développées sur mesure reposent sur PHP.
Mise à jour : les correctifs officiels sont désormais disponibles. La mise à jour vers PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 constitue la seule correction complète des deux vulnérabilités, sauf correctif équivalent fourni par un distributeur.
PHP a publié ses correctifs en urgence ce 21 octobre
Le 20 octobre, l’équipe de sécurité de PHP avait publié une annonce inhabituelle : deux vulnérabilités critiques devaient être corrigées le 21 octobre à 14 h UTC, soit 16 h en France métropolitaine.
PHP demandait à tous les administrateurs de se préparer immédiatement à mettre leurs serveurs à jour. L’équipe précisait même qu’elle pourrait publier les correctifs plus tôt si des détails techniques devenaient publics ou si des attaques étaient détectées.
Les correctifs sont désormais disponibles pour les quatre branches maintenues de PHP. L’équipe officielle confirme que les deux vulnérabilités peuvent permettre une exécution de code à distance sans authentification et appelle les administrateurs à mettre immédiatement leurs installations à jour.
Le CERT-FR a également actualisé son bulletin d’alerte le 21 octobre pour confirmer la disponibilité des correctifs et rappeler le risque d’exécution de code arbitraire à distance.
Les détails des deux failles avaient fuité avant leur publication
Cette communication anticipée intervient dans un contexte particulièrement sensible. Des informations concernant les deux vulnérabilités ont commencé à circuler le 20 octobre, avant leur divulgation coordonnée.
Les failles, référencées CVE-2026-109618 et CVE-2026-109619, ont également reçu le surnom non officiel de « PHP2Shell ».
La société de cybersécurité watchTowr avait affirmé avoir réussi à reproduire au moins l’une des deux vulnérabilités avant la publication des correctifs, tout en refusant de dévoiler les éléments permettant de reproduire l’attaque.
La disponibilité de détails techniques avant la publication des correctifs a renforcé l’urgence pour les administrateurs, certains attaquants pouvant tenter de développer des méthodes d’exploitation avant que les serveurs ne soient protégés.
Deux vulnérabilités capables de compromettre un serveur
Les analyses officielles publiées par PHP précisent désormais la nature des deux problèmes. Il s’agit de vulnérabilités affectant la gestion de la mémoire et de certains états internes du langage.
CVE-2026-109618 : une corruption mémoire lors d’un épuisement de mémoire
La première vulnérabilité concerne la gestion des situations d’épuisement de mémoire, également appelées Out Of Memory (OOM).
Dans certaines circonstances, une erreur d’allocation mémoire peut interrompre PHP alors que des structures internes ne sont pas encore complètement initialisées. Lors du nettoyage de la requête, le moteur peut ensuite traiter ces données invalides comme si elles étaient correctes.
Les chercheurs ont notamment identifié plusieurs méthodes permettant de provoquer un épuisement de mémoire lors du traitement de requêtes multipart, utilisées notamment pour les envois de fichiers et certains formulaires.
Mais le problème ne se limite pas aux requêtes multipart. D’autres traitements accessibles à un attaquant peuvent également provoquer un épuisement de mémoire et atteindre le mécanisme vulnérable.
L’exploitation peut ainsi conduire à une corruption mémoire et, dans certaines conditions, à une exécution de code arbitraire à distance.
CVE-2026-109619 : un état interne conservé entre deux requêtes
La seconde vulnérabilité concerne la persistance incorrecte de certaines informations internes entre plusieurs requêtes traitées par un même processus PHP.
Dans certains scénarios, des références vers des données appartenant à une requête peuvent subsister après la libération de leur mémoire. Une requête suivante peut alors réutiliser ces informations devenues invalides.
Ce comportement correspond à une vulnérabilité de type Use After Free, susceptible de provoquer une corruption mémoire exploitable.
Les mécanismes impliqués peuvent notamment concerner la gestion des sessions, des erreurs, des extensions ou de paramètres de configuration. La fonctionnalité session.upload_progress constitue l’un des chemins d’exploitation identifiés, mais pas le seul.
Les deux vulnérabilités peuvent ouvrir la voie à une exécution de code arbitraire à distance. Selon les conditions d’exploitation, un attaquant pourrait exécuter ses propres instructions avec les droits du processus PHP.
Un tel accès pourrait ensuite permettre le vol de bases de données, la récupération de secrets, la modification de fichiers, l’installation d’une porte dérobée ou le déplacement vers d’autres systèmes accessibles depuis le serveur.
Le problème se situe directement dans PHP, pas dans WordPress
C’est ce qui rend cette alerte particulièrement importante. Les vulnérabilités se situent dans PHP lui-même, et non dans un plugin WordPress ou une extension Magento particulière.
Mettre à jour WordPress, Drupal ou son application ne suffit donc pas. C’est la version de PHP installée sur le serveur ou fournie par l’hébergeur qui doit être corrigée.
Le risque concerne notamment les installations utilisant PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed.
PHP considère le risque particulièrement élevé avec mod_php, pour lequel une exploitation a été démontrée avant même l’exécution du code de l’application.
Une démonstration ayant circulé avant la publication officielle évoquait différents environnements utilisant WordPress, Magento, MediaWiki, Joomla, Laravel, Drupal, phpBB et WHMCS.
Ces applications ne sont pas nécessairement vulnérables par elles-mêmes : elles utilisent simplement PHP pour fonctionner. Un site parfaitement à jour au niveau de son CMS peut donc rester exposé si son moteur PHP n’a pas reçu les correctifs.
PHP 5, PHP 7 et les anciennes versions de PHP 8 sont concernés
Le périmètre est désormais précisé. Le CERT-FR indique que les anciennes générations de PHP sont concernées, ainsi que les versions non corrigées des branches actuellement maintenues.
Les versions corrigées publiées le 21 octobre 2026 sont :
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Les installations utilisant PHP 8.1 ou une version antérieure ne bénéficient plus des mises à jour régulières du projet. Des correctifs rétroportés peuvent toutefois être proposés par certains distributeurs Linux ou fournisseurs de support étendu.
Face à la gravité de cette alerte, l’équipe de sécurité de PHP a également mis à disposition des correctifs minimaux sous forme de code source pour les branches 7.4, 8.0 et 8.1.
Pour les administrateurs concernés, la priorité reste de migrer vers une branche maintenue et corrigée, ou de vérifier explicitement auprès de leur fournisseur que les correctifs de sécurité ont bien été intégrés.
Deux mesures d’urgence pour réduire les risques avant la mise à jour
Lorsque l’installation immédiate des correctifs n’est pas possible, plusieurs mesures temporaires peuvent réduire la surface d’attaque.
Le développeur Vincent Schmalbach, qui a consacré une analyse technique aux deux vulnérabilités, attire notamment l’attention sur deux mesures complémentaires : désactiver le suivi de progression des fichiers envoyés vers PHP et bloquer les requêtes multipart directement au niveau du serveur web.
Ces deux protections sont également évoquées dans les recommandations de sécurité, notamment celles du CERT-FR. Toutefois, l’avis officiel publié par PHP confirme qu’aucune de ces mesures ne corrige complètement les deux vulnérabilités.
Il s’agit donc exclusivement de contournements provisoires, destinés à réduire certains chemins d’exploitation pendant la préparation d’une mise à jour.
1. Désactiver session.upload_progress dans PHP
La première mesure consiste à désactiver la fonctionnalité session.upload_progress, activée par défaut dans PHP et utilisée pour suivre la progression des envois de fichiers.
Cette désactivation peut être réalisée dans le fichier de configuration php.ini, avec le paramètre suivant :
session.upload_progress.enabled = OffSur les installations utilisant PHP-FPM, le paramètre peut également être imposé au niveau des pools, notamment avec la directive suivante :
php_admin_flag[session.upload_progress.enabled] = offLes processus PHP concernés doivent ensuite être redémarrés pour appliquer le changement.
L’équipe officielle de PHP précise que cette configuration doit être appliquée avant le traitement des requêtes. Une modification réalisée depuis le code de l’application avec ini_set(), ou reposant uniquement sur un fichier .user.ini avec PHP-FPM, ne constitue pas une protection suffisante.
Cette mesure ne protège cependant pas contre l’ensemble des scénarios d’exploitation. Elle bloque certains chemins d’attaque confirmés de CVE-2026-109619, mais d’autres variantes peuvent subsister. Elle ne constitue pas non plus un correctif de CVE-2026-109618.
2. Bloquer les requêtes multipart avant leur arrivée dans PHP
C’est la seconde mesure mise en avant par Vincent Schmalbach. Au lieu de laisser PHP recevoir et interpréter les requêtes contenant des formulaires multipart, il propose de les bloquer directement au niveau du serveur web, dans nginx ou Apache.
Concrètement, une règle examine l’en-tête HTTP Content-Type des requêtes entrantes. Lorsqu’il désigne un contenu multipart, le serveur peut refuser la requête avant qu’elle ne soit transmise au moteur PHP.
Cette approche vise à empêcher certains traitements vulnérables de se produire dans PHP, notamment lors de l’analyse automatique de formulaires et d’envois de fichiers.
Le développeur avait notamment alerté sur une autre voie d’exploitation évoquée dans les informations ayant fuité, qui ne serait pas couverte par la simple désactivation de session.upload_progress.
Attention : les informations officielles publiées depuis confirment que le blocage multipart ne suffit pas non plus à neutraliser tous les risques. La vulnérabilité CVE-2026-109618 peut également être déclenchée par d’autres situations d’épuisement de mémoire, indépendamment du traitement de formulaires multipart.
De même, CVE-2026-109619 peut impliquer plusieurs mécanismes internes liés aux erreurs, aux sessions et à la configuration de PHP. Le blocage des requêtes multipart ne garantit donc pas la disparition de toutes les voies d’exploitation.
Ce blocage doit être appliqué avant l’exécution de PHP, sur l’ensemble des points d’entrée concernés, et pas seulement sur les requêtes POST. Certaines configurations peuvent également traiter des contenus multipart avec d’autres méthodes HTTP.
Cette approche est également mentionnée par le CERT-FR parmi les contournements provisoires possibles. L’organisme précise toutefois que ces mesures n’ont pas été qualifiées par ses soins et qu’elles ne remplacent pas l’installation des correctifs.
Quels services cessent de fonctionner avec ce blocage ?
Le principal inconvénient de cette protection est qu’elle bloque également des fonctionnalités légitimes utilisant le format multipart.
Les envois de fichiers, l’ajout de médias dans WordPress, les formulaires comportant des pièces jointes et certaines fonctions d’importation peuvent temporairement cesser de fonctionner.
Certains formulaires peuvent également être affectés même lorsqu’ils ne contiennent aucun fichier, notamment lorsqu’ils utilisent le format multipart pour transmettre leurs données.
En revanche, la consultation des pages classiques, les requêtes JSON et les formulaires utilisant d’autres formats continuent normalement de fonctionner, sous réserve de la configuration propre à chaque application.
Les administrateurs doivent donc vérifier les conséquences de cette mesure sur leurs services. Ils doivent également s’assurer que le blocage est réellement appliqué avant PHP, y compris lorsque le serveur peut être contacté directement sans passer par un éventuel pare-feu applicatif externe.
Une fois la version corrigée installée et les processus PHP redémarrés, les règles temporaires bloquant multipart peuvent être retirées, après vérification du bon fonctionnement des services.
La faille liée à l’épuisement de mémoire nécessite des précautions supplémentaires
L’avis officiel publié le 21 octobre apporte une précision essentielle : la vulnérabilité CVE-2026-109618 ne peut pas être entièrement neutralisée en désactivant session.upload_progress ou en bloquant les requêtes multipart.
PHP recommande donc des mesures supplémentaires lorsque l’installation du correctif est momentanément impossible.
La principale mesure de configuration consiste à imposer temporairement memory_limit=-1 au niveau de l’administration du serveur. Cela supprime la limite mémoire PHP par requête dont le dépassement peut déclencher certains scénarios d’exploitation confirmés.
Mais cette configuration n’est pas sans conséquence : elle retire une protection habituelle contre la consommation excessive de mémoire par les applications. Elle ne doit donc pas être appliquée sans évaluer les risques pour la disponibilité du serveur et prévoir des limites adaptées au niveau de l’infrastructure.
Cette mesure ne garantit pas non plus une protection complète. Un échec d’allocation mémoire au niveau du système peut toujours atteindre le mécanisme vulnérable.
PHP recommande également de limiter la taille des requêtes HTTP et des données transmises. L’équipe de sécurité évoque notamment des valeurs prudentes pour post_max_size : 8 Mo lorsque les envois de fichiers ne sont pas nécessaires et 32 Mo lorsqu’ils le sont, à adapter aux besoins réels des applications.
Le contrôle doit également porter sur le nombre de champs, de fichiers, de parties multipart, d’en-têtes et sur la profondeur des structures envoyées. Les limitations placées au niveau du serveur web doivent prendre en compte les requêtes ne fournissant pas une longueur de contenu exploitable.
Enfin, PHP recommande d’utiliser des mécanismes d’isolation, notamment des conteneurs ou des cgroups, pour limiter les conséquences d’une consommation excessive de mémoire sans provoquer de nouveaux scénarios d’échec d’allocation au sein du processus vulnérable.
Ces recommandations réduisent certains risques mais ne remplacent en aucun cas la mise à jour vers une version corrigée.
Attention : aucune mesure provisoire ne remplace le correctif
Aaucun contournement temporaire ne permet de garantir complètement la sécurité d’une installation vulnérable.
La désactivation de session.upload_progress ne couvre que certains mécanismes liés à CVE-2026-109619. Le blocage multipart réduit plusieurs chemins d’attaque, mais ne neutralise pas tous les scénarios possibles. Quant aux ajustements de gestion mémoire, ils ne suppriment pas totalement le risque de corruption mémoire.
Une protection mise en place uniquement dans WordPress, Laravel ou une autre application ne constitue pas non plus une garantie suffisante. Certaines opérations vulnérables peuvent survenir avant que les mécanismes de sécurité de l’application aient la possibilité d’intervenir.
Le CERT-FR recommande d’isoler les systèmes concernés lorsqu’ils ne peuvent pas être corrigés immédiatement. Dans les situations les plus sensibles, une interruption temporaire de l’accès public peut être préférable au maintien en ligne d’un serveur exposé.
Pour les entreprises qui utilisent des versions anciennes de PHP, la disponibilité éventuelle d’un correctif rétroporté doit être vérifiée auprès du distributeur ou de l’hébergeur. Le simple affichage d’un ancien numéro de version ne permet pas toujours de savoir si un correctif de sécurité a été intégré.
Le risque d’exploitation reste particulièrement élevé
Avant la publication des correctifs, watchTowr et Huntress indiquaient ne pas avoir constaté d’exploitation massive dans leurs observations respectives. Ces constats initiaux ne permettent toutefois pas d’exclure des tentatives d’attaque ni de garantir qu’aucun serveur n’a été compromis.
La publication des correctifs crée par ailleurs un nouveau risque. Les attaquants peuvent désormais comparer les versions vulnérables et corrigées de PHP afin de comprendre les modifications apportées et de tenter de développer leurs propres méthodes d’exploitation.
La société spécialisée dans la sécurité des boutiques en ligne Sansec avait estimé que des attaques automatisées pourraient apparaître très rapidement après la publication des correctifs. Il s’agissait d’une prévision et non d’une confirmation d’attaques massives.
Les conséquences potentielles dépassent largement la compromission d’un simple site Internet. Un attaquant parvenant à exécuter du code avec les droits du processus PHP peut potentiellement accéder aux fichiers, identifiants techniques et données auxquels ce processus a accès.
Les administrateurs doivent également surveiller leurs journaux de sécurité, les processus PHP anormaux, les fichiers récemment modifiés et les éventuels nouveaux comptes administrateurs.
La publication d’un correctif ne garantit pas qu’un serveur n’a pas déjà été compromis auparavant. Lorsqu’une intrusion est suspectée, une analyse de sécurité doit être menée indépendamment de la mise à jour.
Les administrateurs de serveurs PHP doivent agir immédiatement
Les entreprises, hébergeurs et administrateurs doivent désormais vérifier la version exacte de PHP utilisée par leurs applications, y compris sur les environnements secondaires, anciens sites, interfaces d’administration et services exposés sur des sous-domaines.
Les versions corrigées étant disponibles depuis le 21 octobre 2026, l’installation de PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 doit être prioritaire, selon la branche utilisée.
Les administrateurs utilisant des distributions Linux doivent également vérifier si leur fournisseur propose un paquet corrigé ou un correctif rétroporté, dont le numéro de version peut différer de celui publié directement par PHP.
Après l’installation, il est nécessaire de redémarrer les processus concernés, notamment PHP-FPM, Apache lorsque PHP y est intégré, ainsi que les éventuels processus applicatifs persistants. Sans cela, des processus encore actifs pourraient continuer d’utiliser une ancienne version vulnérable.
Pour les serveurs qui ne peuvent pas être corrigés immédiatement, les mesures décrites par Vincent Schmalbach, en particulier le blocage temporaire des requêtes multipart avant leur traitement par PHP, peuvent réduire certains chemins d’attaque. Elles doivent toutefois être complétées par les recommandations officielles relatives à la gestion mémoire et aux limites des requêtes.
La priorité reste de déployer les correctifs, puis de vérifier que les processus actifs utilisent réellement les versions protégées et qu’aucun signe de compromission antérieure n’est présent.
Cette alerte illustre l’ampleur des conséquences possibles lorsqu’une vulnérabilité critique touche directement un composant aussi largement déployé que PHP. Deux failles permettant potentiellement une exécution de code à distance, des informations divulguées prématurément et un très grand nombre de serveurs potentiellement concernés imposent une réaction rapide des équipes techniques.
Le message de l’équipe officielle de PHP est sans ambiguïté : les protections temporaires peuvent limiter l’exposition, mais seule l’installation d’une version corrigée, ou d’un correctif de sécurité équivalent, permet de résoudre complètement ces deux vulnérabilités.
Source originale : Cyberattaque.org.
Image d’illustration : Centaur server room (2293424530).jpg — VIA Gallery from Hsintien, Taiwan — CC BY 2.0, via Wikimedia Commons.
