Votre site tourne probablement en PHP. Depuis le 21 octobre 2026, cette information compte plus que d'habitude.
Deux failles critiques ont été publiées ce jour-là dans le langage qui fait tourner une grande partie du web, dont tous les sites WordPress. Elles portent les identifiants CVE-2026-109618 et CVE-2026-109619, et le surnom qui circule déjà dans la communauté sécurité est explicite : PHP2Shell.
Ce que permettent ces failles
Un attaquant peut exécuter du code sur votre serveur à distance, sans compte ni mot de passe. L'équipe sécurité de PHP leur attribue une note de 9,2 sur 10 selon l'échelle CVSS v4.0, ce qui les place dans la catégorie critique (Tenable, octobre 2026).
La première faille concerne la gestion des erreurs de mémoire. La seconde vient du fait que PHP conserve des informations liées à une requête alors que la mémoire correspondante a déjà été libérée. Dans les deux cas, le résultat est le même : quelqu'un d'extérieur peut faire exécuter ses propres instructions par votre serveur.
Le détail le plus inquiétant est ailleurs. Sur certaines configurations, notamment Apache avec mod_php, l'attaque peut se déclencher avant même que le code de votre site ne s'exécute (Qualys, octobre 2026).
Un plugin de sécurité ne vous protégera pas
Beaucoup de propriétaires de sites WordPress pensent être couverts parce qu'ils ont installé une extension de sécurité. Face à ce type de faille, on pense que c'est un faux sentiment de sécurité.
Un plugin fait partie de votre site. Il s'exécute après PHP, avec PHP, et dépend entièrement de lui. Si l'attaque frappe le moteur avant que votre site ne démarre, le plugin n'a tout simplement pas l'occasion d'intervenir. C'est comme poser une alarme dans une maison dont les fondations s'effondrent.
Seule la mise à jour de PHP corrige le problème.
Pourquoi il faut agir maintenant
Des détails ont fuité avant la sortie du correctif, ce qui a obligé l'équipe PHP à avancer sa publication d'un jour. Les premières tentatives d'exploitation ont été observées dès le 21 octobre (watchTowr, octobre 2026), et Cloudflare a de son côté repéré du trafic d'attaque visant ces failles.
Et la taille de votre site ne change rien. Les attaques sont automatisées : des robots parcourent le web et testent chaque serveur qui répond, qu'il héberge une boutique en ligne ou la vitrine d'un artisan.
Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Toute version inférieure dans la même branche est exposée.
Qui est concerné
Presque tout le monde. Les versions touchées vont de PHP 5.4 jusqu'à PHP 8, et toutes les installations qui servent des pages web sont à risque, quel que soit le mode de fonctionnement du serveur : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP ou LiteSpeed.
Le cas des anciennes versions est plus délicat. PHP 8.1 et les versions antérieures ne sont plus maintenues, et ne recevront donc pas de mise à jour officielle. Des correctifs minimaux ont été publiés pour PHP 7.4, mais ils ne remplacent pas un vrai passage sur une version supportée. Laisser un site sur une version de PHP abandonnée n'est pas une économie. C'est un risque qu'on repousse, jusqu'au jour où il se matérialise.
Comment faire la mise à jour
La démarche dépend de votre hébergement, mais elle commence toujours de la même façon.
- Identifier la version réellement utilisée par le site. La commande php -v en ligne de commande ne donne pas toujours la version qui sert les pages. Vérifiez dans l'interface de votre hébergeur, ou dans WordPress via Outils, puis Santé du site, onglet Infos, rubrique Serveur.
- Sur un hébergement mutualisé (cPanel, Plesk et équivalents), c'est l'hébergeur qui installe le correctif. Ouvrez le sélecteur de version PHP et vérifiez la version exacte proposée pour votre branche. Si aucune version corrigée n'apparaît, contactez le support pour connaître le délai.
- Sur un serveur dédié ou un VPS, passez par le gestionnaire de paquets : apt update puis apt upgrade sous Debian ou Ubuntu, dnf upgrade sous Rocky Linux ou AlmaLinux. Les distributions intègrent souvent le correctif sans changer le numéro de version affiché : consultez leurs bulletins de sécurité pour vérifier que les deux CVE sont bien corrigées. Redémarrez ensuite PHP-FPM ou Apache.
- Avec Docker, mettez à jour l'image PHP vers un tag corrigé, reconstruisez puis redéployez. Une image qui n'est pas reconstruite garde l'ancienne version.
- Si vous changez de branche, par exemple de 8.1 vers 8.3, faites d'abord une sauvegarde complète et testez le site sur une copie : extensions, thème, formulaires, paiement. Une mise à jour dans la même branche ne change rien au fonctionnement. Un changement de branche peut casser un vieux plugin.
- Revérifiez la version servie par le site une fois l'opération terminée. C'est la seule preuve que le correctif est en place.
Ce que cette alerte rappelle
Un site n'est pas un projet qu'on livre puis qu'on oublie. Il repose sur un langage, un serveur, des extensions, et chacune de ces briques vieillit à son rythme, avec ses propres failles qui finissent un jour par être découvertes.
La maintenance ne se voit pas. Elle se remarque le jour où elle manque.
Si vous ne savez pas quelle version de PHP fait tourner votre site, posez la question aujourd'hui à votre prestataire ou à votre hébergeur. C'est une question simple, et elle mérite une réponse claire.
