PHP2Shell : faille PHP critique d’exécution de code à distance (CVE-2026-109618, CVE-2026-109619)

Qu’est-ce que PHP2Shell ? Dernières nouvelles

Le 21 octobre 2026, le projet PHP a publié un avis de sécurité sur deux failles critiques du moteur d’exécution PHP permettant l’exécution de code à distance sans authentification. Le nom courant est PHP2Shell, « php2shell » chez la CISA.

PHP2Shell est-il exploité ?

• AWS MadPot a signalé une tentative d’exploitation le 17 octobre 2026, avant même la divulgation publique.
• Cloudflare, AWS et watchTowr décrivent d’importants volumes de tentatives d’exploitation après l’avis ; le PDG de Cloudflare a écrit le 22 octobre que les tentatives étaient passées de milliers à des millions.
• Aucune compromission confirmée de sites de production nommément connus n’est établie dans les sources examinées pour cette page. Selon des rapports secondaires, les CVE ne figuraient pas au catalogue KEV de la CISA le 22 octobre ; vérifiez vous-même le catalogue KEV.

Ma version de PHP est-elle affectée par PHP2Shell ?

Saisissez la version de PHP indiquée par votre SAPI web (php -v, panneau d’hébergement ou phpinfo()). Ce vérificateur compare uniquement des numéros de version avec les versions correctives amont. Il ne détecte pas les rétroportages des fournisseurs.

• Pages par branche : 8.5, 8.4, 8.3, 8.2, EOL 5–8.1.
• Vue d’ensemble : versions affectées.
• Panneau d’hébergement chinois : 宝塔面板.

Quels sites et éditeurs sont touchés par PHP2Shell ?

En savoir plus : état des éditeurs · évaluations des autorités.

Comment corriger PHP2Shell ?

1. Mettez à jour vers PHP **8.5.12**, **8.4.27**, **8.3.36** ou **8.2.35** (ou plus récent dans la même branche). Sources et builds Windows : téléchargements php.net.
2. Redémarrez chaque worker qui sert des requêtes (Apache avec mod_php, pools PHP-FPM, php-cgi, FrankenPHP, LiteSpeed, conteneurs).
3. PHP 8.1 et antérieures : obtenez un rétroportage du fournisseur, recompilez vos builds maison à partir des rétroportages minimaux du projet pour 7.4/8.0/8.1, ou mettez le service hors ligne jusqu’à la mise à niveau – conformément à la recommandation de la CISA pour les systèmes impossibles à mettre à jour.
4. Les règles WAF et les mesures provisoires php.ini de l’avis PHP ne réduisent que certains chemins. Ce ne sont pas des solutions complètes.

Pas à pas pour apt, yum, Docker, cPanel, Plesk et autres : remédiation.

Combien de serveurs sont exposés à PHP2Shell ?

Les estimations publiques sont élevées et ne comptent pas des sites effectivement piratés. The Record (citant une analyse VirusTotal) et un article de ThreatCluster évoquent tous deux environ **5,1 millions** d’adresses Internet identifiées comme PHP (selon ThreatCluster, seules 1,1 million environ exposent un en-tête de version). Une analyse citée plus tôt situait les estimations de type Censys à plus de **1,3 million** d’hôtes affectés. Les observations PHP récentes de Bitsight se concentrent sur les États-Unis, l’Allemagne, la France, les Pays-Bas et le Japon – ce n’est pas la preuve qu’un pays est « plus obsolète ».

Nous n’inventons **aucun** montant de dommages mondiaux. Tant qu’assureurs, gouvernements ou déclarations publiques n’auront pas publié de coûts attribuables, tout chiffre serait spéculatif.

Pourquoi PHP2Shell est-il plus difficile à contenir à l’ère de l’IA ?

• Les comptes rendus sur PHP2Shell (dont Wiz et l’article de The Record sur la PHP Foundation) décrivent comment des revues assistées par IA ont aidé à trouver des failles critiques dans un moteur vieux de plusieurs décennies. Les attaquants disposent du même levier : dès qu’un PoC existe, les scans et l’armement progressent plus vite que les cycles de correctifs manuels sur des hôtes oubliés.
• PHP non maintenu (5.x à 8.1 sans rétroportage) reste répandu sur l’hébergement mutualisé, les appliances et les CMS « installés une fois pour toutes ». Souvent, plus personne ne sait comment le mettre à jour – une RCE au niveau du langage devient alors un chantier de nettoyage à l’échelle d’Internet plutôt qu’un simple correctif applicatif.
• La leçon pratique pour les exploitants : inventorier chaque endroit où PHP est embarqué, corriger le jour de l’avis et retirer les branches que le projet PHP ne livre plus. La leçon pour le secteur : l’IA raccourcit le délai entre découverte et exploitation ; la latence des correctifs sur les systèmes anciens est la véritable surface d’attaque.