Faille PHP2Shell : mettre PHP à jour sur WordPress, PrestaShop et votre hébergement

En bref

Le 21 octobre 2026, l’équipe de PHP a publié en urgence des correctifs pour deux failles critiques, enregistrées sous les références CVE-2026-109618 et CVE-2026-109619 et surnommées « PHP2Shell ». Une seule requête HTTP suffit à faire exécuter des commandes par un serveur qui n’est pas à jour, sans identifiant ni mot de passe. Des tentatives d’exploitation automatisées sont déjà observées.

Ce guide s’adresse aux clients d’un hébergement web mutualisé, d’un hébergement WordPress, d’un hébergement e-commerce PrestaShop, ainsi qu’aux administrateurs d’un serveur VPS ou d’un serveur dédié. Il complète les guides pour renforcer durablement la sécurité de son hébergement et détecter et traiter un malware avec Imunify360.

• Gravité : 9,2 sur 10 (CVSS 4.0). Exécution de code à distance, sans authentification.
• Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou toute version plus récente de la même branche.
• PHP 8.1, 8.0, 7.x et plus ancien ne reçoivent aucun correctif : il faut changer de branche, ce qui concerne directement les boutiques PrestaShop 1.6, 1.7 et 8.
• Les attaques sont menées par des robots : un site vitrine de cinq pages est testé comme une grande boutique.

PHP2Shell, qu’est-ce que c’est ?

PHP est le langage qui construit chaque page de votre site côté serveur. PHP2Shell désigne deux failles de ce langage qui permettent à un attaquant d’envoyer une requête conçue pour faire exécuter ses propres commandes par votre serveur. C’est ce que les spécialistes appellent une exécution de code à distance (RCE).

Le surnom dit l’essentiel : de PHP à un « shell », c’est-à-dire à un accès en ligne de commande sur la machine. Une fois cet accès obtenu, l’attaquant n’a plus besoin de votre mot de passe d’administration : il lit les fichiers, la base de données et les clés de configuration directement, et il peut installer une porte dérobée qui survivra à la correction.

Les deux failles sont distinctes mais ont le même effet. La première (CVE-2026-109618) exploite une interruption pour manque de mémoire pendant qu’une requête est partiellement initialisée. La seconde (CVE-2026-109619) exploite un état interne qui survit d’une requête à la suivante dans le même processus PHP-FPM. Aucune des deux ne dépend du CMS installé.

Pourquoi c’est urgent

Trois éléments font de PHP2Shell une alerte à traiter le jour même, et pas à la prochaine maintenance :

• La méthode d’attaque est publique. Une démonstration a circulé avant même la sortie des correctifs. Les robots qui parcourent le web l’ont intégrée en quelques heures.
• Les attaques ont commencé. Des tentatives d’exploitation contre des sites ordinaires ont été observées dès l’annonce, et le CERT-FR a publié une alerte (CERTFR-2026-ALE-014) demandant d’appliquer les correctifs sans délai.
• Elles sont automatiques. Les robots ne choisissent pas leurs cibles. Ils testent des milliers d’adresses à la chaîne et retiennent celles qui répondent.

Les sites les plus exposés sont ceux qui ont été livrés puis laissés sans maintenance, en particulier lorsqu’ils tournent encore sous PHP 8.1 ou une version plus ancienne.

Quelles versions de PHP sont concernées ?

Toutes les branches de PHP sont touchées. Le tableau indique la version minimale à atteindre pour chaque branche encore maintenue.

Une mise à jour dans la même branche, par exemple de 8.2.20 à 8.2.35, ne contient que des corrections : elle ne casse presque jamais un site. Changer de branche, de 8.1 à 8.2 ou au-delà, est une autre affaire : le thème, les extensions ou modules et le code sur mesure doivent être compatibles, ce qui se teste avant.

Votre site est-il concerné ?

WordPress et WooCommerce

Oui, comme tout site WordPress hébergé sur un serveur que vous ou votre prestataire gérez. La bonne nouvelle : un WordPress à jour fonctionne avec toutes les branches corrigées, et le passage à la dernière version de votre branche est en général sans surprise. Le point de vigilance, ce sont les extensions et les thèmes abandonnés par leur éditeur, qui peuvent ne pas suivre si vous devez changer de branche. Le guide pour mettre à jour WordPress, les thèmes et les extensions décrit la méthode.

PrestaShop

C’est le cas le plus délicat, parce que chaque version de PrestaShop ne fonctionne qu’avec certaines versions de PHP.

Une boutique en PrestaShop 1.7 ou 8 ne peut donc pas simplement « mettre PHP à jour » : elle s’arrêterait de fonctionner. La vraie solution est la migration vers PrestaShop 9. En attendant, le pare-feu applicatif Imunify360 et une restriction d’accès au back-office réduisent le risque, mais ne le suppriment pas.

Drupal, Joomla, Magento, Laravel, Symfony et les sites sur mesure

Tous fonctionnent avec PHP, donc tous sont concernés. Le cadre applicatif n’y change rien : c’est le PHP du serveur qui compte. Comme pour WordPress, la difficulté dépend de l’écart entre votre branche actuelle et une branche corrigée.

Node.js, Python et sites statiques

Une application Node.js ou Python n’exécute pas PHP et n’est pas concernée par cette faille. Attention toutefois aux serveurs mixtes : un VPS qui héberge une application Node.js et un WordPress reste exposé par le WordPress.

Site IA (Sitejet), Shopify, Wix, Squarespace

Un site créé avec le constructeur Site IA est publié sur votre hébergement NovaHoster et dépend donc de la version de PHP de votre abonnement : vérifiez-la comme pour n’importe quel site. Les plateformes hébergées comme Shopify ou Wix gèrent leurs propres serveurs : vous n’avez rien à mettre à jour vous-même.

Vérifier la version de PHP de votre site

Deux minutes suffisent. La seule version qui compte est celle qui sert les pages du site, pas celle de la ligne de commande.

Depuis Plesk

Connectez-vous à Plesk depuis l’Espace client NovaHoster (le guide pour se connecter à Plesk et retrouver les réglages d’un site détaille l’accès). Dans Sites web & domaines, la version de PHP est affichée sous le nom de chaque domaine, à côté de « PHP ». Cliquez sur Paramètres PHP pour voir la version exacte, par exemple « 8.3.36 », et le mode d’exécution (FPM). Chaque domaine et chaque sous-domaine peut avoir sa propre version : vérifiez-les tous, y compris les sites de test.

Depuis WordPress

Dans l’administration, ouvrez Outils, puis Santé du site, puis l’onglet Infos. La section Serveur affiche la version de PHP utilisée par le site.

Depuis PrestaShop

Dans le back-office, ouvrez Paramètres avancés, puis Informations. La version de PHP figure dans le bloc consacré au serveur.

En ligne de commande (VPS, serveur dédié, accès SSH)

Si vous avez un accès SSH :

php -v
# PHP 8.2.35 (cli) …

Cette commande donne la version utilisée en ligne de commande, qui n’est pas toujours celle qui sert les pages. Sur un serveur Plesk, plusieurs versions cohabitent dans /opt/plesk/php/ ; vérifiez la version déclarée pour chaque site dans Plesk, ou listez les processus PHP-FPM actifs :

ls /opt/plesk/php/*/bin/php | xargs -n1 -I{} {} -v | grep ^PHP
systemctl list-units 'plesk-php*-fpm*'

Si la version affichée est plus ancienne que celles du tableau, ou si vous ne savez pas qui gère votre serveur, considérez que votre site est exposé.

Changer la version de PHP dans Plesk

Sur un hébergement mutualisé NovaHoster, les versions corrigées sont déployées côté serveur : vous n’avez rien à installer. En revanche, c’est vous qui choisissez la branche utilisée par chaque site. Un site réglé sur PHP 8.1 ou plus ancien reste vulnérable tant que vous ne l’avez pas basculé.

1. Dans Plesk, ouvrez Sites web & domaines, puis le domaine concerné, puis Paramètres PHP.
2. Dans la liste Version de PHP, choisissez la branche cible, par exemple « 8.3 (FPM, servie par nginx) ». Laissez le mode FPM sélectionné.
3. Cliquez sur OK ou Appliquer. Le changement est immédiat et ne coupe pas le site plus de quelques secondes.
4. Rechargez la page d’accueil, l’administration, un formulaire et, pour une boutique, le panier et le paiement.
5. Ouvrez les journaux du domaine (Journaux dans Plesk) et lisez les erreurs PHP des minutes qui suivent. Un avertissement « Deprecated » est tolérable ; un « Fatal error » signale une extension ou un module incompatible.
6. En cas de problème, revenez à la version précédente de la même manière, le temps de corriger. Le retour arrière prend un clic.

Que faire selon votre offre NovaHoster

Hébergement web mutualisé, WordPress, e-commerce et revendeur

Les correctifs de PHP sont appliqués sur les serveurs par les équipes NovaHoster, sur toutes les branches maintenues proposées dans Plesk. Votre action se limite à vérifier que chaque site utilise une branche 8.2 ou plus récente, et à le basculer dans le cas contraire. Les comptes sont isolés par CloudLinux, LVE et CageFS : un site vulnérable chez un voisin de serveur ne donne pas accès au vôtre, mais il ne protège pas votre propre site s’il est resté sur une vieille branche.

Revendeurs : vos clients sont vos sites

Un compte revendeur regroupe plusieurs abonnements, chacun avec sa propre version de PHP. Passez en revue chaque abonnement depuis Plesk, et prévenez vos clients dont le site doit changer de branche : c’est à eux de valider la compatibilité de leur thème et de leurs extensions.

VPS ou serveur dédié avec infogérance

L’infogérance serveur couvre la mise à jour du système et de PHP : les correctifs sont appliqués et les services PHP-FPM redémarrés par nos techniciens. Vous recevez une confirmation dans votre Espace client. La compatibilité de vos applications avec une nouvelle branche reste de votre ressort, avec notre aide si vous le demandez.

VPS ou serveur dédié sans infogérance

Personne ne le fera à votre place. Mettez PHP à jour aujourd’hui, puis redémarrez les services qui l’utilisent pour que la nouvelle version soit bien chargée. Sur un serveur Plesk, la mise à jour passe par l’installateur Plesk :

plesk installer update
systemctl restart 'plesk-php*-fpm*'

Sur un serveur sans panneau, utilisez le gestionnaire de paquets de votre distribution (apt, dnf) ou votre dépôt PHP, puis redémarrez PHP-FPM et le serveur web. Si vous ne savez pas qui administre ce serveur, c’est le signe qu’il n’est plus maintenu : une offre d’infogérance serveur règle ce point durablement.

Conteneurs Docker

Mettre à jour l’hôte ne suffit pas : reconstruisez vos images à partir d’une image PHP corrigée (par exemple php:8.3-fpm dans sa dernière révision), puis redéployez. Une image construite il y a six mois contient le PHP d’il y a six mois.

Site encore sur PHP 8.1 ou plus ancien

Planifiez la migration vers une branche maintenue, et posez une protection temporaire en attendant : le pare-feu applicatif Imunify360, actif sur les hébergements mutualisés, filtre une partie des tentatives ; limitez l’accès au back-office par adresse IP ou mot de passe HTTP ; mettez le site en maintenance si rien d’autre n’est possible. Le CERT-FR demande d’isoler les systèmes qui ne peuvent pas être corrigés. Pour une boutique PrestaShop 1.7 ou 8, la migration gratuite vers un hébergement à jour ne suffit pas : c’est la boutique elle-même qui doit passer en PrestaShop 9.

Mettre PHP à jour sans casser son site

Une mise à jour dans la même branche est simple. Un changement de branche demande de la méthode :

1. Faites une sauvegarde complète, fichiers et base de données, et vérifiez qu’elle se restaure. La sauvegarde automatique NovaHoster conserve des copies quotidiennes hors de votre hébergement ; le guide pour sauvegarder, migrer et restaurer un site décrit la restauration.
2. Testez sur une copie du site avec la nouvelle version de PHP avant de toucher au site en ligne.
3. Vérifiez la compatibilité du thème, des extensions ou modules et du code sur mesure. Un module abandonné par son éditeur est le blocage le plus fréquent.
4. Parcourez les fonctions qui rapportent : formulaire de contact, panier, paiement, espace client, envoi des e-mails.
5. Lisez le journal d’erreurs PHP après la bascule : les avertissements annoncent souvent les pannes du lendemain. Le guide pour lire les logs et diagnostiquer une application explique où les trouver.
6. Gardez un retour arrière : dans Plesk, revenir à la version précédente prend un clic, le temps de corriger.

Savoir si votre site a déjà été attaqué

Mettre PHP à jour ferme la porte, mais ne fait pas sortir un attaquant déjà entré. Vérifiez ces signes :

• une alerte Imunify360 dans Plesk, ou un e-mail de NovaHoster signalant un fichier malveillant ;
• un compte administrateur que vous ne connaissez pas, dans WordPress, PrestaShop ou dans Plesk ;
• des fichiers PHP récents dans des dossiers qui ne devraient contenir que des images ou des documents, comme wp-content/uploads/ ou img/ sur PrestaShop ;
• des fichiers du site modifiés à une date où personne n’y a travaillé (dans le gestionnaire de fichiers de Plesk, triez par date) ;
• des pages que vous n’avez pas créées dans les résultats de Google, souvent en langue étrangère : tapez site:votre-domaine.fr dans Google pour les repérer ;
• une alerte dans la rubrique « Problèmes de sécurité » de la Search Console ;
• un site qui redirige certains visiteurs, souvent seulement sur mobile, vers une autre adresse ;
• des e-mails du site qui arrivent en indésirables chez vos clients, ou un avertissement sur des envois massifs ;
• une consommation CPU ou des limites LVE atteintes sans raison, visibles dans Plesk, signe possible d’un programme installé à votre insu.

L’absence de ces signes ne prouve rien : un attaquant discret ne laisse pas de trace visible. Seule une analyse des fichiers et des journaux permet de conclure. Le guide pour détecter et traiter un malware avec Imunify360 détaille la marche à suivre quand une alerte est levée.

Votre site a été piraté : que faire

1. Isolez le site : mise en maintenance ou mise hors ligne, pour arrêter les dégâts.
2. Conservez les traces : copiez les journaux et les fichiers avant de nettoyer. Ils servent à comprendre l’attaque et, le cas échéant, à porter plainte.
3. Corrigez PHP avant de restaurer, sinon le site sera repris dans l’heure.
4. Restaurez une sauvegarde saine, antérieure à l’intrusion, plutôt que de tenter de nettoyer fichier par fichier.
5. Changez tous les accès : comptes d’administration, base de données, FTP et SSH, mots de passe Plesk, et les clés des services reliés au site (paiement, CRM, e-mailing, transporteurs).
6. Notifiez la CNIL sous 72 heures si des données personnelles ont pu être consultées ou volées, et prévenez les personnes concernées si le risque pour elles est élevé.
7. Faites-vous accompagner : le dispositif public cybermalveillance.gouv.fr oriente les entreprises victimes vers des prestataires et explique comment porter plainte. Le support NovaHoster peut fournir les journaux du serveur et vérifier qu’aucune porte dérobée ne subsiste ; voyez comment ouvrir une demande de support pour que la demande soit traitée vite.

Après la mise à jour : la liste de contrôle

• La version de PHP affichée dans Plesk pour chaque domaine et sous-domaine est une version corrigée.
• Les mots de passe et les clés d’accès sensibles ont été changés.
• La liste des comptes administrateurs a été relue, dans le CMS et dans Plesk.
• Aucun fichier PHP inconnu ne se trouve dans les dossiers d’envoi de fichiers.
• Le formulaire de contact, le panier et le paiement fonctionnent.
• Une sauvegarde récente et testée existe.
• Quelqu’un est désigné pour la prochaine alerte, parce qu’il y en aura une.

Cas d’erreur et diagnostic

Quand contacter l’Espace client NovaHoster

Contactez NovaHoster si la branche corrigée n’apparaît pas dans Plesk, si vous ne parvenez pas à identifier la version de PHP qui sert votre site, si une alerte Imunify360 est levée, si le site reste en erreur après le changement de version, ou si vous souhaitez qu’un technicien vérifie l’absence de porte dérobée à partir des journaux. Indiquez le domaine, la version de PHP actuelle et cible, le CMS et sa version, et l’heure du changement. Ne transmettez jamais de mots de passe.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

• Sécuriser un serveur VPS Linux en 30 minutes : la liste de contrôle après la livraison — Sécuriser un VPS Debian, Ubuntu ou AlmaLinux en 30 minutes : mises à jour, sudo, clés SSH, pare-feu, fail2ban, mises à jour automatiques,…
• Détecter et traiter un malware avec Imunify360 — Apprenez à interpréter une alerte Imunify360, vérifier un fichier infecté, utiliser la quarantaine et sécuriser votre site sans supprimer…
• Comprendre CloudLinux, LVE et CageFS — Découvrez comment CloudLinux limite les ressources et isole les comptes d’hébergement avec LVE et CageFS, ainsi que les symptômes d’une…
• Administrer un abonnement Plesk sans interrompre son site — Découvrez une méthode fiable pour administrer un abonnement Plesk, modifier les réglages d’un domaine et limiter les risques avant chaque…
• Changer d’hébergeur WordPress sans perdre son référencement : la méthode complète, phase par phase — Changer d’hébergeur WordPress sans perdre son référencement : préparation, copie, test, bascule DNS avec TTL abaissé, vérifications SEO et…

Sources techniques

[1] php.net — annonce des versions de sécurité 8.5.12, 8.4.27, 8.3.36 et 8.2.35 (21 octobre 2026) [2] Avis de sécurité PHP — CVE-2026-109618 [3] Avis de sécurité PHP — CVE-2026-109619 [4] CERT-FR (ANSSI) — alerte CERTFR-2026-ALE-014 [5] Plesk — Paramètres PHP par domaine [6] CNIL — notifier une violation de données personnelles [7] Cybermalveillance.gouv.fr — assistance aux victimes