CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp
La moitié « entre requêtes » de PHP2Shell : après une erreur fatale, PHP laisse des pointeurs globaux vers de la mémoire déjà libérée. La requête suivante sur le même worker les utilise — et divulgue de la mémoire ou donne à un attaquant l’exécution de code.
Dernière vérification 2026-10-22
Gravité
Authentification
Corrigé dans
Fait partie de
Une erreur fatale (y compris OOM) peut sauter la réinitialisation propre à chaque requête : l’état global d’erreur, de session, d’objet ou d’extension continue alors de pointer vers de la mémoire libérée à la fin de la requête. La requête suivante sur le même worker peut utiliser cette mémoire libérée avant l’initialisation normale.
Impact : Use-after-free menant à la divulgation de la mémoire du worker ou à l’exécution de code. Démontré : RCE pré-authentification sur WordPress et Drupal ; divulgation de mémoire à distance indépendante de l’application.
PHP conserve une partie de son état dans des variables globales propres à la requête — état d’erreur, de session, d’objet et d’extension. Il est normalement réinitialisé à la fin de chaque requête. Une erreur fatale, y compris un manque de mémoire, peut sauter cette réinitialisation, et des avertissements pendant l’arrêt peuvent remplir à nouveau l’état d’erreur après son effacement.
La mémoire vers laquelle pointent ces globales est libérée à la fin de la requête. Si le même worker exécute ensuite du code avant l’initialisation normale de la requête — diagnostics INI ou traitement de progression d’envoi —, il utilise de la mémoire libérée. Ce sont les workers qui enchaînent de nombreuses requêtes (PHP-FPM, processus enfants mod_php) qui rendent cela atteignable.
Use-after-free dans les backtraces d’erreur fatale
EG(last_fatal_error_backtrace) survit à un OOM qui détruit le tas de la requête. Un diagnostic précoce dans la requête suivante suit le pointeur pendant. Cas démontré le plus solide : PHP 8.5 avec fatal_error_backtraces, RCE sur mod_php.
Cycle de vie de la progression d’envoi en session
Un état de session laissé par une requête interrompue est consommé par le traitement de progression d’envoi de la suivante. RCE confirmée sur mod_php et PHP-FPM.
Confusion de types dans la mémoire partagée d’OPcache
Un échec d’allocation entre l’incrément de CG(map_ptr_last) et la publication de la frontière partagée laisse des emplacements sur lesquels les workers sont en désaccord, si bien qu’un worker peut réutiliser un emplacement pour un autre type d’objet.
Autres états propres à la requête
L’avis décrit les familles d’état d’objet et d’extension comme exploitables sous conditions. Le correctif couvre le schéma, pas seulement ces chemins.
L’avis de PHP et l’article de Wiz regroupent certains chemins différemment. Le correctif traite le schéma de défaillance commun : ce regroupement ne change rien à ce que vous devez faire.
| Branche | Vulnérable | Corrigé dans |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.1 · 8.0 · 7.4 | toutes | Rétroportage source seulement |
| 5.4 – 7.3 | toutes | Aucun correctif |
| Configuration | …109619 | Remarques |
|---|---|---|
| Apache + mod_php | RCE confirmée | Les deux CVE ont été confirmées jusqu’à la RCE avec les limites par défaut. Configuration la plus à risque. |
| PHP-FPM (nginx, Apache, Caddy…) | RCE confirmée | RCE via le cycle de vie des sessions confirmée sur FPM. Chemin OOM confirmé via des chemins de code applicatifs ; aucun exploit FPM générique publié. |
| FrankenPHP / LiteSpeed LSAPI | Probable | L’avis les considère comme probablement exposés. Les workers de longue durée rendent l’état résiduel entre requêtes plus pertinent, pas moins. |
| CLI (cron, workers de file, artisan) | Non traité | Non traité par les avis et non joignable par des requêtes HTTP en usage normal. Mettez à jour quand même — c’est le même paquet. |
Vecteur : 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
| Métrique | Signification ici | Effet |
|---|---|---|
AV:N Attack Vector: Network | Joignable par Internet avec des requêtes HTTP ordinaires. | Augmente le score |
AC:H Attack Complexity: High | L’exploit doit être ajusté à la disposition mémoire de chaque cible ; ce n’est pas une requête à copier-coller. | Baisse le score |
AT:P Attack Requirements: Present | La réussite dépend de conditions de déploiement (SAPI, limites, réutilisation des workers) que l’attaquant ne contrôle pas. | Baisse le score |
PR:N Privileges Required: None | Pas de compte, pas de connexion. | Augmente le score |
UI:N User Interaction: None | Personne n’a besoin de cliquer. | Augmente le score |
VC:H / VI:H / VA:H Impact sur le système vulnérable : High | Perte totale de confidentialité, d’intégrité et de disponibilité sur le serveur PHP. | Augmente le score |
SC:N / SI:N / SA:N Impact sur les systèmes suivants : None | Le score ne compte pas le rebond vers d’autres systèmes — en pratique, des identifiants volés le permettent souvent. | Baisse le score |
La correction, c’est une mise à jour de PHP
Installez une version corrigée et redémarrez chaque worker PHP. Guide de mise à jour →
Si vous ne pouvez pas mettre à jour immédiatement, php.net liste ces mesures partielles :
session.upload_progress.enabled = 0 dans php.ini, le pool FPM ou la configuration serveur, puis redémarrage de chaque worker. Détails →fatal_error_backtraces = 0 puis redémarrage. Cela bloque uniquement le chemin confirmé des backtraces.error_reporting, display_errors ou @ n’aide pas.pm.max_requests = 1 si les performances le permettent.Oui. Un use-after-free entre requêtes peut exposer la mémoire du worker — mots de passe, clés d’API, jetons de session d’autres utilisateurs — sans que l’attaquant n’exécute jamais de code, ce qui complique la détection.
En partie. Cela bloque les chemins de session confirmés mais pas les autres variantes, et ne fonctionne que dans php.ini, le pool FPM ou la configuration serveur — pas dans .user.ini ni via ini_set() — suivi du redémarrage de chaque worker.
Oui. La RCE via le cycle de vie des sessions a été confirmée sur mod_php et sur PHP-FPM. Les workers FPM enchaînent de nombreuses requêtes, exactement ce dont l’état résiduel entre requêtes a besoin.
Cela réduit la durée de vie d’un état corrompu, et pm.max_requests = 1 supprime toute réutilisation des workers, au prix d’un coût élevé en performances. Cela n’aide pas contre les chemins qui n’ont besoin que d’une seule requête.