PHP2Shell : deux RCE critiques dans le cœur de PHP (CVE-2026-109618 et CVE-2026-109619)

Introduction

Le 21 octobre 2026, l'équipe de sécurité de PHP a publié des versions correctives pour deux vulnérabilités critiques situées dans le cœur du langage (et non dans une application ou une bibliothèque tierce) : CVE-2026-109618 et CVE-2026-109619. Toutes deux sont notées 9.2 en CVSS v4.0 (score attribué par l'équipe PHP à la date de rédaction de cet article, susceptible d'évoluer avec les analyses ultérieures, notamment celles du NVD) et peuvent conduire à une exécution de code à distance (RCE) sans authentification, avec les privilèges du processus web.

L'événement a été baptisé « PHP2Shell » par la communauté. Le calendrier de divulgation est inhabituel : les identifiants CVE ont fuité avant la publication, l'équipe PHP a avancé la sortie des correctifs d'un jour, et Amazon Threat Intelligence rapporte une tentative d'exploitation dès le 17 octobre, soit quatre jours avant la divulgation.

Dans cet article, nous résumons ce qui est connu à ce jour, expliquons le mécanisme sans diffuser de code d'exploitation, et proposons surtout des commandes pour que vous puissiez vérifier vous-mêmes votre exposition.

Point d'attention : la situation évolue vite. Cet article est basé sur les avis officiels de PHP et sur les publications d'éditeurs de sécurité à la date du 22 octobre 2026. Les sources sont listées en fin d'article.

TLDR : l'essentiel en 30 secondes

• Quoi : deux failles critiques dans le cœur de PHP, exploitables sans authentification pour exécuter du code à distance.
• Qui : toute installation PHP servant des requêtes web et antérieure à 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. Les branches 8.1 et antérieures n'ont pas de correctif officiel.
• Que faire : mettre à jour et redémarrer les workers, seule correction complète.
• Vérifier vous-même : 1. inventorier les PHP · 2. comparer les versions · 3. contrôler les rétroportages · 4. vérifier la configuration · 5. repérer l'exposition externe · 6. chercher des traces d'exploitation

En bref

Que se passe-t-il techniquement ?

Les deux failles relèvent de la même famille : la gestion de l'état d'une requête qui survit ou est mal initialisé après une erreur fatale. Nous nous appuyons ici sur les avis officiels de PHP (GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp).

CVE-2026-109618 : corruption mémoire à la suite d'une saturation de la mémoire

Lorsque PHP manque de mémoire (Out Of Memory, OOM), il interrompt la requête avec un longjmp(). Dans certains contextes, la mémoire de la requête est déjà accessible alors qu'elle n'est pas entièrement initialisée. L'interruption laisse alors des structures invalides, que la phase de nettoyage de fin de requête lit comme si elles étaient valides.

Plusieurs comportements du traitement des requêtes multipart permettent de provoquer ce manque de mémoire tout en restant dans les limites apparentes de PHP : absence de gestion de la longueur du contenu, nombre illimité d'en-têtes par partie, champs de fichier vides avec des noms de champs imbriqués. Une condition OOM propre à l'application peut aussi suffire.

CVE-2026-109619 : réutilisation d'un état de requête déjà libéré (use-after-free)

PHP conserve certains états globaux liés à une requête (erreurs, sessions, objets, extensions) alors que la mémoire sous-jacente a été libérée. Dans un worker persistant, du code exécuté avant l'initialisation normale d'une requête peut réutiliser ce pointeur périmé. L'exploitation nécessite deux requêtes traitées par le même worker : une qui laisse l'état périmé, une qui le consomme.

Deux producteurs d'état périmé sont confirmés par PHP :

• la progression d'envoi de fichiers dans les sessions (session.upload_progress), activée par défaut, validée sur mod_php et PHP-FPM ;
• les rétrotraces d'erreurs fatales (fatal_error_backtraces) de PHP 8.5, à la base de l'exploit confirmé sur mod_php.

JFrog décrit le mécanisme d'exploitation de la progression d'envoi : l'attaquant influence l'identifiant de session, un suffixe de clé et le nom du fichier envoyé, qui sont sérialisés dans un fichier de session. PHP désérialise ce fichier avant l'exécution de tout script. Une erreur qui court-circuite le nettoyage laisse des pointeurs sur de la mémoire libérée ; une seconde requête sur le même worker réutilise cette mémoire avec des octets contrôlés par l'attaquant.

Une précision sur l'attribution : les publications de Wiz et de JFrog rattachent le use-after-free de la progression d'envoi à CVE-2026-109618, et les rétrotraces d'erreurs ainsi qu'OPcache à CVE-2026-109619. Les avis GHSA de PHP, que nous suivons ici, décrivent CVE-2026-109618 comme un problème de gestion de l'OOM et CVE-2026-109619 comme un problème d'état périmé, la progression d'envoi figurant dans ce second avis. Wiz précise par ailleurs que d'autres variantes devraient relever des deux mêmes CVE. En pratique la distinction n'a pas d'incidence sur la remédiation : les deux sont corrigées par les mêmes versions.

La découverte est attribuée à Wiz Research, en coordination avec Calif et OpenAI, avec une part importante d'analyse assistée par IA. Wiz indique avoir identifié le premier bug le 19 août 2026 et signalé l'ensemble à l'équipe PHP le 24 août, soit près de deux mois avant la publication.

Pourquoi c'est grave

• Le code de l'application n'a pas besoin d'être vulnérable. C'est le moteur qui est en cause : un WordPress, un Drupal ou une application maison parfaitement à jour mais tournant sur un PHP vulnérable est exposé.
• L'exploitation se fait par une requête HTTP, avant l'authentification. PHP a validé une RCE complète sur mod_php avec les limites de mémoire et d'entrée par défaut.
• Tous les SAPI web sont concernés : PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. mod_php est le plus exposé (exploit complet validé par PHP). Pour PHP-FPM, la voie de la progression d'envoi a été validée, et l'autre faille semble exploitable sans qu'un exploit complet ait été démontré. FrankenPHP et LSAPI sont probablement concernés d'après l'analyse du code.
• Le périmètre dépasse vos serveurs web : PHP est embarqué dans des équipements et logiciels éditeurs (panneaux d'hébergement, appliances, outils d'administration). Cisco a par exemple publié un avis dédié.

État de l'exploitation

Les sources ne sont pas totalement alignées, ce qui est normal à ce stade :

• Amazon Threat Intelligence a observé une tentative sur ses honeypots le 17 octobre, puis d'autres le 21 octobre avec des charges et infrastructures laissant penser à plusieurs acteurs. Amazon recommande d'investiguer à partir du 17 octobre.
• Tenable indique une exploitation large dans la nature. Rapid7 est plus prudent et s'attend à la publication prochaine d'un exploit fonctionnel. Huntress n'avait pas observé d'exploitation chez ses partenaires au 21 octobre.
• Des outils d'exploitation publics existent désormais. Sansec indique que des analyses techniques et un outil d'exploitation, attribué à Calif, sont publics. Calif a démontré une exécution de code sans authentification sur Magento 2.4.9 et dix autres applications PHP, et watchTowr a confirmé une RCE dès le 20 octobre. Cloudflare a observé des premières attaques le 21 octobre à 07h43 UTC, avant la sortie des correctifs. Plusieurs dépôts GitHub se présentent aussi comme des PoC, mais leur fiabilité n'est pas établie : Huntress ne connaissait aucun code public à la date de sa publication, et JFrog signale des faux PoC, dont un embarquant une charge Base64. N'exécutez jamais un PoC non audité, et surtout pas sur un environnement de production. Nous ne référençons volontairement aucun de ces dépôts.

Notre recommandation est de considérer la vulnérabilité comme exploitée et de traiter les serveurs exposés à Internet en priorité.

Suis-je vulnérable ? Commandes de vérification

Les commandes ci-dessous sont purement défensives : elles lisent des versions, des configurations et des processus. Elles n'exploitent pas la faille. Elles sont à exécuter sur vos propres systèmes, avec un compte disposant des droits adéquats.

Étape 1 : inventorier toutes les installations PHP

Une machine peut contenir plusieurs PHP (CLI, FPM, module Apache, conteneurs, logiciels embarquant leur propre PHP). Commencez par les lister.

# Binaires PHP, PHP-FPM, php-cgi et modules Apache présents sur le système
find / \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'libphp*.so' \) -type f -perm -u+x -not -path '/proc/*' 2>/dev/null

# Version de chaque SAPI
php -v
php-fpm -v 2>/dev/null          # ou php-fpm8.3 -v selon la distribution
php-cgi -v 2>/dev/null

# Module PHP chargé par Apache
apache2ctl -M 2>/dev/null | grep -i php    # httpd -M sur RHEL et dérivés

Pour Windows (PowerShell) :

Get-ChildItem -Path C:\ -Recurse -Include php.exe,php-cgi.exe -ErrorAction SilentlyContinue |
  ForEach-Object { "$($_.FullName) : $((& $_.FullName -v)[0])" }

Pour les conteneurs :

# Version de PHP dans chaque conteneur en cours d'exécution (identifiant du conteneur : version)
# Le nom correspondant s'obtient avec « docker ps ».
for c in $(docker ps -q); do
  echo "$c : $(docker exec $c php -v 2>/dev/null | head -1)"
done

Ne vous arrêtez pas aux conteneurs en cours d'exécution : vérifiez aussi les images de base de vos registres et de vos pipelines CI/CD. Si vous utilisez une image « corrigée » fournie par un tiers, contrôlez la version de PHP à l'intérieur : certaines images communautaires affichent des tags inférieurs aux versions corrigées (par exemple 8.3.35 au lieu de 8.3.36), ce qui ne suffit pas pour conclure qu'elles sont protégées.

Sur les testeurs en ligne : des vérificateurs publics de PHP2Shell existent. Ne les utilisez que sur des sites qui vous appartiennent, et sachez qu'un résultat négatif ne prouve pas que vous êtes à jour. Aikido précise que son test définitif envoie une charge susceptible de faire planter un worker PHP. Préférez la vérification de version et du journal du paquet ci-dessus, et évitez toute exécution sur un système de production en heures ouvrées.

Étape 2 : comparer avec les versions corrigées

Vous êtes sans doute vulnérable si votre version est inférieure à :

Étape 3 : attention aux rétroportages des distributions

C'est le piège classique. Debian, Ubuntu, RHEL et dérivés corrigent souvent sans changer le numéro de version amont. Un paquet affichant 8.2.29 peut donc déjà contenir le correctif : un numéro inférieur à ceux du tableau ne suffit pas à conclure qu'un paquet de distribution est vulnérable, pas plus qu'un numéro identique ne prouve qu'il est protégé. Vérifiez le journal des modifications du paquet :

# Debian / Ubuntu
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'
dpkg -l | grep -E '^ii\s+php'

# RHEL, Fedora, Rocky, Alma
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'
rpm -qa | grep -i '^php'

# Alpine (pas de journal de CVE dans le paquet : comparer avec le suivi de sécurité Alpine)
apk list -I 'php*'

Si les deux CVE apparaissent dans le journal du paquet installé, le correctif est présent dans ce paquet (encore faut-il que les processus aient été redémarrés, voir plus bas). Dans le doute, consultez l'avis de sécurité de votre distribution et mettez à jour : apt update && apt install --only-upgrade 'php*', ou dnf upgrade 'php*'.

Pour les dépôts tiers (par exemple Remi), l'équipe Huntress notait que les paquets n'étaient pas encore à jour le jour de la publication. Vérifiez la disponibilité avant de conclure.

Étape 4 : vérifier les configurations d'atténuation (si vous ne pouvez pas mettre à jour immédiatement)

Ces réglages réduisent la surface connue, mais ne sont pas une correction (voir plus bas).

# Valeurs présentes dans les fichiers de configuration PHP (ignorer les lignes commentées par « ; »)
grep -rnE 'session\.upload_progress\.enabled|fatal_error_backtraces|^\s*memory_limit' /etc/php* /usr/local/etc/php* 2>/dev/null

# Valeur du php.ini de PHP-FPM (celui du CLI est souvent différent ! sous Debian : php-fpm8.3 -i)
php-fpm -i 2>/dev/null | grep -E 'session.upload_progress.enabled|fatal_error_backtraces|^memory_limit'

Cette commande ne voit pas les surcharges par pool PHP-FPM (php_admin_value[...] dans /etc/php/*/fpm/pool.d/, déjà couvert par le premier grep). Pour mod_php, la valeur effective est celle du php.ini du dossier apache2 (ex. /etc/php/8.3/apache2/php.ini) plus les directives posées dans la configuration Apache et les .htaccess, où un php_value peut remettre une valeur que vous aviez durcie (seul php_admin_value n'est pas surchargeable) :

grep -rnEi 'php_(admin_)?(value|flag)' /etc/apache2 /etc/httpd /var/www --include='*.conf' --include='.htaccess' 2>/dev/null | grep -iE 'upload_progress|memory_limit|fatal_error'

Étape 5 : repérer l'exposition externe

Pour identifier ce qui, côté Internet, expose potentiellement du PHP (détection indicative uniquement, l'en-tête est souvent masqué) :

curl -sI https://votre-site.example | grep -iE '^(server|x-powered-by):'

Une absence d'en-tête ne prouve rien. Ne vous fiez pas à cette méthode pour conclure à une non-exposition. Les outils d'inventaire et de gestion de surface d'attaque (scanners authentifiés, EASM) sont plus fiables. Tenable fournit par exemple le plugin Nessus 369483 (« PHP < 8.2.35 / 8.3.x < 8.3.36 / 8.4.x < 8.4.27 / 8.5.x < 8.5.12 Multiple Vulnerabilities »), qui se base uniquement sur la version annoncée par PHP et ne teste donc pas la faille (un paquet de distribution corrigé par rétroportage peut ressortir en faux positif), et runZero propose la requête vendor:=PHP AND product:=PHP dans son inventaire logiciel.

Comment savoir si on a déjà été ciblé ?

Les éditeurs n'ont pas encore publié d'indicateurs de compromission (IOC) confirmés. La détection la plus fiable à ce jour repose sur le comportement : un processus PHP ou serveur web qui lance un interpréteur de commandes ou un outil de téléchargement.

# Processus lancés PAR un worker PHP / Apache (hors workers eux-mêmes) : à examiner
# (sh, bash, python, perl, curl, wget, nc...). Quelques résultats légitimes sont normaux
# (convert, git, sendmail...) : c'est la nouveauté et l'incohérence qui comptent.
ps -eo pid=,ppid=,user=,comm=,args= | awk '
  { comm[$1]=$4; line[$1]=$0; ppid[$1]=$2 }
  END { for (p in ppid)
          if (comm[ppid[p]] ~ /^(php|apache2|httpd)/ && comm[p] !~ /^(php|apache2|httpd)/) print line[p] }'

# Motifs de reverse shell dans les journaux et les racines web
# (fsockopen existe dans du code légitime, notamment dans vendor/ : à trier)
grep -rEl '/dev/tcp/|fsockopen|mkfifo' /var/log/apache2 /var/log/nginx /var/log/httpd /var/www 2>/dev/null

# Fichiers PHP modifiés depuis les 5 derniers jours (à comparer à vos dates de déploiement)
find /var/www /srv /home -name '*.php' -mtime -5 2>/dev/null

Sous Windows :

$php = Get-CimInstance Win32_Process | Where-Object { $_.Name -in 'php-cgi.exe','php.exe' } | Select-Object -ExpandProperty ProcessId
Get-CimInstance Win32_Process | Where-Object { $_.ParentProcessId -in $php -and $_.Name -in 'cmd.exe','powershell.exe' }

Compte tenu de la première tentative observée le 17 octobre, remontez vos analyses de journaux au minimum jusqu'à cette date. Cherchez en particulier :

• des requêtes multipart/form-data inhabituelles (en-têtes très nombreux, corps volumineux, champs imbriqués) suivies de redémarrages ou d'erreurs de workers ;
• des cookies PHPSESSID anormalement volumineux ou mal formés dans les réponses, ainsi que des séries de réponses HTTP 500 après des requêtes multipart (indicateurs relevés par Wiz et Aikido) ;
• des erreurs de mémoire ou des arrêts anormaux des processus PHP (segfault dans dmesg ou les journaux système, messages Allowed memory size exhausted, workers tués par le noyau) ;
• des reconnaissances classiques exécutées depuis le compte web : id, whoami, uname -a.

⚠️ L'absence de ces éléments ne prouve pas l'absence de compromission. Le vecteur peut laisser peu de traces applicatives, et PHP indique lui-même que des journaux d'erreurs propres ne constituent pas une preuve suffisante.

En cas de suspicion : isolez le serveur, conservez les journaux, recherchez des webshells, de nouvelles tâches planifiées et de nouveaux comptes, puis renouvelez les secrets (mots de passe, jetons, clés d'API, certificats) accessibles par l'application, la faille pouvant en divulguer le contenu mémoire.

La position du CERT-FR

Le CERT-FR a publié l'alerte CERTFR-2026-ALE-014 le 21 octobre 2026. Elle classe le risque en exécution de code arbitraire à distance et liste comme systèmes affectés :

• toutes les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x, qui ne sont plus supportées par l'éditeur ;
• PHP 8.2.x avant 8.2.35, 8.3.x avant 8.3.36, 8.4.x avant 8.4.27 et 8.5.x avant 8.5.12.

Le CERT-FR recommande d'isoler les équipements affectés, puis de migrer vers une version maintenue. Il propose aussi deux mesures transitoires, qu'il indique ne pas avoir vérifiées :

1. désactiver la progression d'envoi de fichiers : session.upload_progress.enabled = Off dans le php.ini, ou php_admin_flag[session.upload_progress.enabled] = off pour PHP-FPM. Cela ne réduit l'exposition qu'à l'une des deux vulnérabilités ;
2. bloquer les requêtes HTTP dont l'en-tête Content-Type est multipart (via un WAF par exemple) ou, à défaut, les surveiller de près.

Ce second point est facile à vérifier côté journaux. Si votre serveur web consigne le Content-Type (champ à ajouter au format de journal), vous pouvez isoler ces requêtes :

# Exemple Apache : ajouter %{Content-Type}i au LogFormat, puis compter les multipart par IP source
grep -i 'multipart/form-data' /var/log/apache2/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

Que faire ?

1. Mettre à jour (seule correction complète)

Passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou au paquet corrigé de votre distribution. PHP est clair sur ce point : aucune configuration ne constitue une atténuation complète.

Redémarrez les workers (systemctl restart php8.3-fpm, apache2, etc.) : un correctif installé mais non rechargé ne protège pas les processus déjà en mémoire. Vérifiez ensuite que les processus ont bien démarré après la mise à jour, pas seulement que le paquet est à jour sur le disque :

ps -eo pid,lstart,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd' | head

2. Si une mise à jour immédiate est impossible

Appliquez, en complément et à titre transitoire :

• session.upload_progress.enabled = 0 ;
• sur PHP 8.5 : fatal_error_backtraces = 0 ;
• memory_limit = -1 imposé de façon que l'application ne puisse pas le surcharger, et sans recourir à RLIMIT_AS ni RLIMIT_DATA (qui provoquent des échecs d'allocation mmap() sur le chemin vulnérable). Attention, cela supprime une protection contre l'épuisement des ressources : combinez avec une limite mémoire au niveau du conteneur ou du cgroup ;
• réduction de la surface de requêtes : post_max_size conservateur, limites du nombre de variables, de parties multipart et de profondeur d'imbrication, ou blocage du multipart au niveau du frontal si l'application n'en a pas besoin ;
• si vos performances le permettent, pm.max_requests = 1 en PHP-FPM, qui réduit la condition « même worker » ;
• redémarrage de tous les workers après chaque changement.

Ces mesures sont partielles : la désactivation de la progression d'envoi ne couvre pas la voie des rétrotraces ni l'état d'OPcache, et la suppression de la limite mémoire n'empêche pas tous les échecs d'allocation. Un WAF peut aider (Cloudflare a publié des règles couvrant des vecteurs connus), mais Cloudflare lui-même le qualifie de palliatif.

3. PHP 8.1 et versions antérieures : sortir de l'impasse

Aucune version officielle n'est prévue. L'équipe PHP a fourni de minimaux rétroportages pour les sources de PHP 7.4, 8.0 et 8.1, utilisables uniquement si vous compilez vous-même. Pour les branches 5.4 à 7.3, rien n'existe côté PHP. Dans tous les cas :

• vérifiez si votre distribution ou un éditeur LTS publie un correctif ;
• retirez ces systèmes d'Internet ou placez-les derrière un VPN, un WAF ou un reverse proxy qui filtre le multipart ;
• planifiez la migration vers une branche supportée. À noter que PHP 8.2 sera en fin de vie le 31 décembre 2026 : n'en faites pas votre cible de long terme.

4. Ne pas oublier les « PHP cachés »

L'inventaire doit inclure les PHP embarqués : CMS (WordPress, Drupal, Joomla, Magento), panneaux d'hébergement (cPanel, Plesk), appliances et outils d'administration, ainsi que les images de conteneurs. Pour chacun, la correction dépend de l'éditeur : demandez-lui sa position et son calendrier. Le NCSC néerlandais tient pour cela un inventaire public des produits embarquant PHP, avec un statut par produit (en investigation, vulnérable, corrigé, contournement, non vulnérable). Il est encore incomplet, ses entrées sont des pistes à confirmer auprès de l'éditeur, et il ne couvre pas vos applications PHP développées en interne.

Notre analyse

Cet épisode illustre plusieurs points que nous rencontrons régulièrement lors de nos missions :

• Le patch management ne s'arrête pas à l'application. Une application à jour au-dessus d'un runtime vulnérable reste exposée. L'inventaire des composants sous-jacents (runtimes, modules, images de base) est une condition préalable.
• Les environnements « oubliés » sont ceux qui paieront. Les PHP 7.x ou 5.x maintenus pour des raisons historiques, les serveurs de recette exposés et les images de conteneurs figées n'auront pas de paquet officiel corrigé (au mieux des rétroportages à compiler soi-même pour 7.4 à 8.1).
• La fenêtre entre fuite et correctif se réduit. Une tentative d'exploitation observée avant la divulgation montre qu'il faut pouvoir déployer en heures, et non en semaines.
• La détection comportementale compense l'absence d'IOC. Un serveur web qui lance un shell doit déclencher une alerte, quelle que soit la vulnérabilité exploitée. C'est aussi un bon exercice pour vérifier ce que votre supervision voit réellement.

Chez AlgoSecure, nous pouvons vous accompagner pour cartographier votre exposition (avec AlgoLightHouse, notre solution EASM), vérifier l'exploitabilité sur vos périmètres exposés dans le cadre d'un test d'intrusion et évaluer l'impact d'une compromission via une approche Assumed Breach.

Sources

• php.net : annonces des 20 et 21 octobre 2026
• CERT-FR : CERTFR-2026-ALE-014
• GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp : avis de sécurité officiels
• Wiz Research : PHP2Shell
• Aikido : Critical vulnerabilities in PHP
• NCSC-NL : php2shell
• Sansec : PHP2Shell
• JFrog Security Research : PHP2Shell
• Tenable : php2shell FAQ
• Huntress : Rapid Response php2shell
• runZero : Critical RCE vulnerability in PHP
• Rapid7 : CVE-2026-109618 and CVE-2026-109619
• Cisco Security Advisory : PHP October 2026