Faille PHP2Shell et PrestaShop : risques et que faire

PHP2Shell désigne deux failles critiques de PHP, CVE-2026-109618 et CVE-2026-109619, rendues publiques le 21 octobre 2026. Une seule requête piégée peut suffire à prendre le contrôle du serveur d’une boutique, sans connexion ni mot de passe. Elles concernent toutes les boutiques PrestaShop, quelles que soient leur version et leurs modules, car le bug se trouve dans PHP, le moteur sur lequel tourne PrestaShop, et non dans PrestaShop lui-même. La seule protection complète est la mise à jour de PHP en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Les boutiques plus anciennes sont les plus exposées : PrestaShop 1.6, 1.7 et 8 fonctionnent sur des versions de PHP qui ne reçoivent plus de correctif officiel. Voici, en termes simples, ce qu’est cette faille, comment vérifier votre boutique et que faire, étape par étape.

Qu’est-ce que PHP2Shell ?

PHP est le langage et le moteur qui font tourner PrestaShop sur le serveur : il construit les pages, enregistre les commandes et envoie les e-mails. Si votre boutique était un magasin dans un centre commercial, PHP serait la serrure de l’entrée principale du bâtiment. En octobre 2026, on a découvert que cette serrure pouvait s’ouvrir sans clé.

L’équipe PHP a décrit deux bugs, tous deux notés 9,2 sur 10 sur l’échelle CVSS, soit un niveau critique :

• CVE-2026-109618 : lorsque PHP manque de mémoire pendant la lecture d’un formulaire envoyé, il peut laisser derrière lui des données à moitié construites, que l’attaquant sait exploiter.
• CVE-2026-109619 : des restes d’une requête demeurent dans la mémoire du serveur, et la requête suivante traitée par le même processus peut s’en servir. La voie la plus simple passe par la fonction de suivi de l’envoi des fichiers (session upload progress), activée par défaut dans PHP.

Dans les deux cas, le résultat est une exécution de code à distance (RCE) : l’attaquant lance le programme de son choix sur votre serveur avant même que PrestaShop démarre. Une fuite a aggravé la situation : les détails et un outil baptisé « PHP2Shell » circulaient en ligne la veille de la publication des correctifs.

Pourquoi une faille PHP touche-t-elle toutes les boutiques PrestaShop ?

La plupart des vulnérabilités décrites dans notre guide Sécurité PrestaShop concernent un module ou une version de boutique précis, et il suffit de mettre le module à jour. PHP2Shell est différente. L’attaque a lieu pendant que le serveur lit la requête entrante, avant l’exécution de tout code PrestaShop. C’est pourquoi mettre à jour PrestaShop ou ses modules ne sert à rien ici, ce que confirme aussi le guide officiel de PrestaShop pour les marchands. Le correctif doit être installé sur le serveur.

Impossible non plus de simplement « désactiver les formulaires ». PrestaShop envoie des fichiers à de nombreux endroits : formulaire de contact avec pièce jointe, personnalisation de produit, import CSV, images produits et installation de modules dans le back-office. Bloquer ces requêtes casserait la boutique.

Que peut faire un attaquant qui contrôle le serveur ? Tout ce que peut faire un administrateur : copier la base clients avec adresses et numéros de téléphone, remplacer la page de paiement par une fausse, injecter du code malveillant pour les visiteurs, envoyer du spam depuis le domaine de la boutique ou chiffrer vos fichiers pour exiger une rançon. En cas de fuite de données personnelles s’ajoutent vos obligations envers vos clients et envers l’autorité de protection des données (la CNIL en France).

Anciennes versions de PrestaShop : le vrai problème

Chaque version de PrestaShop ne fonctionne qu’avec certaines versions de PHP, et le projet PHP ne maintient que ses dernières branches. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles. À titre exceptionnel, l’équipe PHP a publié un correctif minimal dans le code source de PHP 7.4, 8.0 et 8.1, mais son arrivée sur votre serveur dépend de celui qui fournit les paquets PHP : votre distribution Linux ou votre hébergeur.

Le correctif minimal ferme les voies d’attaque connues de façon radicale : quand PHP manque de mémoire, le processus est arrêté sur-le-champ, et le suivi de l’envoi des fichiers est désactivé définitivement. Il fonctionne, mais l’équipe PHP elle-même le présente comme le minimum pour des versions non maintenues, et la prochaine faille du même genre pourrait ne pas en avoir. De plus, PHP 8.2 arrive en fin de vie le 31 décembre 2026 : dans deux mois, d’autres serveurs rejoindront ce groupe.

La conclusion est simple : une boutique sous PrestaShop 1.7 ou 8 peut encore être protégée aujourd’hui, mais ce sera plus difficile chaque mois. La voie sûre est une mise à jour vers PrestaShop 9, qui tourne sur un PHP maintenu.

Comment vérifier la version de PHP de votre boutique ?

Dans le back-office de PrestaShop 1.7, 8 et 9, ouvrez Paramètres avancés → Informations. La partie consacrée au serveur indique la version de PHP. Attention : le numéro seul ne dit pas tout. Les paquets qui intègrent le correctif reporté gardent souvent le même numéro qu’avant (par exemple 7.4.33 ou 8.1.34) et ne diffèrent que par une révision interne du paquet. Avec un PHP ancien, demandez donc toujours à la personne qui gère le serveur si le correctif est installé.

Hébergement mutualisé ou serveur dédié : qui installe le correctif ?

Tout dépend de l’endroit où tourne votre boutique. Nous comparons les deux options dans VPS ou hébergement mutualisé pour PrestaShop.

• Hébergement mutualisé : c’est l’hébergeur qui met PHP à jour, vous n’avez pas la main. Les anciennes versions de PHP proposées dans le panneau d’hébergement ne reçoivent pas toujours les correctifs. Posez la question par écrit : « Le correctif des CVE-2026-109618 et CVE-2026-109619 est-il appliqué à la version de PHP qui fait tourner ma boutique ? » C’est aussi ce que recommande PrestaShop.
• VPS ou serveur dédié : c’est l’administrateur qui installe le correctif, donc vous ou la société qui gère le serveur. Personne ne le fera automatiquement : les sources de paquets PHP tierces courantes pour Ubuntu ne sont pas couvertes par défaut par les mises à jour automatiques du système.
• Serveur infogéré : les mises à jour de sécurité, PHP compris, font partie du travail de l’administrateur.

Que faire maintenant : 6 étapes

1. Vérifiez votre version de PHP dans Paramètres avancés → Informations.
2. Interrogez votre hébergeur ou votre administrateur sur l’installation du correctif, et demandez une réponse écrite.
3. Sur votre propre serveur, mettez PHP à jour et redémarrez tous les processus PHP (PHP-FPM, Apache). Installer les paquets ne suffit pas : les processus en cours utilisent encore l’ancien code.
4. Si la mise à jour est impossible tout de suite, désactivez le suivi de l’envoi des fichiers dans php.ini ou dans la configuration du pool PHP-FPM (pas dans .user.ini ni avec ini_set(), où cela n’a aucun effet). PrestaShop n’utilise pas cette fonction, rien ne sera cassé. Ce contournement ne ferme qu’une partie des voies d’attaque.
5. Cherchez des traces d’intrusion : nouveaux fichiers .php dans les dossiers de la boutique, comptes inconnus dans Paramètres avancés → Équipe, modules de paiement modifiés, nouvelles tâches cron. Notre guide sécurité détaille les symptômes et la marche à suivre après une attaque.
6. Planifiez une mise à jour de PrestaShop si votre boutique tourne sur PHP 8.1 ou plus ancien.

Pour les administrateurs de serveurs Ubuntu ou Debian : mise à jour de PHP et vérification que le paquet contient le correctif (un résultat supérieur à zéro signifie que oui) :

sudo apt update
sudo apt install --only-upgrade 'php*'
sudo systemctl restart php8.1-fpm
zcat /usr/share/doc/php8.1-common/changelog.Debian.gz | grep -c CVE-2026-109618

Contournement temporaire dans php.ini ou dans le pool PHP-FPM :

session.upload_progress.enabled = 0
post_max_size = 32M

Conseil : l’équipe PHP propose aussi de régler memory_limit=-1. Mais cela remplace le risque d’intrusion par le risque qu’une seule requête occupe toute la mémoire du serveur et arrête la boutique. Sans limite de mémoire distincte pour les processus PHP, mieux vaut s’en abstenir ; c’est une tâche d’administrateur, pas de marchand.

Failles liées plus récentes

L’histoire ne s’est pas arrêtée le 21 octobre. Voici la suite :

• CVE-2026-115560 (23/10) : une autre faille dans la même fonction de suivi de l’envoi des fichiers. Elle n’est exploitable que si une application modifie en cours d’exécution la façon dont PHP enregistre les sessions (session.serialize_handler). Nous n’avons trouvé aucune modification de ce type dans le code de PrestaShop 9 : pour une boutique classique, le risque est faible. Le correctif arrivera avec la prochaine version régulière de PHP ; d’ici là, le même réglage session.upload_progress.enabled = 0 vous protège.
• Attaques réelles : le 26 octobre, la CISA a ajouté CVE-2026-109618 et CVE-2026-109619 à son catalogue des vulnérabilités exploitées dans de vraies attaques. Des dizaines d’exemples d’exploits publics circulent, y compris des variantes conçues pour passer les filtres WAF.
• CVE-2026-111497 (26/10) : un bug de la bibliothèque Brotli dans les versions Windows de PHP. Il ne concerne pas les boutiques sur des serveurs Linux classiques.

Cloudflare ou un autre WAF peut filtrer une partie des attaques automatisées, mais ne remplace pas le correctif, surtout si votre serveur reste joignable directement, sans passer par Cloudflare. Nous expliquons comment bien le configurer dans Sécuriser un serveur PrestaShop.

Un serveur dont vous n’avez plus à vous occuper

PHP2Shell montre que la sécurité d’une boutique ne se limite pas aux modules et aux mots de passe. Quelqu’un doit apprendre l’existence d’une nouvelle faille le jour même, vérifier si elle touche le serveur, installer le correctif, redémarrer les services et s’assurer que la boutique fonctionne. Si vous ne voulez pas vous en charger, vous pouvez le confier.

Avec notre service Serveur et infogérance PrestaShop, vous disposez de votre propre VPS préparé pour PrestaShop et d’un administrateur qui assure les mises à jour régulières, y compris de sécurité. Le serveur comprend un pare-feu, une connexion SSH par clé uniquement, fail2ban, Cloudflare avec protection DDoS et WAF, une surveillance et 7 jours de sauvegardes. Nous intervenons sous 4 heures les jours ouvrés, et la migration de votre boutique est incluse. Le service coûte 119 € HT par mois.

Si vous pensez que votre boutique a pu être attaquée avant l’installation du correctif, commandez un audit de sécurité de la boutique. Nous vérifions le cœur, les modules, la configuration et les traces d’intrusion, et le rapport liste chaque problème avec son niveau de risque.

Sources

• PHP : annonces d’octobre 2026 — versions corrigées, contournements, CVE-2026-115560.
• GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp — détails techniques des deux failles.
• PrestaShop Help Center — recommandations de PrestaShop aux marchands.
• CISA Known Exploited Vulnerabilities — les deux failles ajoutées le 26/10/2026.
• Configuration requise de PrestaShop 1.7, 8 et 9 — versions de PHP prises en charge.

Questions fréquentes

Une question sur le PHP du serveur de votre boutique ? Contactez-nous ou découvrez notre service Serveur et infogérance PrestaShop.

Produits de cet article

Serveur et infogérance PrestaShop (1 mois)

119,00 €

Note sur 5 étoiles d'après () avis

Ajouter au panier

Mise à jour de PrestaShop

1 999,00 €

Note sur 5 étoiles d'après () avis

Ajouter au panier

Audit de sécurité de la boutique

239,00 €

Note sur 5 étoiles d'après () avis

Ajouter au panier

Retour : Blog