Faille PHP2Shell : votre site est-il vulnérable?

PHP2Shell est une faille PHP, pas une faille WordPress. Elle touche PHP lui-même, le langage qui fait tourner WordPress sur le serveur, et elle permet d’y exécuter du code à distance, sans compte ni mot de passe. Pensez à un immeuble : la faille est dans la serrure de la porte d’entrée, pas dans celle de votre appartement. Changer vos clés, c’est-à-dire mettre WordPress et ses extensions à jour, ne la répare pas. Le correctif s’installe sur le serveur, par votre hébergeur ou par la personne qui gère ce serveur. Vérifier si votre site est touché prend deux minutes, et c’est par là qu’il faut commencer.

Ce que la faille PHP2Shell permet à un attaquant

PHP2Shell regroupe deux failles, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 par l’équipe de PHP. Une requête bien construite, envoyée à n’importe quelle page du site, peut amener le serveur à exécuter les commandes de l’attaquant. Tout se joue au moment où PHP lit la requête, avant même que WordPress démarre. Une extension de sécurité comme Wordfence arrive donc trop tard : elle se lance après cette lecture.

Une fois son code exécuté, l’attaquant peut faire tout ce que le site peut faire. Glisser des pages de pourriel dans votre site. Y cacher un logiciel malveillant qui s’en prend à vos visiteurs. Lire la base de données, et avec elle les demandes reçues par vos formulaires. Ou enrôler le serveur dans un réseau d’appareils piratés : des tentatives d’installer Mirai, un logiciel de ce genre, ont déjà été rapportées.

Le risque n’a rien de théorique. Amazon a repéré une première tentative d’attaque quatre jours avant l’annonce officielle. Le jour de l’annonce, Cloudflare a vu les tentatives passer de quelques dizaines de milliers en 45 minutes à des millions en moins d’une journée. Palo Alto Networks recense plus de 22 millions d’installations exposées sur Internet. Les chercheurs notent qu’une attaque fiable est plus difficile à écrire que prévu, et plusieurs observateurs n’ont vu que des balayages, sans prise de contrôle confirmée. C’est une raison de ne pas paniquer, pas une raison d’attendre.

Toutes les versions de PHP qui servent des pages web sont touchées, depuis PHP 5.4, quelle que soit la façon dont le serveur fait tourner PHP. L’équipe de PHP a publié quatre versions corrigées :

Pour PHP 7.4 à 8.1, l’équipe de PHP n’a publié que des correctifs à compiler soi-même. Certains hébergeurs et distributions Linux les ont intégrés, mais ces branches ne reçoivent plus rien d’autre. C’est le moment d’en sortir.

Comment savoir si votre site est vulnérable

Dans le tableau de bord de WordPress, ouvrez Outils › Santé du site, puis l’onglet Informations. Dépliez la section Serveur : la ligne « Version de PHP » donne le numéro complet. Comparez-le au tableau ci-dessus, jusqu’au dernier chiffre : 8.4.26 est vulnérable, 8.4.27 ne l’est plus.

Deux pièges attendent ceux qui s’arrêtent là.

Le premier se trouve dans l’onglet État de la même page. WordPress y affiche « Votre site utilise une version recommandée de PHP » même pour une version vulnérable. Il juge la branche (8.3, 8.4), pas les correctifs installés. Nous avons interrogé le service de WordPress.org qui fournit ce verdict : il considère PHP 8.4.26 comme sûr. Le feu vert de Santé du site ne dit rien sur PHP2Shell.

Le deuxième touche les serveurs qui reçoivent PHP d’une distribution Linux. Ubuntu, par exemple, corrige les failles sans changer le numéro affiché. Un serveur Ubuntu 24.04 corrigé affiche toujours 8.3.6, alors que la version corrigée par PHP porte le numéro 8.3.36. Le correctif se trouve dans le paquet installé, invisible depuis WordPress. C’est aussi le cas des vieilles versions de PHP que certains hébergeurs maintiennent eux-mêmes. Si votre numéro est plus bas que celui du tableau, votre site est peut-être vulnérable, peut-être pas : seul votre hébergeur, ou la personne qui gère le serveur, peut trancher.

Sans accès à WordPress, le panneau de votre hébergeur indique aussi la version de PHP, mais parfois seulement la branche, sans le dernier chiffre. La question à l’hébergeur reste alors la seule façon d’être fixé.

Corriger la faille PHP chez votre hébergeur

Sur un hébergement mutualisé ou un hébergement WordPress infogéré, vous ne choisissez pas le dernier chiffre de la version. Le panneau vous laisse choisir la branche, 8.3 ou 8.4 par exemple. Les correctifs à l’intérieur de cette branche, c’est l’hébergeur qui les installe sur ses serveurs. Ce n’est pas un bouton que vous auriez oublié.

Écrivez donc au support, avec une question à laquelle on ne peut pas répondre à côté : « Les versions de PHP de mon compte incluent-elles les correctifs des failles CVE-2026-109618 et CVE-2026-109619? Depuis quand? » Gardez la réponse écrite. Un hébergeur sérieux a corrigé dans les jours qui ont suivi l’annonce, et il sait le dire en une phrase. Un hébergeur qui ne sait pas répondre à cette question vous a déjà répondu. Notre article sur le choix d’un hébergement web vous aidera à en trouver un autre.

Si votre site tourne encore sur PHP 8.1 ou plus ancien, un correctif de l’hébergeur ne fait que gagner du temps : c’est à vous de changer de branche, dans le panneau, pour 8.3 ou 8.4. Ne le faites pas à l’aveugle. Une vieille extension ou un vieux thème peut ne pas suivre et afficher une erreur. Faites d’abord l’essai sur une copie du site, comme pour une mise à jour majeure (nous l’expliquons dans notre article sur les mises à jour de WordPress). Si la copie fonctionne, changez la version du site en ligne, puis refaites le tour de vos pages clés et de vos formulaires.

Poser la bonne question à l’hébergeur, tester sur une copie, vérifier après : si vous préférez que quelqu’un d’autre s’en charge, c’est le genre de suivi qu’on confie à une maintenance de site WordPress.

Corriger soi-même sur votre serveur

Si votre site tourne sur un serveur infonuagique que vous gérez, vous ou votre développeur, personne ne fera la mise à jour à votre place. Sur Ubuntu ou Debian, deux commandes suffisent, en remplaçant 8.3 par votre branche :

sudo apt update
sudo apt install --only-upgrade 'php8.3*'

Redémarrez ensuite PHP. C’est l’étape qu’on oublie : tant que les processus de PHP tournent, ils gardent l’ancien code en mémoire, et le serveur reste vulnérable même avec le nouveau paquet installé.

sudo systemctl restart php8.3-fpm

Si PHP tourne comme module d’Apache, c’est Apache qu’on redémarre (sudo systemctl restart apache2). Vérifiez ensuite la version du côté web, dans Santé du site, et pas seulement avec php -v : la ligne de commande et le site n’utilisent pas forcément la même installation de PHP. Sur Ubuntu, où le numéro ne bouge pas, apt policy php8.3-fpm donne la version du paquet installé, à comparer avec l’avis de sécurité d’Ubuntu. Debian 12 et 13 ont reçu les versions officielles 8.2.35 et 8.4.27. Le dépôt d’Ondřej Surý, très utilisé pour installer des versions récentes de PHP, suit lui aussi les numéros officiels.

Avec Docker, redémarrer le conteneur ne change rien. Il faut télécharger l’image corrigée et recréer le conteneur (docker compose pull, puis docker compose up -d).

Si vous ne pouvez pas mettre à jour tout de suite, un réglage réduit le risque en attendant. Ajoutez-le au fichier php.ini qu’utilise le site web, pas à celui de la ligne de commande, puis redémarrez PHP :

session.upload_progress.enabled = 0

Sur PHP 8.5, ajoutez aussi fatal_error_backtraces = 0. Ce réglage ferme une des voies d’attaque, pas les deux. L’équipe de PHP le dit sans détour : aucun réglage ne rend une installation sûre, seule la mise à jour le fait. Le même réglage protège aussi d’une troisième faille, annoncée deux jours plus tard (CVE-2026-115560) : elle ne touche que des configurations inhabituelles et sera corrigée dans la prochaine version régulière de PHP.

Cloudflare, un rempart en attendant

Si votre site passe par Cloudflare, vous avez une protection de plus. Cloudflare a ajouté des règles contre PHP2Shell à son pare-feu quelques heures avant l’annonce officielle. Elles s’appliquent à tous les forfaits, y compris le forfait gratuit, sans rien activer. Sur un forfait payant, vérifiez que l’ensemble de règles géré (Managed Ruleset) est bien réglé pour bloquer.

Cette protection a deux limites. Elle ne vaut que pour les visites qui passent par Cloudflare : si votre serveur répond aussi à qui l’appelle directement par son adresse IP, un attaquant peut faire le tour. Et un pare-feu reconnaît des attaques connues. Cloudflare a déjà vu des attaquants modifier leurs requêtes pour passer à côté de ses règles, qu’il ajuste au fur et à mesure. C’est une clôture autour de la maison, pas une nouvelle serrure. Notre article Cloudflare : à quoi ça sert pour votre site? explique ce qu’il protège et ce qu’il ne remplace pas.

Si votre site a déjà été visé

Une mise à jour ferme la porte. Elle ne fait pas sortir quelqu’un qui serait déjà entré. Si votre site a tourné sur une version vulnérable, prenez le temps de chercher des traces :

• un compte administrateur que vous ne connaissez pas, dans Utilisateurs (filtrez par rôle);
• des fichiers .php dans le dossier wp-content/uploads, qui ne devrait contenir que des images et des documents;
• des fichiers de WordPress ou d’extensions modifiés : l’analyse de Wordfence les signale, tout comme les commandes wp core verify-checksums et wp plugin verify-checksums --all de WP-CLI;
• dans les journaux d’erreurs du serveur, des rafales du message « Allowed memory size … exhausted » suivi de « Unknown on line 0 », un signe de tentative.

Si vous trouvez quelque chose, ne vous contentez pas de supprimer le fichier suspect. Mettez PHP à jour, restaurez une sauvegarde d’avant l’intrusion, puis changez tous les mots de passe : administrateurs, base de données, hébergement, sans oublier les clés de sécurité du fichier wp-config.php. Si la base contenait des demandes de formulaire, l’intrusion est aussi un incident de confidentialité au sens de la Loi 25, avec des obligations précises que nous détaillons dans notre article sur la Loi 25.

Et si rien ne cloche, notez la date de votre vérification et la réponse de votre hébergeur. À la prochaine faille, vous saurez déjà à qui écrire et quoi lui demander.