Le 21 octobre 2026, deux vulnérabilités critiques du cœur de PHP ont été rendues publiques sous le nom PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Ensemble, elles permettent à un attaquant non authentifié d'exécuter du code sur le serveur, sans aucune action de la part d'un utilisateur.
Ce qui se passe
Les deux failles partagent une même cause. Lorsque PHP rencontre une condition fatale, il ne remonte pas l'erreur dans la pile d'appels comme il le devrait. Trois situations suffisent à déclencher cet état : un dépassement de la mémoire allouée, un dépassement du temps d'exécution, ou une connexion client interrompue.
À partir de là, la gestion des sessions, le cache de classes d'OPcache et la génération de la trace d'erreur peuvent être détournés jusqu'à l'exécution de code arbitraire.
Les failles ont été découvertes à l'aide d'outils d'analyse assistée par IA, puis divulguées par Wiz avec OpenAI et d'autres acteurs.
Gravité et portée
Les développeurs de PHP classent les deux failles à 9,2 sur l'échelle CVSS v4.0. Les chercheurs de watchTowr les évaluent à 10,0. Des démonstrations d'exploitation ont été publiées contre WordPress, Drupal et Joomla, entre autres.
Les estimations de portée varient selon les sources : Wiz indique que les versions à partir de PHP 5.4 sont concernées, sans que chaque version ait été testée individuellement.
Les versions corrigées
Les correctifs sont disponibles dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Si vous êtes sur une de ces branches, la mise à jour règle le problème.
Si vous êtes sur PHP 8.1 ou antérieur, il n'y a pas de correctif officiel. Ces branches ne sont plus maintenues. La seule voie est de demander un rétroportage à votre hébergeur, ou de monter de version.
Pourquoi votre code n'y peut rien
C'est le point qui surprend le plus souvent : aucune correction applicative ne protège contre PHP2Shell. La faille est dans l'interpréteur, pas dans ce qu'il exécute. Auditer son propre code ne sert à rien ici — il faut mettre à jour PHP.
En attendant la mise à jour, Cloudflare a déployé des règles de pare-feu applicatif par défaut pour tous ses clients, y compris les comptes gratuits. C'est une mesure de réduction du risque, pas un correctif.
Ce qu'on recommande de faire aujourd'hui
Vérifiez votre version. En ligne de commande, php -v. Comparez au numéro corrigé de votre branche.
Mettez à jour sans attendre une fenêtre de maintenance confortable. Des exploitations ont été observées avant même la publication officielle, et des outils d'attaque sont désormais publics.
Si votre branche n'est plus supportée, traitez-le comme une urgence et non comme un sujet de planning. Aucun correctif ne viendra.
Regardez vos journaux. Des erreurs fatales inhabituelles liées à la mémoire ou au temps d'exécution, autour des dates de divulgation, méritent un examen.
La leçon de fond
PHP2Shell rappelle que la sécurité d'une application ne se joue pas seulement dans son code. Elle dépend aussi de la discipline avec laquelle on tient à jour ce sur quoi elle repose. Les projets qui suivaient déjà leurs versions ont appliqué un correctif en une heure. Les autres découvrent qu'ils sont sur une branche abandonnée.
Sources : Wiz, Sansec, JFrog Security Research, Help Net Security, Cloudflare, Imperva, CrowdStrike.