Votre site tourne sous WordPress, Drupal, Joomla ou un autre CMS en PHP ? Le projet PHP vient de corriger les failles PHP2Shell, qui permettent d’exécuter du code à distance sans authentification, directement dans le langage. Voici ce qu’il faut savoir et surtout, ce que vous devez faire dès que possible si vous êtes concerné.
L’essentiel en bref
- Le projet PHP a publié le 21 octobre 2026 les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent les failles PHP2Shell.
- Les failles PHP2Shell se situent dans le moteur PHP lui-même : mettre à jour WordPress, Drupal ou Joomla ne suffit pas à s’en protéger.
- Selon php.net, seule la mise à jour de PHP corrige complètement les deux failles.
Failles PHP2Shell dans PHP : ce qu’il faut savoir
- Deux failles critiques notées 9,2 sur 10 (CVSS v4) : selon l’avis de PHP (CVE-2026-109618 et CVE-2026-109619), elles permettent d’exécuter du code sur le serveur sans authentification.
- Toutes les installations PHP qui servent des pages web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP juge le risque le plus élevé avec mod_php.
- Le CMS ne vous protège pas : Wiz, qui a révélé les failles, dit avoir pris le contrôle d’images récentes de WordPress, Drupal et Joomla.
- Les données en mémoire sont aussi exposées : Wiz a démontré qu’un attaquant peut lire la mémoire du processus PHP, susceptible de contenir mots de passe, jetons et clés d’API.
- Aucune exploitation active n’est confirmée par php.net : Cloudflare dit toutefois observer du trafic d’attaque visant ses clients.
Les alertes que nous relayons, comme la faille critique qui touchait 5 millions de sites WordPress, se réglaient le plus souvent depuis le tableau de bord du CMS. PHP2Shell se loge une couche plus bas : le correctif passe par l’hébergeur ou le serveur.
Source : php.net, octobre 2026
Vous gérez un parc de sites clients ? Traitez d’abord ceux sur Apache avec mod_php : le projet PHP y a validé une attaque qui se déclenche avant même le code de l’application.
Les sites en PHP-FPM suivent, sans attendre : l’analyse du code les rend vulnérables, même si aucune attaque complète n’y a été démontrée.
Comment vérifier votre version de PHP selon votre situation ?
- Site WordPress : Outils, puis « Santé du site », onglet « Informations », section « Serveur ». Sous Drupal : Rapports, puis « Rapport d’état ».
- Hébergement mutualisé : la version s’affiche dans l’espace client, mais elle ne dit pas toujours si le correctif est appliqué. Demandez une confirmation écrite au support.
- VPS ou serveur dédié : php -v en SSH donne la version en ligne de commande, parfois différente de celle servie par PHP-FPM ou Apache. Les distributions Linux corrigent souvent sans changer ce numéro : vérifiez le paquet dans leur avis de sécurité.
- Site derrière Cloudflare : selon Cloudflare, des règles de pare-feu applicatif sont actives depuis le 21 octobre, offre gratuite comprise. Un filet, pas un correctif.
À faire dès aujourd’hui
- 1 Relever la version de PHP réellement servie par chaque site, via le CMS, l’hébergeur ou le serveur.
- 2 Installer la version corrigée de votre branche ou le paquet corrigé de votre distribution, puis redémarrer PHP-FPM ou Apache.
- 3 Faute de mise à jour immédiate, appliquer les réglages provisoires de php.net, dont session.upload_progress.enabled=0 dans php.ini, puis redémarrer tous les workers.
- 4 Surveiller les journaux : requêtes multipart suivies d’erreurs de limite mémoire, erreurs 500 répétées, cookies PHPSESSID anormalement longs, signaux cités par Wiz.
Vous préférez couper un site le temps du correctif, comme l’ont fait des administrations et hôpitaux européens selon Reuters ? John Mueller (Google) conseille de renvoyer un code HTTP 503 plutôt qu’un délai d’attente, un 404 ou un 500.
Ce 503 peut être servi hors de PHP, depuis le CDN ou via le DNS, précise-t-il. Google a déjà indiqué que ce statut doit rester une affaire d’heures, pas de semaines.
Réglages provisoires, vieilles versions, WAF : les limites des parades
- Les réglages provisoires ne rendent pas un serveur sûr : php.net précise qu’ils bloquent des chemins d’attaque connus, pas toutes les variantes.
- PHP 8.1 et antérieurs n’ont plus de versions officielles : des correctifs minimaux existent en code source pour 7.4, 8.0 et 8.1, pour qui compile PHP. Sinon, distribution, support étendu ou migration.
- Les règles WAF peuvent être contournées : Cloudflare dit avoir vu des attaquants modifier leurs requêtes pour échapper à ses protections.
Mon avis :
PHP2Shell justifie de passer en revue dès aujourd’hui chaque site PHP dont vous avez la charge, à une condition : contrôler la version servie par le serveur, pas celle de WordPress. C’est la priorité des freelances, agences et équipes qui gèrent leurs propres VPS (un site chez un hébergeur qui a confirmé le correctif par écrit est moins urgent). À votre place, je demanderais cette confirmation à chaque hébergeur, je traiterais les serveurs en mod_php en premier et je ne couperais un site qu’en 503, pour quelques heures au plus.
