L’essentiel à retenir ℹ️
Le 21 octobre 2026, PHP a corrigé en urgence deux failles critiques (CVE-2026-109618 et CVE-2026-109619, surnommées PHP2Shell, notées 9,2 sur 10) qui permettent d’exécuter du code sur le serveur sans aucun compte. Les versions sûres sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Mettre WordPress à jour ne change rien : PHP tourne chez votre hébergeur. Vérifiez votre version dans Outils > Santé du site > Infos > Serveur, puis faites corriger PHP depuis votre panneau d’hébergement ou par le support.
Votre WordPress est en 7.1.3, vos extensions sont à jour, et pourtant votre site est peut-être ouvert à tous les vents depuis mardi. Le 21 octobre 2026, l’équipe de PHP a publié des correctifs d’urgence pour deux failles qui donnent les clés du serveur à un pirate, avec une seule requête et sans mot de passe. Les détails avaient fuité la veille, avant même que le correctif existe.
Le problème, c’est que ce correctif ne passe pas par votre tableau de bord WordPress. Je vous montre comment savoir en deux minutes quelle version de PHP fait tourner votre site, pourquoi le numéro affiché peut vous mentir, et comment obtenir la mise à jour chez votre hébergeur.
PHP2Shell : ce qui s’est passé le 21 octobre
PHP est le langage dans lequel WordPress est écrit. C’est lui qui, sur le serveur, transforme vos fichiers en pages web à chaque visite. Une faille dans PHP touche donc tout ce qui tourne dessus, quel que soit l’état de votre site.
Les deux failles corrigées jouent sur la gestion de la mémoire. La première (CVE-2026-109618) exploite le moment où PHP manque de mémoire en pleine requête : il laisse derrière lui des données à moitié initialisées, que le nettoyage traite ensuite comme valides. La seconde (CVE-2026-109619) profite d’un état interne qui survit à une requête terminée et qu’une requête suivante réutilise. Dans les deux cas, un attaquant habile peut en tirer une exécution de code à distance (remote code execution, ou RCE), sans authentification.
La chronologie mérite qu’on s’y arrête :
- Août 2026 : les chercheurs de Calif et de Wiz signalent les failles à l’équipe PHP, qui prépare les correctifs sous embargo.
- 20 octobre : les détails fuitent publiquement avant la date prévue. PHP avance sa publication.
- 21 octobre : sortie de PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, puis publication des analyses techniques.
Selon Sansec, le code fautif remonte à PHP 5.4, sorti en 2012, et la configuration par défaut est vulnérable. L’avis officiel juge le risque maximal avec Apache et mod_php, mais PHP-FPM, LiteSpeed et FrankenPHP figurent aussi dans le périmètre. Les chercheurs ont démontré l’attaque contre WordPress, Drupal, Joomla et Magento. Côté exploitation réelle, les sources divergent encore : Huntress n’avait rien observé chez ses clients le 21 octobre, d’autres signalent des premières attaques. Je ne parierais pas sur un répit.
Pourquoi mettre WordPress à jour ne vous protège pas
C’est le malentendu numéro un. WordPress, vos extensions et votre thème sont des fichiers posés dans votre espace d’hébergement. PHP, lui, est installé sur le serveur et géré par votre hébergeur. Le bouton « Mettre à jour » du tableau de bord ne le touche jamais. La démonstration de Sansec visait d’ailleurs WordPress 7.1.2 : la faille est déclenchée avant même que le moindre code de WordPress s’exécute.
Même punition pour le mode maintenance ou les extensions de sécurité installées dans WordPress : elles arrivent trop tard dans la chaîne. Si vous avez déjà lu mon article sur wp2shell, retenez la différence : wp2shell était une faille du cœur de WordPress, corrigée par une mise à jour de WordPress. PHP2Shell se corrige uniquement côté serveur.
Vérifier la version de PHP de votre site WordPress
Pas besoin d’outil externe, WordPress l’affiche lui-même :
- Ouvrez Outils > Santé du site dans l’administration.
- Cliquez sur l’onglet Infos.
- Dépliez la section Serveur et lisez la ligne Version de PHP.
Avec un accès SSH, WP-CLI donne la version utilisée par WordPress :
# Version de PHP vue par WordPress
wp eval 'echo PHP_VERSION . PHP_EOL;'
# Version du PHP en ligne de commande (peut différer de celle du site)
php -v
Petit conseil : fiez-vous à la Santé du site plutôt qu’à php -v. Sur beaucoup d’hébergements, le PHP de la ligne de commande n’est pas celui qui sert vos pages.
Lire le numéro : la branche et le correctif
Un numéro comme 8.3.36 se lit en deux temps. « 8.3 » est la branche, celle que vous choisissez dans votre panneau d’hébergement. Le « 36 » est le niveau de correctif, et c’est lui qui compte aujourd’hui. Voici le minimum à atteindre :
| Branche | Version corrigée | Support de sécurité jusqu’au |
|---|---|---|
| PHP 8.5 | 8.5.12 | 31 décembre 2029 |
| PHP 8.4 | 8.4.27 | 31 décembre 2028 |
| PHP 8.3 | 8.3.36 | 31 décembre 2027 |
| PHP 8.2 | 8.2.35 | 31 décembre 2026 |
| PHP 8.1 et avant | aucune version officielle | terminé |
Vous êtes en PHP 8.1, 8.0 ou 7.4 ? Le projet PHP n’a publié que des correctifs minimaux, à compiler soi-même. Pour un site WordPress chez un hébergeur, la seule voie réaliste est de changer de branche.
Le piège du numéro qui ne bouge pas
Un numéro inférieur à ceux du tableau ne prouve pas toujours que vous êtes vulnérable. Certains hébergeurs et distributions Linux rétroportent le correctif : ils l’appliquent à leur version de PHP sans changer le numéro. J’ai le cas sous les yeux. Le 22 octobre, mes sites hébergés chez o2switch affichaient encore PHP 8.3.35, mais avec des fichiers PHP recompilés le 21 octobre, le jour du correctif. Vous pouvez le constater vous-même sur la capture plus haut : la commande php -v affiche la date de compilation entre parenthèses, ici « built: Oct 21 2026 ». Correctif intégré ou simple reconstruction ? Le numéro ne permet pas de le savoir.
Dans ce cas, une seule méthode fiable : posez la question au support, en citant les deux identifiants CVE. Une réponse claire du type « corrigé le 21 octobre » vaut mieux que toutes les suppositions.
Un message court suffit, par exemple : « Bonjour, pouvez-vous me confirmer que la version de PHP qui sert mon site votre-site.fr intègre les correctifs des failles CVE-2026-109618 et CVE-2026-109619 publiés le 21 octobre 2026 ? Si oui, depuis quelle date ? » Conservez la réponse écrite, elle vous servira si un incident apparaît plus tard.
Mettre à jour PHP chez votre hébergeur
Premier réflexe avant toute manipulation : une sauvegarde complète du site, fichiers et base de données. Ensuite, tout dépend de votre type d’hébergement.
Hébergement mutualisé avec cPanel
Chez o2switch et la plupart des hébergeurs sous cPanel, l’outil PHP Selector (son nom varie d’un hébergeur à l’autre) vous laisse choisir la branche, pas le niveau de correctif. Ce dernier dépend de l’hébergeur, qui installe les correctifs pour tous ses clients. Concrètement, deux cas :
- Votre branche est 8.2 ou plus récente : vous attendez le correctif de l’hébergeur, et vous vérifiez auprès du support qu’il est en place.
- Votre branche est 8.1 ou plus ancienne : passez à une branche supportée dans le sélecteur, de préférence 8.3 ou 8.4, puis testez le site.
Hébergement WordPress infogéré
Chez un hébergeur spécialisé WordPress, PHP est entièrement entre ses mains. Inutile de chercher un bouton : consultez sa page d’état ou son blog, et à défaut écrivez au support. Un hébergeur sérieux communique sur ce genre d’alerte sous 48 heures.
VPS ou serveur dédié
Là, c’est vous l’hébergeur. Mettez à jour les paquets PHP de votre distribution, puis redémarrez le service qui exécute PHP (PHP-FPM ou Apache), sinon l’ancienne version reste chargée en mémoire :
# Debian / Ubuntu : mise à jour des paquets, puis redémarrage de PHP-FPM
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm # adaptez au numéro de votre branche
# Vérifiez ensuite la version servie dans Outils > Santé du siteAu passage, si vous utilisez le dépôt de Remi sur une distribution de type Red Hat, Sansec signalait qu’il n’avait pas encore les paquets corrigés le 21 octobre. Vérifiez avant de supposer.
En attendant le correctif : les mesures temporaires
Votre hébergeur traîne ? L’avis officiel de PHP et les chercheurs proposent des parades partielles. Soyons clairs, aucune ne remplace la mise à jour. La plus simple sur un hébergement mutualisé consiste à couper le suivi de progression des envois de fichiers, l’une des voies d’attaque documentées. Dans un fichier .user.ini à la racine du site (ou via les options du sélecteur PHP de cPanel) :
; Désactive le suivi de progression des envois (atténuation partielle PHP2Shell)
session.upload_progress.enabled = Off
Cette option ne sert à presque aucun site WordPress, vous ne perdrez rien. Les autres mesures évoquées, comme supprimer la limite de mémoire ou bloquer les envois de formulaires, se règlent côté serveur et cassent facilement un site. Je ne les recommande pas sur un mutualisé. Si votre site passe par Cloudflare, sachez enfin que des règles de pare-feu applicatif ont été déployées pour tous ses clients, offre gratuite comprise. C’est un filet, pas une protection garantie.
Votre site a-t-il déjà reçu de la visite ?
La mise à jour ferme la porte, elle ne met pas dehors un intrus déjà entré. Une fois PHP corrigé, prenez dix minutes pour un contrôle de base : comptes administrateurs inconnus dans Utilisateurs, fichiers PHP récents dans wp-content/uploads (ce dossier ne devrait contenir que des médias), tâches planifiées suspectes. Mon guide pour améliorer la sécurité de WordPress détaille les réglages à durcir ensuite.
Ce que je ferais à votre place
Aujourd’hui même : notez votre version de PHP dans la Santé du site et comparez-la au tableau. Si elle est inférieure, écrivez à votre hébergeur avec les deux CVE et demandez une réponse écrite. Si vous êtes encore en PHP 8.2, profitez-en pour viser la 8.4 : la 8.2 perd tout support le 31 décembre 2026, dans deux mois. Testez le changement de branche sur une copie du site, en suivant la même logique que pour une mise à jour de WordPress.
Et si je ne devais garder qu’un conseil : ne vous contentez pas du numéro. Entre les correctifs rétroportés et les PHP différents selon l’usage, seule une confirmation de l’hébergeur vous dit vraiment si vous êtes protégé.
Foire aux questions
Pas de façon fiable. Ces extensions s’exécutent à l’intérieur de WordPress, donc après PHP. Or l’attaque se déclenche pendant le traitement de la requête par PHP, avant que le code de WordPress ne démarre. Seule la mise à jour de PHP corrige la faille.
Un correctif à l’intérieur d’une même branche, par exemple de 8.3.35 à 8.3.36, ne casse pratiquement jamais rien. Un changement de branche, de 8.1 à 8.3 par exemple, peut révéler des extensions ou un thème trop anciens. Faites une sauvegarde et testez sur une copie du site avant de basculer.
Non. Sur WordPress.com, Automattic gère les serveurs et PHP pour vous. Le tutoriel concerne les sites WordPress.org auto-hébergés, chez un hébergeur mutualisé, infogéré ou sur votre propre serveur.
Parce qu’elle n’est pas conçue pour suivre les failles de PHP au jour le jour. Elle vous prévient surtout quand votre branche est trop ancienne par rapport aux recommandations de WordPress. Pour une alerte comme celle du 21 octobre, ne comptez pas sur elle : comparez vous-même le numéro affiché aux versions corrigées.
Oui. L’avis officiel de PHP inclut PHP-FPM, LiteSpeed, FrankenPHP et php-cgi dans le périmètre. Le risque est jugé maximal avec Apache et mod_php, mais aucune configuration n’est à l’abri tant que PHP n’est pas corrigé.
Visez une branche qui reçoit encore des correctifs de sécurité. PHP 8.3 et 8.4 sont un bon compromis entre compatibilité des extensions et durée de support, jusqu’à fin 2027 et fin 2028. Testez toujours le changement sur une copie du site.
Cherchez des comptes administrateurs que vous n’avez pas créés, des fichiers PHP dans wp-content/uploads et des tâches planifiées inconnues. En cas de doute, demandez à votre hébergeur d’examiner les journaux d’accès depuis le 20 octobre.
