PHP2Shell : CVE-2026-109618 et CVE-2026-109619, exécution de code à distance non authentifiée dans PHP

Rapport CTI technique du 24 octobre 2026

Résumé exécutif

Le 21 octobre 2026, le projet PHP a publié les correctifs 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour deux vulnérabilités critiques regroupées sous le nom PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Chacune est évaluée CVSS v4.0 9.2 et permet à un attaquant non authentifié d'obtenir une exécution de code à distance sur un serveur web exécutant PHP. watchTowr indique avoir observé une exploitation des deux failles dans la nature via son réseau de honeypots Attacker Eye à partir du 21 octobre 2026. À la date du présent rapport, aucune des deux CVE ne figure au catalogue CISA KEV.

La faille CVE-2026-109618 repose sur une corruption liée à la gestion des erreurs d'épuisement mémoire, et CVE-2026-109619 sur un état global périmé qui survit à la mémoire de requête. Le risque est le plus élevé sur Apache mod_php, où l'attaque peut aboutir avant l'exécution du code applicatif. Les branches PHP 8.1 et antérieures ne reçoivent plus de correctif officiel et doivent être migrées ou couvertes par un backport de distribution.

Chronologie

Fiche vulnérabilité

CVE-2026-109618 | CVSS 9.2 (v4.0, vecteur non publié) | PHP, noyau php-src

CVE-2026-109619 | CVSS 9.2 (v4.0, vecteur non publié) | PHP, noyau php-src

CVE-2026-109618 repose sur la gestion des erreurs d'épuisement mémoire. PHP utilise longjmp() pour interrompre le traitement de la requête en cas d'erreur d'épuisement mémoire. Dans certains contextes, la mémoire de requête est temporairement accessible avant d'être totalement initialisée. Si une allocation échoue à ce moment, PHP sort du contexte sans prendre en compte cette interruption et laisse la mémoire dans un état invalide. La procédure de nettoyage de requête peut ensuite lire cette mémoire ou effectuer un branchement dessus. L'avis éditeur décrit plusieurs stratégies OOM capables de déclencher la condition de manière fiable : une requête multipart sans longueur de contenu exploitable peut passer le contrôle post_max_size initial, une partie multipart peut contenir un nombre non limité d'en-têtes dont la représentation interne consomme plus de mémoire que la représentation filaire, les contrôles de fichier vides ne comptent pas dans max_file_uploads tout en créant des tableaux de métadonnées, et les noms de champs imbriqués multiplient le travail de construction du tableau. L'épuisement mémoire peut aussi être atteint par des chemins applicatifs lorsque des entrées contrôlées par l'attaquant provoquent une allocation importante.

CVE-2026-109619 concerne un état global périmé qui survit à la mémoire de requête. PHP utilise également longjmp() pour interrompre le traitement après une erreur fatale. Dans certains contextes, l'état global pointe vers de la mémoire libérée en fin de requête. Une requête suivante traitée par le même worker PHP peut lire ou brancher sur cet état invalide. Les travaux cités par Recorded Future et Imperva identifient un use-after-free dans le désérialiseur de progression d'upload de session, un use-after-free dans la génération de backtraces d'erreur fatale et une confusion de type dans le cache OPcache. La fonctionnalité Session Upload Progress, activée par défaut, constitue un chemin confirmé vers CVE-2026-109619.

Les classifications CWE divergent : les données structurées associent CWE-416 à CVE-2026-109618, tandis qu'Imperva classe les deux failles en CWE-824.

Versions affectées et corrigées

Pour exploiter ces failles, l'accès réseau suffit, aucun compte ni interaction utilisateur n'est requis. La complexité d'attaque est élevée selon Imperva : l'attaquant doit franchir une protection mémoire intégrée, placer des données façonnées dans l'espace libéré et atteindre le même worker Apache. Sur Apache mod_php, la procédure de nettoyage est invoquée inconditionnellement même en cas d'échec du démarrage de requête, ce qui permet une attaque avant toute exécution de code applicatif. FPM quitte le processus enfant en cas d'échec de démarrage, ce qui empêche la consommation de l'état invalide à ce stade. Une susceptibilité FPM est déduite de l'analyse du code source mais aucun exploit complet FPM n'a été démontré pour cette SAPI. FrankenPHP est jugé probablement susceptible par analogie avec mod_php. LSAPI est jugé probablement exploitable par des chemins applicatifs, sans validation publiée.

Un outil de preuve de concept nommé PHP2Shell a fuité le 20 octobre 2026. Des dépôts publics proposent des PoC, dont deux publiés par le chercheur J4ck3LSyN puis invalidés par leur auteur concernant la théorie du pointeur en cache. Wiz indique avoir démontré une RCE non authentifiée contre WordPress, Drupal et Joomla. watchTowr signale une exploitation en conditions réelles des deux CVE via son réseau Attacker Eye depuis le 21 octobre 2026. La CSA de Singapour fait état de tentatives d'exploitation généralisées, tandis que Recorded Future indique que l'ampleur exacte des compromissions réussies n'est pas établie à la date de son point du 21 octobre 2026.

Diagramme de la chaîne d'attaque

Analyse technique

Étape 1 : Déclenchement contrôlé de l'épuisement mémoire ou de l'erreur fatale

L'attaquant envoie une requête HTTP multipart/form-data construite pour rester sous les limites apparentes de PHP tout en épuisant la mémoire réelle du worker. L'avis éditeur décrit des leviers précis : absence de longueur de contenu exploitable, en-têtes multipart non bornés, contrôles de fichier vides et noms de champs imbriqués. Pour CVE-2026-109619, la fonctionnalité Session Upload Progress, activée par défaut, offre un chemin d'entrée confirmé.

Étape 2 : Sortie anticipée par longjmp et création d'un état mémoire invalide

Quand l'allocation échoue ou qu'une erreur fatale survient, PHP abandonne le contexte courant via longjmp. Selon l'avis GHSA-w8hw-w9fx-j79w, certains contextes laissent alors une mémoire de requête partiellement initialisée ou un état global pointant vers de la mémoire libérée, sans que la comptabilité de nettoyage ait été exécutée.

Étape 3 : Traitement de l'état invalide lors du nettoyage ou de la requête suivante

Sur mod_php, la procédure de nettoyage de requête est invoquée inconditionnellement, y compris après un échec de démarrage. Le code de nettoyage lit ou branche sur l'état invalide. Pour CVE-2026-109619, le même worker réutilise ensuite l'état global périmé lors d'une requête ultérieure, ce qui permet de placer des données façonnées dans l'espace libéré.

Étape 4 : Obtention d'une exécution de code

La corruption mémoire peut être convertie en exécution de code arbitraire avec les privilèges du processus PHP. L'attaque aboutit avant l'exécution du code applicatif sur mod_php, ce qui rend même un endpoint minimal vulnérable. Les effets secondaires observés incluent des arrêts de worker, des lectures de fichiers arbitraires et une divulgation de mémoire serveur selon Imperva.

Exposition

Toute installation PHP servant des requêtes web est concernée, y compris PHP-FPM, mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque le plus élevé est documenté pour Apache mod_php. Les applications construites sur WordPress, Drupal et Joomla sont exposées lorsque le moteur PHP sous-jacent est vulnérable, car la faille touche le runtime et non le code applicatif. Imperva estime que PHP est utilisé par plus de 69 % des sites dont le langage serveur est connu. Les serveurs directement accessibles depuis Internet doivent être traités en priorité, en particulier les modules Apache mod_php. Les branches PHP 8.1 et antérieures, y compris des versions remontant à PHP 5.4.0 selon Imperva, restent exposées sans correctif officiel.

Indicateurs de compromission

Aucun IOC public documenté à ce jour.

Pistes de détection :

• Journaliser et alerter sur les requêtes multipart/form-data présentant une absence de Content-Length exploitable, un nombre anormal de parties, d'en-têtes par partie ou de champs imbriqués.
• Surveiller les erreurs OOM, les erreurs fatales et les redémarrages anormaux de workers PHP dans les journaux de mod_php, PHP-FPM et FrankenPHP.
• Corréler les arrêts de worker avec les requêtes HTTP précédentes d'une même adresse source.
• Contrôler les accès au champ PHP_SESSION_UPLOAD_PROGRESS et aux endpoints de progression d'upload, notamment depuis des sources non légitimes.
• Déployer des signatures réseau ou de surface d'attaque spécifiques à PHP2Shell, comme le scanner mentionné par Help Net Security ou les signatures Attack Surface Intelligence de Recorded Future.
• Inspecter le trafic vers les applications WordPress, Drupal et Joomla à la recherche de corps multipart malformés répétés.

MITRE ATT&CK

Lecture analytique, aucune cartographie officielle publiée à ce jour.

Remédiation : checklist opérationnelle

1. Appliquer le correctif officiel de la branche utilisée : PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une version ultérieure de la même branche. Pour PHP 8.1 et antérieures, déployer un backport de distribution ou de fournisseur LTS, ou migrer vers une branche supportée.
2. Prioriser les serveurs exposés sur Internet, en particulier les configurations Apache mod_php, où le risque démontré est le plus élevé.
3. Identifier toutes les installations PHP, y compris celles embarquées par des applications tierces ou des composants, même si le site principal n'utilise pas PHP.
4. Pour les installations qui ne peuvent pas être mises à jour immédiatement, appliquer la mitigation partielle de l'éditeur : fixer et faire respecter memory_limit=-1, redémarrer chaque worker PHP, vérifier qu'aucun paramètre de pool, de répertoire ou d'application ne rétablit une limite finie.
5. Durcir les limites d'entrée : conserver post_max_size prudent, borner max_input_nesting_level, le nombre de variables d'entrée, de parties multipart, d'en-têtes par partie et d'uploads, et appliquer une limite de taille décodée côté frontal.
6. Mettre en place la surveillance décrite dans les pistes de détection et consulter la guidance PHP ainsi que les avis de la CSA de Singapour pour les mesures temporaires.

Sources

• Avis PHP GHSA-w8hw-w9fx-j79w
• Annonce oss-security CVE-2026-109618
• Discussion oss-security du 23 octobre 2026
• Avis Siemens SSA-566512
• Analyse Wiz Research PHP2Shell
• watchTowr PHP2Shell
• watchTowr FAQ CVE-2026-109618
• Recorded Future PHP2Shell
• Imperva PHP2Shell
• Alerte CSA Singapour