php2shell : deux vulnérabilités critiques d'exécution de code à distance sans authentification dans PHP

Résumé : Le Centre national britannique de cybersécurité (NCSC) a publié le 21 octobre un avertissement concernant un problème critique affectant PHP. Le problème recouvre en réalité deux vulnérabilités distinctes : l’une provient de l’interruption d’une requête lorsque la mémoire est insuffisante, l’autre de la réutilisation d’un état résiduel d’une requête dans la requête suivante du même processus worker. Toutes deux peuvent aller jusqu’à l’exécution de code avec le compte utilisateur du serveur web, sans authentification. PHP a publié un correctif avec les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 et indique que la mise à jour est la seule solution complète. Dans cet article, j’ai rassemblé séparément ce qui figure dans les annonces officielles, les points où les risques se concentrent, les mesures temporaires possibles si la mise à jour ne peut pas être faite immédiatement, et les affirmations non encore vérifiées.

Qu’est-ce que php2shell et qui est concerné ?

Réponse courte : php2shell est le nom commun donné à deux vulnérabilités critiques du cœur de PHP (CVE-2026-109618 et CVE-2026-109619). Toutes les installations PHP qui traitent des requêtes web sont concernées ; le risque le plus élevé concerne les serveurs utilisant Apache mod_php. La solution consiste à mettre à jour PHP vers la version 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 et à redémarrer tous les workers PHP.

Question	Réponse
Vulnérabilités	CVE-2026-109618, CVE-2026-109619
Gravité	Critique, score CVSS 4.0 de 9,2
Authentification requise ?	Non
Date de l’annonce	21 octobre 2026
Versions corrigées	8.2.35, 8.3.36, 8.4.27, 8.5.12
Installation la plus à risque	Apache `mod_php`
Solution complète	Mise à jour ; les modifications de configuration ne font que réduire le risque

Que s’est-il passé ?

Le projet PHP avait annoncé à l’avance le 20 octobre la publication imminente d’une version de sécurité critique, puis a publié le 21 octobre une version de sécurité sur quatre branches à la fois. Le même jour, le NCSC, le Centre canadien de cybersécurité et le NCSC néerlandais (NCSC-NL) ont publié des avertissements. Dans les milieux de la sécurité, les deux vulnérabilités sont désignées ensemble sous le nom de php2shell. Ce nom n’est pas utilisé dans l’annonce de PHP elle-même ; il est employé par le dépôt de suivi du NCSC-NL et par diverses sociétés de sécurité.

L’avertissement du NCSC est bref et général. Il indique que tout serveur web exécutant PHP peut être à risque et demande aux organisations de recenser et de mettre à jour leurs installations PHP, en commençant par les systèmes exposés à Internet. J’ai repris les numéros de version et les détails techniques des avis de sécurité de PHP sur GitHub et de php.net.

Que compromettent les deux vulnérabilités ?

1. CVE-2026-109618 : une requête interrompue lorsque la mémoire est insuffisante

Lorsqu’une requête dépasse la limite memory_limit, PHP l’interrompt avec longjmp(). Si l’interruption survient alors que certaines données internes de la requête sont encore à moitié préparées, la phase de fermeture de la requête peut lire ces données incomplètes comme si elles étaient valides. Il en résulte une corruption de la mémoire.

Selon l’annonce de PHP, un attaquant peut gonfler l’utilisation de la mémoire avec des données de formulaire multipart (multipart/form-data) tout en restant en apparence dans les limites. Sur Apache mod_php, avec les réglages par défaut, via HTTP et sans authentification, l’exécution de code à distance a été confirmée. L’annonce indique que, d’après l’analyse du code source, PHP-FPM, FrankenPHP et LiteSpeed pourraient également être concernés ; toutefois, aucun exploit complet n’a été démontré pour FPM.

Le correctif supprime entièrement le recours à longjmp() lorsque la mémoire est insuffisante. Il le remplace par un mécanisme en deux étapes : d’abord une limite souple qui arrête la requête à un point sûr, puis une limite stricte à un seuil plus élevé qui ferme immédiatement le processus.

2. CVE-2026-109619 : un état ancien reporté dans la requête suivante

Dans les installations fonctionnant avec des processus worker persistants comme PHP-FPM ou mod_php, le même processus sert plusieurs requêtes successives. Certains états de PHP — erreurs, sessions, objets et extensions — peuvent subsister dans le worker après la libération de la mémoire de la requête. Si la requête suivante y accède avant que l’initialisation normale ne réinitialise cet état, la mémoire libérée est réutilisée. Ce type de faille est appelé use-after-free en anglais.

L’exploitation nécessite deux étapes dans le même worker : une requête qui laisse l’état corrompu, puis une opération qui le lit ensuite. PHP a confirmé deux voies :

La combinaison de la fonctionnalité fatal_error_backtraces de PHP 8.5 avec les avertissements INI émis avant l’initialisation (confirmée sur mod_php).
La voie de la progression du chargement de session (session.upload_progress) corrompue par une insuffisance de mémoire (confirmée sur mod_php et PHP-FPM).

L’impact de la vulnérabilité est la fuite du contenu de la mémoire et l’exécution de code avec les privilèges du worker web.

3. Gravité

	CVE-2026-109618	CVE-2026-109619
Titre anglais dans l’annonce	RCE via OOM corruption	RCE via stale global state
Gravité	Critique, score CVSS 4.0 de 9,2	Critique, score CVSS 4.0 de 9,2
Authentification	Non requise	Non requise
Complexité de l’attaque	Élevée, avec condition préalable	Élevée, avec condition préalable
Environnement confirmé	Apache `mod_php`	Apache `mod_php`, PHP-FPM

Le vecteur est identique pour les deux : CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Le fait que la complexité soit « élevée » ne signifie pas que la vulnérabilité ne peut pas être exploitée ; cela indique que le succès de l’exploitation dépend des options de compilation, des extensions et de l’organisation de la mémoire.

Quelles versions sont concernées ?

Branche	Concernée	Version corrigée	Remarque
8.5	avant 8.5.12	8.5.12
8.4	avant 8.4.27	8.4.27
8.3	avant 8.3.36	8.3.36
8.2	avant 8.2.35	8.2.35	Le support se termine le 31 décembre 2026
8.1, 8.0, 7.4	Concernée	Aucune version officielle	PHP n’a publié que des correctifs minimaux pour ceux qui compilent depuis les sources

Toutes les installations qui traitent des requêtes web via PHP sont concernées : PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est surtout élevé dans les installations qui utilisent mod_php, car l’exploit présenté se déclenche pendant le traitement de la requête, sans qu’aucun code applicatif ne soit exécuté. Autrement dit, le fait que le site soit sous WordPress, Laravel ou une application écrite à la main ne change rien à lui seul.

La quatrième version candidate (RC4) de la version 8.6.0, en phase de test, contient les correctifs, mais elle n’est pas destinée à la production. Les distributions et les entreprises de support à long terme ont reçu les correctifs à l’avance ; certaines, comme AlmaLinux, ont publié les paquets le jour même. PHP a également annoncé que le dépôt rpms.remirepo.net ne pourra pas fournir de paquets à jour le 21 octobre.

1. Comment savoir ce que j’utilise sur mon propre serveur ?

La version en ligne de commande et celle utilisée par le serveur web peuvent être différentes. Il faut d’abord vérifier les deux :

# Komut satırı sürümü
php -v

# PHP-FPM kuruluysa (paket adı dağıtıma göre değişir, ör. php8.3-fpm)
php-fpm8.3 -v

# Debian/Ubuntu: yüklü PHP paketleri ve sürümleri
dpkg -l | grep -E '^ii\s+(php|libapache2-mod-php)'

# RHEL/AlmaLinux/Rocky
rpm -qa | grep -E '^php'

Côté web, pour voir avec quelle interface serveur (SAPI) PHP s’exécute, on peut consulter la ligne Server API dans la sortie de phpinfo() ; si la ligne indique « Apache 2.0 Handler », cela signifie que mod_php est utilisé. Il faut ouvrir cette page temporairement et la supprimer une fois le travail terminé.

Ceux qui utilisent un hébergement mutualisé voient généralement la version depuis le panneau et c’est l’hébergeur qui effectue la mise à jour. Dans ce cas, le plus juste est de vérifier si l’entreprise a fait une déclaration et, si nécessaire, de lui poser la question.

2. Mise à jour

La seule solution complète est de mettre à jour. Si les paquets de la distribution sont utilisés, on se base sur la version indiquée dans l’avis de sécurité de la distribution ; si l’on compile depuis les sources, on se base sur la version du tableau ci-dessus. Après la mise à jour, il faut redémarrer tous les workers PHP ; le simple fait d’installer le paquet ne remplace pas les processus en cours :

# Örnek: Debian/Ubuntu, PHP-FPM ve Apache
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

Le NCSC rappelle notamment ceci : les équipements réseau, les panneaux d'administration, les applications prêtes à l'emploi et les images de conteneurs qui intègrent PHP en interne ne sont pas mis à jour par le gestionnaire de paquets du serveur. Pour ceux-ci, il faut attendre le correctif de l'éditeur. Le NCSC-NL tient sur GitHub une liste des produits susceptibles d'être affectés.

3. Si la mise à jour ne peut pas être faite immédiatement

Voici les mesures provisoires recommandées par PHP. Selon les propres termes de PHP, elles réduisent certaines voies d'attaque mais ne rendent pas l'installation sûre. Les réglages doivent être définis dans php.ini, dans le pool FPM ou dans la configuration du serveur, puis tous les workers doivent être redémarrés ; il ne faut pas se fier aux réglages définis via ini_set() ou .user.ini.

Pour CVE-2026-109619 :

; Oturum yükleme ilerlemesi gerekmiyorsa kapalı tutulmalı (yamadan sonra da)
session.upload_progress.enabled = 0

; Yalnızca PHP 8.5
fatal_error_backtraces = 0

Il faut également supprimer les réglages invalides ou obsolètes définis par requête et qui génèrent un avertissement au démarrage (comme les lignes php_value dans .htaccess). Masquer l'avertissement avec error_reporting, display_errors ou @ ne fonctionne pas.

Pour CVE-2026-109618 :

; Dosya yükleme gerekmiyorsa 8M, gerekiyorsa 32M
post_max_size = 8M
; upload_max_filesize, post_max_size değerinden küçük kalmalı
upload_max_filesize = 6M

PHP recommande également memory_limit=-1 comme mesure partielle. Comme ce réglage supprime la limite de mémoire, le serveur doit être protégé par un autre moyen, par exemple par une limite de conteneur ou de cgroup memory.max. Il ne faut pas utiliser RLIMIT_AS ni RLIMIT_DATA ; ceux-ci peuvent justement provoquer l'erreur d'allocation mémoire qui déclenche la vulnérabilité. Au niveau du serveur web ou du reverse proxy, il faut fixer des limites pour la taille des requêtes, le nombre de champs, le nombre de parties d'un formulaire multipart et le nombre d'en-têtes. Si l'application n'utilise pas de formulaires multipart, ces requêtes peuvent être bloquées en amont.

Le NCSC recommande, si aucune de ces mesures n'est possible, d'envisager de mettre le système hors ligne jusqu'à ce qu'il soit corrigé. Pour les systèmes dont le correctif doit être retardé, il est également recommandé de surveiller les journaux du serveur web, les processus inattendus, les fichiers et les connexions sortantes.

Allégations non vérifiées

Les éléments de cette section ne figurent pas dans les annonces officielles ou se contredisent :

Exploitation active : watchTowr indique avoir observé une exploitation sur son propre réseau de pots de miel (honeypots) au 21 octobre. Patchstack et Aikido ont également signalé une exploitation ; toutefois, selon la note de SOCRadar, aucun des deux n'a publié de détails techniques. Datadog, en se fondant sur AWS, rapporte que les tentatives d'exploitation ont commencé le 17 octobre, quatre jours avant la divulgation publique des vulnérabilités ; Sansec écrit, en se fondant sur une publication sur les réseaux sociaux, que Cloudflare a observé des attaques le matin du 21 octobre, avant la publication des correctifs. Je n'ai pu vérifier aucune de ces informations de première main. Par ailleurs, le Centre canadien de cybersécurité indique le même jour n'avoir détecté aucune exploitation active, tout en précisant que la situation peut évoluer rapidement ; Rapid7 ne signale pas non plus d'exploitation confirmée et écrit qu'elle est attendue. Selon SOCRadar, les deux vulnérabilités ne figuraient pas, au 21 octobre, dans le catalogue des vulnérabilités exploitées (KEV) de la CISA.
Preuve de concept (PoC) publique : le Centre canadien de cybersécurité écrit, selon des informations publiques, qu'une preuve de concept existe. Des dépôts publiés sous ce nom existent sur GitHub ; je n'ai pas testé s'ils fonctionnent et je ne fournis pas de lien.
Remontée jusqu'à PHP 5 : certains articles affirment que les vulnérabilités touchent toutes les versions depuis PHP 5. PHP indique dans son annonce avoir publié un correctif minimal pour 7.4, 8.0 et 8.1 ; il ne dit rien de précis sur les versions plus anciennes. La formulation du NCSC, « toutes les versions de PHP », peut aussi être lue en ce sens, mais elle ne donne pas d'intervalle de versions.

Questions fréquentes

Suis-je concerné si mon site est sous WordPress ?

Très probablement oui. Les vulnérabilités ne sont pas dans WordPress, mais dans PHP lui-même. Indépendamment de l'application avec laquelle le site est construit, le risque existe si la version de PHP du serveur est antérieure aux versions corrigées. Une mise à jour d'extension ou de thème ne résout pas ce problème.

Que faire en hébergement mutualisé ?

L'hébergeur de PHP met à jour. Il suffit de vérifier la version de PHP dans le panneau, de contrôler si l'entreprise a publié une déclaration sur php2shell et, en l'absence de déclaration, de la demander. Si le panneau le permet, passer à la branche PHP la plus récente prise en charge est également une bonne étape.

Je n'utilise PHP qu'en ligne de commande, y a-t-il un risque ?

Les annonces officielles ciblent les installations qui traitent des requêtes web ; elles ne mentionnent pas spécifiquement l'usage en ligne de commande (CLI). Toutefois, si un serveur web tourne aussi sur la même machine, la mise à jour ne doit pas être reportée.

Les réglages temporaires suffisent-ils ?

Non. PHP indique clairement que des réglages comme session.upload_progress.enabled=0, fatal_error_backtraces=0 et memory_limit réduisent certaines voies d'attaque, mais ne rendent pas l'installation sûre.

J'utilise PHP 8.1 ou une version plus ancienne, que va-t-il se passer ?

Le projet PHP ne publie pas de nouvelle version pour ces branches. Des correctifs minimaux ont été publiés pour 7.4, 8.0 et 8.1 à destination de ceux qui compilent depuis les sources ; les distributions et les entreprises de support à long terme peuvent aussi proposer leurs propres correctifs. La solution durable est de passer à une branche prise en charge.

Mon analyse

Ce qui est certain : il existe deux vulnérabilités distinctes, critiques et ne nécessitant pas d'authentification ; les correctifs sont arrivés avec 8.2.35, 8.3.36, 8.4.27 et 8.5.12. L'installation la plus exposée est Apache mod_php.
La configuration seule n'est pas une solution : PHP écrit clairement qu'aucune des mesures temporaires ne rend l'installation sûre. Modifier les réglages et reporter la mise à jour ne fait que réduire le risque.
La charge principale est en dehors du serveur : mettre à jour son propre serveur est relativement facile. Ce qui est difficile, ce sont les appareils, les panneaux et les images de conteneurs qui embarquent PHP en interne ; le moment de leur correctif dépend du fabricant.
Les versions en fin de support : les systèmes restés sur 8.1 et antérieur n'ont cette fois pas reçu de version officielle. Sachant que 8.2 sortira également du support le 31 décembre 2026, il semble judicieux de planifier la mise à jour en même temps que le passage à la branche suivante.
Rester prudent sur l'exploitation : les affirmations d'exploitation active proviennent de plusieurs sociétés de sécurité, mais les organismes officiels ne les ont pas encore confirmées. Je ne les tiens pas pour acquises ; je ne les considère pas non plus comme une raison d'attendre pour mettre à jour. Si de nouvelles informations officielles paraissent, je mettrai l'article à jour.

Sources

Annonces officielles

Évaluations des sociétés de sécurité