PHP2Shell : l'exploitation est confirmée, vérifiez votre boutique

Depuis le 26 octobre 2026, l’exploitation de PHP2Shell dans la nature n’est plus une hypothèse : la presse spécialisée documente une exécution de code à distance confirmée sur un serveur PHP. Pour une boutique en ligne, la question n’est plus de savoir si le correctif existe, mais si elle a été exposée entre le 17 et le 21 octobre.

Une exécution de code confirmée dans la nature

Le 26 octobre, BleepingComputer rapporte que les deux failles PHP critiques PHP2Shell ont été exploitées avec succès. La détection vient de leurres réseau (des honeypots, des serveurs yeuxrés pour attirer les attaquants) déployés par Adel Karimi, responsable de la détection chez Perplexity. Ces leurres ont enregistré une exécution de code à distance confirmée contre une installation Apache avec mod_php sous PHP 8.4.26.

La preuve est précise. La réponse du serveur a renvoyé un vidage de cookie décodé de 800 Kio, et une adresse de fonction calculée à partir de ce vidage apparaît dans la charge utile d’exécution qui suit. Marcus Hutchins, chercheur chez Expel, a confirmé les constatations.

L’alerte AL26-026 du Centre canadien pour la cybersécurité, mise à jour le 27 octobre, indique que la CISA a ajouté les deux failles à son catalogue des vulnérabilités exploitées le 26 octobre.

Ce que cette preuve ne permet pas de dire

Le profil compromis est étroit : Apache avec mod_php, en configuration à worker unique, un montage que le chercheur décrit lui-même comme volontairement favorable. Sa conclusion est explicite, la démonstration porte sur ce profil précis et ne mesure pas la fiabilité de l’exploitation sur d’autres nombres de workers, d’autres versions de PHP ou d’autres applications.

Cette prudence ne doit pas devenir une berceuse pour les boutiques mutualisées. L’éditeur considère que toutes les installations qui servent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé le plus élevé pour mod_php, parce qu’une requête non authentifiée peut déclencher l’attaque avant l’exécution du moindre code applicatif.

En revanche, une compromission documentée ne prouve pas que des boutiques sont compromises : c’est un cas observé dans un environnement instrumenté, pas une mesure de l’ampleur réelle.

Votre boutique a pu être exposée entre le 17 et le 21 octobre

Amazon Threat Intelligence a observé les premières tentatives d’exploitation dès le samedi 17 octobre 2026, quatre jours avant la publication des correctifs. Des adresses issues d’un réseau d’anonymisation commercial ont visé les leurres ; AWS conclut que plusieurs acteurs étaient probablement actifs, sans pouvoir dire si ces tentatives auraient réussi.

Le 22 octobre, l’équipe TRACE de Dataminr décrivait l’activité observée depuis la publication de la faille comme limitée à du scan, d’empreinte et à l’usage d’exploits non fonctionnels, sans compromission connue.

La fenêtre à considérer est précise : du 17 octobre au moment où votre hébergeur a déployé les versions corrigées et redémarré les processus qui traitent les requêtes. Nous avons détaillé cette partie dans notre article du 22 octobre sur la faille PHP. Ce qui change, c’est que l’exploitation n’est plus une simple menace.

Une troisième faille, sans correctif à ce jour

Le 23 octobre, l’éditeur a publié un avis sur une troisième exécution de code à distance, CVE-2026-115560. Le CERT-FR l’a reprise dans son alerte CERTFR-2026-ALE-014, mise à jour le 27 octobre : un correctif sera publié au prochain cycle de mises à jour, l’éditeur estimant les conditions d’exploitation peu probables.

Le scénario est précis. L’application doit régler le gestionnaire de sérialisation de session sur php_binary ou php_serialize, puis le basculer sur php à l’exécution avec ini_set(), avant l’ouverture de session. Le suivi de progression des envois doit rester actif. Une application qui ne modifie jamais ce gestionnaire n’est pas exposée.

En attendant, l’éditeur recommande de désactiver le suivi de progression des envois : posez le réglage session.upload_progress.enabled=0 dans la configuration du serveur, puis redémarrez tous les processus. Vérifiez si une fonction de votre back-office s’en sert. Si vous l’aviez déjà posé le 21 octobre, rien de plus à faire.

Que demander à votre hébergeur et que vérifier sur votre boutique

La vérification se fait en deux temps : ce que l’hébergeur doit prouver par écrit, ce que vous devez regarder sur votre boutique.

1. La version réellement servie et le mode d’exécution. Demandez, pour chaque site, la version de PHP qui traite les requêtes, le mode (mod_php, PHP-FPM ou autre), la date et l’heure du déploiement du correctif, puis l’heure du redémarrage de tous les processus.
2. Le réglage de configuration, au bon niveau. Faites confirmer que la valeur est à 0 dans la configuration effective du serveur ou du pool, et qu’aucun réglage local ne la remet à 1. Un ini_set() dans le code applicatif ne suffit pas : la désérialisation s’exécute avant l’initialisation de la requête.
3. La conservation des journaux. Demandez si les journaux d’accès, d’erreur PHP et d’authentification sont conservés sur la fenêtre du 17 au 21 octobre, et comment en obtenir une copie.
4. La recherche de compromission. Demandez si l’hébergeur a cherché des traces d’exécution de commandes et des fichiers modifiés, et sur quel périmètre.

De votre côté, la lecture des journaux reste le premier réflexe. Repérez les requêtes inhabituelles vers des scripts, les erreurs de mémoire en début de requête, les processus et tâches planifiées que vous ne connaissez pas, les fichiers ajoutés ou modifiés dans le cœur, les modules, les thèmes et les répertoires d’envoi.

Ajoutez les comptes administrateurs inattendus, les changements de mot de passe, les modifications des scripts de paiement et des redirections. Un journal incomplet ne prouve pas qu’il n’y a pas eu de compromission, et l’absence d’indice n’exclut pas une intrusion.

Si vous trouvez un indice, ne supprimez pas le fichier à la hâte. Conservez les journaux et une copie des fichiers concernés avant tout nettoyage, faites réinitialiser vos secrets depuis un poste sain et faites analyser l’hébergement par un professionnel. Le contrôle de la version de PHP fait partie de notre maintenance Prestashop mensuelle.

La fin de vie de PHP 8.2 fixe le vrai calendrier

Le projet PHP a placé la fin du support de sécurité de PHP 8.2 au 31 décembre 2026, sans correctif ensuite. Les versions 5.x, 6.x, 7.x, 8.0.x et 8.1.x ne sont plus supportées : le CERT-FR recommande d’isoler les équipements vulnérables, puis de migrer vers une version maintenue.

Un marchand sur PHP 8.2 a un correctif qui expire dans deux mois. Sur 8.1 ou une version antérieure, tout dépend d’un rétroportage éventuel de son hébergeur, que rien ne garantit.

La migration elle-même a ses propres règles, que nous détaillons dans notre guide de migration Prestashop.

Que retenir, quelle décision prendre ?

Si votre boutique a été exposée entre le 17 et le 21 octobre, demandez les quatre preuves écrites, puis faites relire les journaux et le site. C’est la seule séquence qui distingue une boutique intacte d’une boutique compromise.

Si votre hébergeur ne fournit aucune trace, ce silence est une information en soi. Un hébergement mutualisé sans traçabilité sur les versions et les journaux reste un risque pour une boutique qui encaisse des paiements.

Si vous êtes déjà sur PHP 8.3 ou une version plus récente et que les quatre preuves tombent, votre priorité redevient la fin de support de PHP 8.2, à traiter avant le 31 décembre.

---

Vous voulez savoir ce que votre hébergement couvre et comment planifier la montée de version avant le 31 décembre ? Consultez notre page de création de boutique Prestashop, ou contactez-nous pour en parler.

Questions complémentaires sur PHP2Shell

Une boutique Prestashop peut-elle être compromise par PHP2Shell ?

Oui. La faille est dans le moteur PHP, pas dans la plateforme : mettre à jour Prestashop ou ses modules n’y change rien, la correction se fait chez votre hébergeur. Le profil le plus exposé est mod_php en configuration à worker unique, mais toutes les installations qui servent des requêtes web sont concernées.

Ce qui distingue une boutique compromise d’une boutique intacte, c’est l’examen des journaux et des fichiers, pas le sentiment de sécurité.

Faut-il mettre à jour Prestashop ou PHP ?

PHP d’abord, car c’est le correctif du moteur qui ferme la faille. Pour la plateforme, voici où vous en êtes.

« Prestashop 9 est la version majeure actuelle (première version stable 9.0 publiée le 10 juin 2025 ; branche 9.1 disponible). La branche 8.2 reste maintenue en correctifs de sécurité. Prestashop 1.7 n’est plus maintenu depuis la sortie de la version 9.0, et Prestashop 1.6 ne l’est plus depuis juin 2019 : les boutiques restées sur ces versions n’ont plus de correctifs de sécurité. »

Les mesures de contournement protègent-elles ma boutique ?

Non. Selon le CERT-FR, seule l’application de la mise à jour permet de se prémunir contre l’exploitation. Les mesures publiées par PHP réduisent l’exposition à des chemins d’attaque précis, elles ne rendent pas une installation sûre. Pour la troisième faille, aucun correctif n’existe : la configuration est le seul levier disponible en attendant.