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 suffit à prendre le contrôle d’un serveur qui n’est pas à jour, sans identifiant ni mot de passe. Des attaques sont déjà en cours.
Ce guide répond aux questions que nous posent nos clients depuis l’annonce : qui est touché, comment le vérifier en deux minutes, quoi faire selon votre hébergement, comment savoir si votre site a déjà été visé, et que faire s’il l’a été. Il est tenu à jour au fil des annonces officielles.
En bref
- La faille se trouve dans PHP lui-même, le langage qui fait tourner WordPress, PrestaShop, Drupal, Joomla, Magento et la plupart des sites développés sur mesure. Mettre à jour son CMS ou ses extensions ne suffit pas.
- Elle est notée 9,2 sur 10 et permet d’exécuter des commandes sur le serveur à distance, sans authentification.
- Les versions corrigées sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou plus récentes.
- PHP 8.1 et les versions plus anciennes ne recevront pas de correctif : il faut changer de version, ce qui concerne directement les boutiques PrestaShop 1.7 et 8.
- Les attaques sont automatisées : la taille du site ne protège pas.
PHP2Shell, qu’est-ce que c’est ?
PHP est le langage qui exécute le code de votre site sur le serveur : chaque fois qu’un visiteur ouvre une page, PHP construit cette page. PHP2Shell désigne deux failles dans ce langage. Elles permettent à un attaquant d’envoyer une requête qui fait exécuter ses propres commandes par votre serveur. C’est ce que les spécialistes appellent une exécution de code à distance.
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 connaître votre mot de passe d’administration : il lit les fichiers, la base de données et les clés de configuration directement.
Nous ne détaillons pas ici le fonctionnement technique de l’attaque. Il est documenté dans les sources officielles citées en fin d’article, et il ne sert à rien pour protéger un site : ce qui compte, c’est la version de PHP qui tourne sur votre serveur.
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. N’importe qui peut désormais la reproduire.
- Les attaques ont commencé. Cloudflare a observé des tentatives d’exploitation contre les sites de ses clients dès l’annonce.
- Elles sont automatiques. Des robots parcourent le web et testent des milliers de sites à la chaîne. Ils ne choisissent pas leurs cibles : un site vitrine de cinq pages est testé comme une grande boutique.
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 ?
| Branche de PHP | Version corrigée | Ce qu’il faut faire |
|---|---|---|
| PHP 8.5 | 8.5.12 ou plus récente | Appliquer la mise à jour |
| PHP 8.4 | 8.4.27 ou plus récente | Appliquer la mise à jour |
| PHP 8.3 | 8.3.36 ou plus récente | Appliquer la mise à jour |
| PHP 8.2 | 8.2.35 ou plus récente | Appliquer la mise à jour |
| PHP 8.1, 8.0, 7.x et plus ancien | Aucune | Passer à une branche maintenue, et protéger le site en attendant |
Une version de la même branche, par exemple de 8.2.20 à 8.2.35, ne change 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 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 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.
Les sites hébergés directement sur WordPress.com sont gérés par la plateforme : vous n’avez pas la main sur PHP, et donc rien à mettre à jour vous-même.
PrestaShop
C’est le cas le plus délicat, parce que chaque version de PrestaShop ne fonctionne qu’avec certaines versions de PHP.
| Version de PrestaShop | PHP le plus récent pris en charge | Situation face à PHP2Shell |
|---|---|---|
| PrestaShop 1.6 et 1.7 | PHP 7.x selon la version mineure | Aucun PHP corrigé possible : migration nécessaire |
| PrestaShop 8 | PHP 8.1 | Aucun PHP corrigé possible : migration nécessaire |
| PrestaShop 9 | PHP 8.4 | Passer sur PHP 8.2.35, 8.3.36 ou 8.4.27 |
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, que nous détaillons dans notre guide pour migrer vers PrestaShop 9. En attendant, une protection temporaire réduit le risque, mais ne le supprime pas.
Drupal, Joomla, Magento et les sites sur mesure
Tous fonctionnent avec PHP, donc tous sont concernés. Un site développé avec Laravel ou Symfony l’est aussi : 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.
Shopify, Wix, Squarespace, Webflow
Ces plateformes hébergent votre site sur leurs propres serveurs et ne vous donnent pas la main sur le langage. Vous n’avez pas de PHP à mettre à jour : la correction, s’il y a lieu, leur revient.
Comment connaître la version de PHP de votre site
Deux minutes suffisent. Choisissez la méthode qui correspond à votre site.
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.
Depuis l’espace client de votre hébergeur
Tous les hébergeurs affichent la version de PHP de chaque site, souvent dans une rubrique « Configuration », « Langages » ou « Version de PHP ». C’est aussi là que vous pourrez la changer sur un hébergement mutualisé.
En ligne de commande
Si vous avez un accès SSH :
$ php -v
PHP 8.2.35 (cli) …Attention : cette commande donne la version utilisée en ligne de commande, qui n’est pas toujours celle qui sert les pages du site. Sur un serveur où plusieurs versions cohabitent, vérifiez aussi la version déclarée pour le site lui-même dans la configuration du serveur ou dans l’espace client.
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é.
Que faire maintenant, selon votre hébergement
Hébergement mutualisé
Les hébergeurs mutualisés appliquent eux-mêmes les correctifs de PHP sur les branches qu’ils proposent. Mais c’est vous qui choisissez la branche dans votre espace client. Si votre site est réglé sur PHP 8.1 ou plus ancien, l’hébergeur ne peut pas le corriger à votre place : il faut passer sur une branche maintenue, après avoir vérifié que le site la supporte. Demandez aussi par écrit à votre hébergeur à quelle date le correctif a été déployé.
Hébergement infogéré
Votre prestataire gère le serveur : écrivez-lui pour obtenir la confirmation que PHP est passé sur une version corrigée, et la date. Si votre contrat ne couvre que le système et pas l’application, la question de la compatibilité de votre site reste à votre charge.
Serveur dédié ou VPS
Personne ne le fera à votre place. Faites mettre PHP à jour aujourd’hui par la personne qui administre le serveur, puis redémarrez les services qui l’utilisent pour que la nouvelle version soit bien chargée. Si vous ne savez pas qui administre ce serveur, c’est le signe qu’il n’est plus maintenu.
Conteneurs Docker
Mettre à jour l’hôte ne suffit pas : reconstruisez vos images à partir d’une image PHP corrigée, puis redéployez. Une image construite il y a six mois contient le PHP d’il y a six mois.
PHP 8.1 ou plus ancien
Planifiez la migration vers une branche maintenue, et faites poser une protection temporaire en attendant : filtrage des requêtes par un pare-feu applicatif, restriction de l’accès aux zones sensibles, voire mise en maintenance. Le CERT-FR, rattaché à l’ANSSI, demande d’isoler les systèmes qui ne peuvent pas être corrigés. Le NCSC, l’agence britannique de cybersécurité, recommande même de mettre ces sites hors ligne si ni la mise à jour ni une protection temporaire ne sont possibles.
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 :
- Faites une sauvegarde complète : fichiers et base de données, et vérifiez qu’elle se restaure.
- Testez sur une copie du site avec la nouvelle version de PHP avant de toucher au site en ligne.
- 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.
- Parcourez les fonctions qui rapportent : formulaire de contact, panier, paiement, espace client, envoi des e-mails.
- Lisez le journal d’erreurs PHP après la bascule : les avertissements annoncent souvent les pannes du lendemain.
- Gardez un retour arrière : sur la plupart des hébergements, revenir à la version précédente prend un clic, le temps de corriger.
Comment 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 :
- un compte administrateur que vous ne connaissez pas, dans WordPress, PrestaShop ou sur le serveur ;
- des fichiers PHP récents dans des dossiers qui ne devraient contenir que des images ou des documents, comme les dossiers d’envoi de fichiers ;
- des fichiers du site modifiés à une date où personne n’y a travaillé ;
- des pages que vous n’avez pas créées dans les résultats de Google, souvent en langue étrangère ou à vocation commerciale douteuse : tapez
site:votre-domaine.frdans 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 de votre hébergeur sur des envois massifs ;
- un serveur anormalement lent, 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 du serveur permet de conclure.
Votre site a été piraté : que faire
- Isolez le site : mise en maintenance ou mise hors ligne, pour arrêter les dégâts.
- Conservez les traces : copiez les journaux et les fichiers avant de nettoyer. Ils servent à comprendre l’attaque et, le cas échéant, à porter plainte.
- Corrigez PHP avant de restaurer, sinon le site sera repris dans l’heure.
- Restaurez une sauvegarde saine, antérieure à l’intrusion, plutôt que de tenter de nettoyer fichier par fichier.
- Changez tous les accès : comptes d’administration, base de données, FTP et SSH, et les clés des services reliés au site (paiement, CRM, e-mailing, transporteurs).
- 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é.
- Faites-vous accompagner : le dispositif public cybermalveillance.gouv.fr oriente les entreprises victimes vers des prestataires et explique comment porter plainte.
Après la mise à jour : la liste de contrôle
- La version de PHP affichée par le site, et pas seulement par le serveur, 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.
- 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.
Ce qu’une attaque peut coûter
Un attaquant qui contrôle votre serveur peut voler vos fichiers clients et vos commandes, récupérer les clés de vos outils de paiement ou d’e-mailing, rediriger votre site vers des arnaques, ou y injecter des pages de spam qui abîment votre référencement pendant des mois. Google peut alors afficher votre site comme dangereux. Votre serveur peut aussi servir à envoyer du spam, et vos propres e-mails finissent en indésirables. Chaque jour d’indisponibilité coûte des ventes ou des contacts, et la remise en état coûte toujours plus cher qu’une mise à jour.
Questions fréquentes
Mettre à jour WordPress ou PrestaShop suffit-il ?
Non. La faille est dans PHP, pas dans le CMS. Un WordPress parfaitement à jour sur un PHP non corrigé reste vulnérable.
Mon site est petit, est-il vraiment visé ?
Oui. Les attaques sont menées par des robots qui testent tous les sites qu’ils trouvent. Un petit site est même une cible appréciée : il est souvent moins surveillé, et son serveur sert ensuite à attaquer d’autres sites ou à envoyer du spam.
Le cadenas HTTPS protège-t-il mon site ?
Non. Le certificat chiffre la connexion entre le visiteur et le serveur. Il ne dit rien de ce que le serveur exécute.
Un pare-feu ou Cloudflare me protège-t-il ?
Un pare-feu applicatif bien réglé peut bloquer une partie des tentatives, et c’est une bonne protection temporaire. Ce n’est pas une correction : une variante de l’attaque peut passer. Seule la mise à jour de PHP ferme la faille.
PHP 7.4 ou 8.0 sont-ils concernés ?
Ces versions ne reçoivent plus aucun correctif depuis longtemps. Qu’elles soient touchées ou non par cette faille précise, un site qui tourne dessus est exposé à celle-ci comme aux précédentes : il faut migrer.
La mise à jour va-t-elle casser mon site ?
Dans la même branche, très rarement. En changeant de branche, c’est possible si le thème, une extension ou un module n’est pas compatible : d’où l’intérêt de tester sur une copie avant.
Combien coûte la mise en sécurité ?
Cela dépend de votre situation : une mise à jour dans la même branche n’a rien à voir avec la migration d’une boutique PrestaShop 1.7. C’est pourquoi nous commençons par un audit, qui établit précisément ce qu’il faut faire.
Dois-je prévenir mes clients ?
Seulement si leurs données ont pu être exposées. Dans ce cas, la CNIL doit être notifiée sous 72 heures, et les personnes concernées doivent être informées lorsque le risque pour elles est élevé.
Comment ne plus subir ces alertes ?
En confiant le suivi du site à quelqu’un dont c’est le travail. Une maintenance de site internet inclut la surveillance des alertes de sécurité et l’application des correctifs, de PHP comme du CMS. La loi NIS2 va d’ailleurs dans ce sens pour les entreprises qu’elle concerne : il faut pouvoir prouver que les mises à jour sont appliquées. Les autres failles fréquentes, celles du code et des extensions, sont détaillées dans notre article sur les dix vulnérabilités qui touchent les sites français.
Ce que fait Novatis
Nous auditons votre site : version de PHP, CMS, thème et extensions, traces de piratage, sauvegardes et hébergement. Vous recevez un rapport clair, avec la liste des corrections à faire et leur devis. Pour les boutiques PrestaShop 1.7 et 8, nous posons une protection temporaire, puis nous préparons la migration vers PrestaShop 9.
Faire auditer mon site ou appelez-nous au 07 56 82 86 52.
