Faille PHP et WordPress : vérifier sa version de PHP et la mettre à jour (php2shell)

Ne vérifiez que des systèmes qui vous appartiennent ou dont vous êtes responsable. Cette page et notre vérificateur comparent uniquement des numéros de version que vous saisissez vous-même, dans votre navigateur. Rien n’est testé, sondé ni analysé sur votre site.

Réponse courte

La faille « php2shell » (CVE-2026-109618 et CVE-2026-109619) se trouve dans PHP, le logiciel serveur sur lequel tourne WordPress. Elle n’est ni dans WordPress, ni dans votre thème, ni dans vos extensions. Wordfence le précise : les mises à jour automatiques de WordPress n’appliqueront pas ce correctif (Wordfence, traduction libre).

1. Ouvrez Outils > Santé du site > Info > Serveur et lisez la version de PHP.
2. Si elle est inférieure à 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou si vous êtes en 8.1 ou plus ancien, faites mettre PHP à jour chez votre hébergeur.
3. Faites une sauvegarde avant de changer de branche majeure de PHP.

Pourquoi c’est urgent : selon le PHP Group, ces failles peuvent permettre à une personne non authentifiée d’exécuter du code à distance sur le serveur (php.net). Le CERT-FR a publié une alerte (CERTFR-2026-ALE-014) : « PHP indique que les vulnérabilités CVE-2026-109618 et CVE-2026-109619 permettent à un attaquant de provoquer une exécution de code arbitraire à distance. » Le CERT-EU ajoute que des preuves de concept ont commencé à circuler (CERT-EU 2026-018). Pas de panique, mais ne remettez pas cela à la semaine prochaine. Contexte complet : php2shell, de quoi s’agit-il ?.

Étape 1 : lire sa version de PHP dans « Santé du site »

1. Connectez-vous à l’administration WordPress.
2. Allez dans Outils > Santé du site, ouvrez l’onglet Info, puis dépliez la section Serveur.
3. Repérez la ligne de la version de PHP (« PHP version » en anglais ; aide WordPress.org).

Pas d’accès à l’administration ? Le panneau de votre hébergeur affiche aussi la version de PHP choisie pour le site.

Deux pièges :

• « 8.3 ou supérieur » ne suffit plus. Être sur une branche récente ne protège pas à lui seul : pour cette faille, une 8.3 inférieure à 8.3.36 reste concernée.
• La ligne de commande peut différer du site. php -v dans un terminal peut afficher un autre PHP que celui qui sert votre site. Santé du site s’exécute dans la requête web : fiez-vous à lui pour le site.

Saisissez votre numéro dans le vérificateur pour le comparer aux versions corrigées. Sur un hébergement dont le PHP est rétroporté (par exemple cPanel pour 7.4, 8.0 et 8.1), le correctif ne change que le numéro de révision du paquet, pas le numéro affiché : seul l’hébergeur peut confirmer.

Étape 2 : savoir qui met PHP à jour chez vous

PHP est installé sur le serveur : vous le changez dans les réglages de votre hébergeur, ou c’est lui qui le fait (WordPress.org). Sur un VPS ou un serveur dédié que vous administrez, c’est à vous ou à votre prestataire (Wordfence). Dans un panneau comme cPanel, choisir une branche de PHP ne suffit pas : encore faut-il que l’hébergeur ait installé le paquet corrigé (voir plus bas).

Ce que disent les hébergeurs francophones

État au 22 octobre 2026, d’après leurs propres pages. Les hébergeurs mettent ces pages à jour : ouvrez le lien avant de décider. « Aucune déclaration trouvée » ne veut pas dire « pas corrigé » ; cela veut dire qu’il faut poser la question.

Les hébergeurs WordPress gérés ont aussi réagi, avec des formulations qui diffèrent : WordPress.com et Pressable parlent de sites « protégés » (sans numéro de version), WP Engine et Flywheel annoncent avoir terminé le déploiement des correctifs de sécurité PHP sur leur plateforme et aucune action requise, Kinsta indique que tous les sites sont protégés et que les mises à jour de sécurité PHP sont déployées sur toute la plateforme (incident résolu le 22/10 à 08 h 26 UTC) ; ses messages précédents listaient des correctifs pour PHP 7.4 à 8.5 et disaient que les mesures provisoires (pare-feu Cloudflare) restaient en place jusqu’à nouvel ordre, ce que le dernier message ne mentionne pas. Détail par hébergeur et date de vérification : état des hébergeurs. « Protégé » ou « en cours de déploiement » ne prouve pas que votre site tourne sur un PHP corrigé : relisez Santé du site, et si le numéro est encore concerné, demandez par écrit à quelle date votre offre recevra la version corrigée. Autres cas d’hébergement : guide hébergeurs.

Si votre hébergeur utilise cPanel, Plesk ou DirectAdmin

• cPanel : EasyApache 4 25.91 (21 octobre) corrige les paquets ea-php82 à ea-php85 (8.2.35, 8.3.36, 8.4.27, 8.5.12) et rétroporte le correctif pour ea-php74, ea-php80 et ea-php81 (notes de version cPanel).
• Plesk : correctifs disponibles pour PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 sous Linux et sous Windows ; sous Linux, 7.4.33, 8.0.30 et 8.1.34 gardent leur numéro et les builds du 21 octobre incluent les correctifs, Plesk demandant de mettre Plesk à jour vers la dernière version (base de connaissances Plesk).
• DirectAdmin : la mise à jour de PHP n’est pas automatique ; elle demande da update puis da build php, sauf si la tâche cron de CustomBuild est active ; la version publiée le 21 octobre ajoute aussi des correctifs pour PHP 8.1, 8.0 et 7.4 (forum DirectAdmin).
• Votre propre serveur : vérifier sa version de PHP, puis la marche à suivre générale dans php2shell : que faire.

Étape 3 : avant de changer de branche de PHP

Mettre à jour dans la même branche (par exemple 8.3.30 vers 8.3.36) est une mise à jour corrective, en principe moins risquée qu’un changement de branche. Si votre hébergeur propose déjà la version corrigée de votre branche, prenez-la d’abord. Passer à une autre branche (par exemple 8.1 vers 8.3) peut casser d’anciennes extensions et d’anciens thèmes. La liste de contrôle de WordPress.org (source), adaptée :

1. Sauvegardez les fichiers et la base de données. Pour un retour en arrière, l’hébergeur doit aussi remettre l’ancienne version de PHP.
2. Mettez à jour WordPress, le thème et les extensions (Tableau de bord > Mises à jour), puis vérifiez que le site fonctionne. Si l’hébergeur propose un environnement de préproduction (« staging »), testez-y le changement.
3. Lancez l’extension PHP Compatibility Checker. WordPress.org prévient qu’elle « n’est pas parfaite » (traduction libre) : elle peut rater des points ou signaler de faux problèmes. Pour chaque alerte, interrogez l’auteur de l’extension, ou remplacez-la si elle n’est plus maintenue.
4. Changez la version de PHP dans le panneau de l’hébergeur (ou demandez-le), puis chargez la page d’accueil, connectez-vous, testez les formulaires et le paiement si vous vendez en ligne.
5. En cas de problème, demandez à l’hébergeur de remettre l’ancienne version, puis restaurez la sauvegarde. Ne restez pas durablement sur une version concernée : corrigez l’extension, puis recommencez.

Vérifiez aussi que votre version de WordPress prend en charge la branche visée : la table de compatibilité de WordPress indique, branche par branche, à partir de quelle version de WordPress c’est le cas. Un WordPress récent est le choix le plus simple.

PHP 8.2 ne reçoit des correctifs de sécurité que jusqu’au 31 décembre 2026, 8.3 jusqu’au 31 décembre 2027 et 8.4 jusqu’au 31 décembre 2028 (versions supportées) : la 8.2 n’est qu’une étape courte. Si vous devez rester sur une branche sans version corrigée, aucune extension ne comblera le manque : demandez à l’hébergeur un correctif rétroporté ou une offre de support étendu.

Extensions de sécurité et pare-feu : un complément, pas la solution

• Le PHP Group est clair : « There are no complete mitigations, updating is the only safe choice » (php.net). En clair : aucune mesure d’atténuation ne suffit, seule la mise à jour corrige la faille.
• Wordfence a publié un avis après la sortie de PHP (21 octobre) : il demande de mettre PHP à jour et ne cite aucune règle de pare-feu. Un second article (22 octobre) indique que son pare-feu ne protège que la couche applicative de WordPress et qu’il est « essentiel » de mettre PHP à jour et de le redémarrer (Wordfence).
• Patchstack (21 octobre) : « Passez à PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou au paquet corrigé de votre fournisseur », et évitez les extensions « correctives » non officielles et les extraits de code copiés-collés (Patchstack, traduction libre).
• Si votre site passe par Cloudflare, des règles WAF gérées sont actives par défaut depuis le 21 octobre, mais Cloudflare demande de corriger PHP quand même (Cloudflare). Sucuri dit la même chose : sa protection « ne remplace pas la mise à jour de PHP sur votre serveur d’origine » (Sucuri, traduction libre).

Étape 4 : vérifier

1. Rechargez Outils > Santé du site > Info > Serveur et relisez la version de PHP.

2. Si vous administrez le serveur, redémarrez PHP (cela interrompt brièvement les requêtes) et contrôlez la version du paquet. Adaptez le nom du service à votre installation ; php -v montre le PHP de la ligne de commande, donc fiez-vous à Santé du site pour le site :

   sudo systemctl restart php8.3-fpm
   sudo systemctl restart apache2    # seulement avec mod_php
   php -v

   Sur une distribution, comparez avec la version de paquet corrigée du fournisseur, pas avec le numéro officiel : voir les versions corrigées.

3. Saisissez la version dans le vérificateur, puis ouvrez quelques pages de votre site pour confirmer que tout fonctionne.

Besoin d’un coup de main pour votre configuration ?

Si vous préférez ne pas déterminer seul les étapes pour votre hébergeur et votre version de WordPress, nous proposons un plan de correctif personnel à 49 dollars américains : les étapes écrites pour votre configuration exacte, envoyées par e-mail sous 24 h. Détails sur /fr/fix-service/. Nous ne nous connectons jamais à votre serveur.

Site indépendant, non affilié à WordPress.org, à Automattic, au PHP Group ni à php.net.