Failles PHP2Shell : correctifs publiés, exploitation facile contestée

PHP a corrigé le 21 octobre deux CVE touchant son moteur central, notées jusqu’à 9,2 sur l’échelle CVSS. Wiz affirme avoir exploité WordPress, Drupal et Joomla, mais Elias Taylor juge l’attaque trop difficile pour être banalisée.

Le 21 octobre 2026, PHP a publié le correctif de plusieurs failles de sécurité mémoire dans le moteur central du langage, selon Wiz. Les failles sont regroupées sous deux CVE, avec une sévérité allant jusqu’à 9,2 sur l’échelle CVSS. D’après Wired, les correctifs sont tombés juste avant 10 h, heure de la côte Est américaine, le mercredi.

Un périmètre très large

La PHP Foundation avait publié un préavis dès le 20 octobre, sans détails ni versions concernées. Elle qualifiait déjà les deux failles de critiques, avec un score CVSS de 9,2 sur 10.

Selon Wired, la fondation a ensuite détaillé les deux CVE. Elles touchent « toutes les installations PHP servant des requêtes web » depuis PHP 5, sorti en juillet 2004. Seules les versions 8.2 et plus récentes reçoivent toutefois des correctifs. Wiz indique de son côté que toutes les versions publiées durant la dernière décennie sont touchées par au moins une des failles, jusqu’à la version 5.4.

Comme la faille se trouve dans PHP lui-même, Wiz précise que même une simple application « Hello World » tournant sur une version affectée peut être vulnérable.

Wiz revendique des exploits fonctionnels

Wiz affirme avoir démontré une exécution de code à distance sans authentification sur WordPress, Drupal et Joomla. Les tests ont visé leurs images de conteneur les plus récentes au moment de l’essai.

L’entreprise explique que construire l’exploit a demandé d’enchaîner plusieurs failles et d’adapter l’attaque à la disposition mémoire de chaque cible. Les modèles d’IA de pointe ont permis d’y parvenir en quelques heures, d’après Wiz. L’entreprise ajoute que certaines failles sont exploitables assez facilement.

Les PoC publics sous le feu des critiques

Le ton est très différent chez Elias Taylor. Il affirme que des milliers de dépôts GitHub se présentent comme des PoC, mais qu’aucun ne fonctionne contre une instance PHP standard. Selon lui, beaucoup s’appuient sur une inclusion de fichier local (LFI), ce qui suppose que le serveur ait déjà une faille grave. Sa conclusion :

This is too difficult to exploit easily. It isn’t a Log4J moment.

Safeguard.sh tente de concilier les deux lectures. Le site distingue les PoC publics, jugés majoritairement défaillants, des exploits construits par les découvreurs. Il indique aussi que l’avis officiel PHP décrit une complexité d’attaque élevée, et que la portabilité des exploits dépend de la version de PHP, des extensions et de la mémoire.

Attaques : les signaux sont contradictoires

Sur le début des attaques, les sources ne disent pas la même chose. Cloudflare déclare observer des attaques naissantes avant la publication des détails et des correctifs par la PHP Foundation. Sansec écrit, cité par Wired :

We expect mass attacks to start within 15 minutes of the release

La PHP Foundation, citée par Safeguard.sh, dit au contraire n’avoir identifié aucun exploit fonctionnel à la publication. Des organisations ont néanmoins mis leurs sites hors ligne par précaution, dont plusieurs sites du gouvernement finlandais, d’après Wired citant Reuters.

Que faire maintenant

Sur ce point, les sources convergent. La PHP Foundation, citée par Wired, affirme :

« There are no complete mitigations, updating is the only safe choice« 

Safeguard.sh détaille la marche à suivre :

• mettre PHP à jour ;
• redémarrer les workers ;
• vérifier les journaux depuis le 17 octobre.

Les administrateurs de serveurs sous des versions antérieures à PHP 8.2 doivent retenir un point : selon Wired, ces branches ne reçoivent pas de correctifs. Pas simple quand des sites tournent sur ce type de version. Quoi qu’il en soit cela signifie une chose, c’est qu’il est important de maintenir ses serveurs, ses sites et l’ensemble de ses services à jour.