Faille PHP2Shell : pourquoi votre site WordPress ou PrestaShop doit passer à jour maintenant

Le 21 octobre 2026, l’équipe de développement de PHP a publié en urgence des correctifs pour deux failles critiques, surnommées « PHP2Shell » : CVE-2026-109618 et CVE-2026-109619. Quelques jours plus tard, l’agence américaine de cybersécurité CISA les ajoutait à sa liste des vulnérabilités activement exploitées.

Si votre site tourne sous WordPress, PrestaShop, Joomla ou tout autre outil écrit en PHP, il est concerné. Voici ce qu’il faut savoir, sans jargon.

Ce que permettent ces failles

PHP est le langage qui fait fonctionner une très grande partie des sites web, dont la quasi-totalité des sites WordPress et PrestaShop. Les deux failles permettent une exécution de code à distance sans authentification : un attaquant peut, en envoyant une simple requête bien construite, faire exécuter ses propres commandes sur le serveur, sans identifiant et avant même que le code de votre site ne s’exécute.

Concrètement, cela peut mener à :

• l’installation d’un logiciel malveillant ou d’une porte dérobée sur le serveur ;
• le vol de données (comptes clients, commandes, e-mails) ;
• la défiguration du site ou son utilisation pour envoyer du spam ;
• une pénalité ou un avertissement « site dangereux » de la part de Google.

D’où viennent les deux failles ?

Les deux problèmes touchent la façon dont PHP gère la mémoire entre et pendant les requêtes, au cœur du moteur et non dans une extension particulière :

• CVE-2026-109618 : lorsque PHP manque de mémoire au milieu de la préparation d’une requête, des données internes peuvent rester à moitié initialisées. Le code de nettoyage les traite ensuite comme valides.
• CVE-2026-109619 : des données internes liées à une requête peuvent survivre après la libération de leur mémoire. Une requête suivante traitée par le même processus PHP peut alors réutiliser cet état périmé.

C’est pour cela qu’un correctif « dans le code de votre site » ne suffit pas : c’est PHP lui-même, sur le serveur, qui doit être mis à jour.

Ces failles ont été jugées parmi les plus graves jamais découvertes dans PHP. Le cabinet watchTowr leur attribue un score de gravité CVSS de 9,2 sur 10, et des tentatives d’exploitation ont été observées dès la publication des correctifs.

Quelles versions sont touchées ?

Branche PHP	Version corrigée	Statut
PHP 8.5	8.5.12 et plus	Corrigée
PHP 8.4	8.4.27 et plus	Corrigée
PHP 8.3	8.3.36 et plus	Corrigée
PHP 8.2	8.2.35 et plus	Corrigée (fin de support fin 2026)
PHP 8.1, 8.0, 7.4	Pas de version officielle	Correctifs « à compiler » seulement, branches plus maintenues
PHP 7.3 et plus ancien	Aucun correctif	Migration indispensable

Toutes les versions antérieures aux numéros indiqués ci-dessus sont vulnérables. Pour les branches anciennes, l’équipe PHP n’a publié que des correctifs minimaux à compiler soi-même, réservés aux administrateurs système. La CISA va jusqu’à recommander de mettre hors ligne les systèmes en PHP 8.1 ou antérieur tant qu’ils ne sont pas mis à jour.

Que faire pour votre site ?

1. Vérifier la version de PHP utilisée

• WordPress : menu Outils → Santé du site → Infos → Serveur.
• PrestaShop : menu Paramètres avancés → Informations.
• Hébergement OVH, o2switch, etc. : la version PHP est indiquée dans l’espace client, souvent dans la configuration de l’hébergement ou du « multisite ».

2. Mettre à jour PHP (ou demander à l’hébergeur)

• Sur un hébergement mutualisé, c’est l’hébergeur qui installe les correctifs de PHP. Vérifiez qu’il l’a fait et, si votre site est configuré sur une vieille branche (7.4, 8.0, 8.1), passez à une branche maintenue (8.3 ou 8.4 par exemple).
• Sur un serveur dédié ou un VPS, installez les versions corrigées via les paquets de votre distribution, puis redémarrez tous les processus PHP (PHP-FPM, Apache…) : un processus resté en mémoire continue d’utiliser l’ancien code.

3. Vérifier la compatibilité de votre site

Passer d’un vieux PHP 7.4 à PHP 8.3 n’est pas anodin : certains thèmes, extensions WordPress ou modules PrestaShop anciens ne sont pas compatibles et peuvent provoquer une page blanche. D’où l’intérêt de :

• faire une sauvegarde complète (fichiers + base de données) avant toute intervention ;
• mettre à jour le CMS, le thème et les extensions en même temps ;
• tester le site sur une copie avant de basculer en production quand c’est possible.

4. Ajouter une protection en attendant

Si la mise à jour ne peut pas être faite immédiatement, un pare-feu applicatif (WAF) peut offrir une protection partielle : Cloudflare a par exemple déployé des règles contre les vecteurs d’attaque connus, y compris pour ses offres gratuites. Mais selon l’équipe PHP, aucun réglage de configuration ne corrige complètement ces failles : seule la mise à jour règle le problème.

5. Surveiller les signes d’intrusion

Fichiers PHP inconnus, comptes administrateurs ajoutés, redirections suspectes, pics d’envoi d’e-mails : au moindre doute, un site peut avoir été compromis avant la mise à jour et doit être vérifié, voire nettoyé.

Notre conseil

Cette affaire rappelle une réalité simple : un site non mis à jour finit tôt ou tard par subir une faille de sécurité. La meilleure protection reste une maintenance régulière du PHP, du CMS et des extensions, avec des sauvegardes systématiques.

Vous ne savez pas quelle version de PHP fait tourner votre site, ou vous êtes encore en PHP 7.x ? Nous pouvons vérifier, mettre à jour et sécuriser votre site WordPress ou PrestaShop, et gérer la migration vers une version de PHP maintenue : découvrez notre offre Mises à jour & sécurité WordPress / PrestaShop.

---

Sources : CISA, alerte du 21 octobre 2026 (mise à jour le 26 octobre) · Help Net Security, 21 octobre 2026 · watchTowr, FAQ CVE-2026-109618 · Notes de version PHP 8.2.35