PHP2Shell : deux failles RCE critiques corrigées en urgence dans PHP 8.x

Deux failles, une même cause

Le 21 octobre 2026, l’équipe sécurité de PHP a publié en urgence des correctifs pour deux vulnérabilités critiques, CVE-2026-109618 et CVE-2026-109619, regroupées sous le nom PHP2Shell. Toutes deux permettent une exécution de code à distance sans authentification, avec les privilèges du compte qui fait tourner le serveur web. Elles ont été découvertes par des chercheurs de Calif, de Wiz et d’OpenAI, rapporte Bleeping Computer.

L’origine est commune : lorsqu’une requête se termine anormalement, PHP peut laisser sa mémoire dans un état corrompu. La première faille enchaîne plusieurs faiblesses pour provoquer une corruption liée à l’épuisement de la mémoire. La seconde repose sur un état global périmé et ouvre un use-after-free sur le tas, une divulgation de mémoire et, au bout de la chaîne, l’exécution de code.

Toutes les installations qui servent des requêtes web sont touchées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L’équipe PHP juge le risque le plus élevé pour mod_php, avec un exploit démontré où une requête non authentifiée déclenche l’attaque avant même que le code de l’application ne s’exécute.

Les versions à installer

Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. PHP 8.1 et antérieurs ne reçoivent plus de mises à jour du projet ; certaines distributions et fournisseurs LTS rétroportent des correctifs, ce qu’il faut vérifier auprès d’eux. Compte tenu de la gravité, l’équipe sécurité a tout de même publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, à destination de ceux qui compilent eux-mêmes ou n’ont pas de fournisseur LTS. Pour qui tourne encore en PHP 7, la consigne reste de migrer vers une version corrigée.

La veille, mardi, les développeurs de PHP avaient déjà prévenu : tous les utilisateurs devaient se préparer à mettre à jour dès la sortie des correctifs, et l’équipe se réservait le droit de publier plus tôt si des détails devenaient publics ou si une exploitation active était constatée. Avant même la publication, Cloudflare a confirmé par la voix de son directeur technique observer de premières attaques visant les deux failles, malgré des règles WAF déployées pour bloquer les méthodes d’exploitation connues, protections qu’il a lui-même qualifiées de temporaires. Le NCSC britannique recommande de mettre à jour immédiatement ou de mettre les systèmes hors ligne tant qu’ils ne sont pas corrigés.

Ce que vous pouvez faire en attendant

Pour les serveurs que vous ne pouvez pas mettre à jour tout de suite, l’équipe PHP a listé des mesures qui réduisent l’exposition à certains chemins d’attaque, sans protéger entièrement. Un membre de l’équipe cœur de PHP l’a dit sans détour : aucune atténuation ne bloque totalement les attaques, seul le correctif officiel est une défense permanente.

Pour CVE-2026-109618 : passer memory_limit à -1, de préférence d’une façon que les applications ne peuvent pas surcharger, via php_admin_value dans le pool FPM ou la configuration Apache ; abaisser post_max_size à 8M si l’application ne reçoit pas de fichiers, 32M sinon ; poser une limite de conteneur ou de cgroup comme borne de disponibilité, idéalement avec une politique qui ne tue que le worker concerné.

Pour CVE-2026-109619 : passer session.upload_progress.enabled à 0 puis redémarrer tous les workers ; sur PHP 8.5, passer fatal_error_backtraces à 0 et redémarrer, ce qui ne ferme que le chemin confirmé des traces d’erreurs fatales ; retirer les réglages invalides ou dépréciés appliqués par requête qui émettent des diagnostics avant l’initialisation. Masquer ces diagnostics avec error_reporting, display_errors ou l’opérateur @ ne sert à rien. Enfin, corriger les erreurs fatales et les dépassements de délai qu’un attaquant peut atteindre, y compris dans les callbacks, le traitement des envois ou des imports et le nettoyage.

L’ordre des opérations

Si vous administrez des serveurs PHP, la séquence raisonnable ce 21 octobre tient en quatre temps : inventorier les versions en production, mettre à jour tout ce qui tourne en 8.2 ou plus récent, contacter le fournisseur de la distribution pour le reste, et n’appliquer les atténuations qu’à ce qui doit attendre. Le périmètre justifie l’effort : PHP fait tourner 75 à 80 % des sites web, dont ceux sous WordPress, Joomla et Drupal, et VirusTotal estime à plus de 5,1 millions le nombre d’hôtes PHP exposés en ligne, dont environ 3,8 millions avec au moins un port ouvert.

L’équipe PHP s’était donné jusqu’à la première exploitation constatée pour publier plus tôt que prévu. Les attaques relevées par Cloudflare avant la sortie des correctifs indiquent que ce délai s’est refermé en moins d’une journée.