Vulnérabilités PHP critiques (php2shell) : ce que les marchands PrestaShop doivent savoir

Le 21 octobre 2026, l'équipe de sécurité PHP a publié des mises à jour corrigeant deux vulnérabilités critiques dans PHP lui-même, toutes deux évaluées à un score CVSS de 9.2. Il s'agit d'une vulnérabilité PHP, et non d'une vulnérabilité PrestaShop. Étant donné que PrestaShop fonctionne sous PHP, presque toutes les boutiques PrestaShop sont concernées, tout comme la plupart des sites web utilisant PHP (WordPress, Magento, Drupal et bien d'autres).

PrestaShop est un logiciel open source installé sur l'hébergement de votre choix, et nous n'avons pas accès à votre serveur. Le correctif est une mise à jour de PHP, appliquée par la personne ou l'entité qui gère votre serveur : généralement votre hébergeur. Cet article explique ce qu'il faut vérifier et ce qu'il faut demander.

! En bref Assurez-vous que le serveur de votre boutique utilise PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 (ou ultérieur), ou un paquet patché fourni par votre distribution Linux ou votre hébergeur. Contactez votre hébergeur dès aujourd'hui et demandez une confirmation écrite. Mettre à jour PrestaShop ou vos modules ne corrigera pas cette vulnérabilité.

1. Comprendre la vulnérabilité

Le 20 octobre, le projet PHP a diffusé une notification préalable concernant une mise à jour de sécurité. Les correctifs ont été publiés le 21 octobre à 14:00 UTC, accompagnés d'un avis de sécurité officiel.

Les deux vulnérabilités, surnommées php2shell par les chercheurs qui les ont signalées (Calif.io, Wiz, OpenAl et Quarkslab), sont :

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) : lorsque PHP manque de mémoire, il peut être interrompu alors que les données internes de la requête ne sont que partiellement initialisées. Le processus de nettoyage qui suit peut alors considérer ces données incomplètes comme valides.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) : un état interne appartenant à une requête peut survivre après que sa mémoire a été libérée. Une requête ultérieure traitée par le même processus PHP (worker) peut alors utiliser cet état obsolète.

En clair, il s'agit dans les deux cas de failles de gestion de la mémoire dans le moteur PHP. Avec des requêtes HTTP spécialement conçues, un attaquant pourrait faire planter PHP, exposer des données sensibles ou, dans le pire des cas, exécuter son propre code sur le serveur sans aucune authentification.

Toutes les installations PHP traitant des requêtes web sont menacées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est le plus élevé avec mod_php.

2. Une vulnérabilité PHP, pas une vulnérabilité PrestaShop

Ces vulnérabilités ne se trouvent pas dans PrestaShop, ni dans aucun module PrestaShop. Elles résident dans l'environnement d'exécution PHP qui fait tourner PrestaShop, tout comme il fait tourner les applications WordPress, Magento, Drupal ou Laravel.

Cela a trois conséquences :

1. Mettre à jour PrestaShop ou vos modules ne résoudra pas le problème. Il n'y a pas de patch PrestaShop à installer. La seule solution complète est de mettre à jour PHP sur le serveur.
2. L'attaque peut se produire avant même que le code PrestaShop ne s'exécute. Les mesures de sécurité dans PrestaShop ou dans les modules ne peuvent pas la bloquer. La protection doit venir de la mise à jour de PHP et, en attendant, de la couche serveur ou réseau.
3. Toutes les versions de PrestaShop sont concernées, de la 1.6 à la 9, puisqu'elles fonctionnent toutes sous PHP.

Étant donné que ces failles peuvent être exploitées à distance et sans authentification, nous considérons la mise à jour de PHP comme une priorité absolue pour chaque marchand.

3. Étapes à suivre

Vérifier votre version de PHP

Dans votre Back Office, allez dans Paramètres avancés > Informations. La version de PHP est indiquée sous Informations sur le serveur. Comparez-la ensuite avec les versions corrigées :

Les distributions Linux intègrent souvent les correctifs de sécurité (backports) sans modifier le numéro de version. Un paquet Debian ou Ubuntu peut toujours afficher une ancienne version 8.2.x tout en incluant le correctif. Une version inférieure ne signifie pas automatiquement que vous êtes vulnérable, mais vous devez vérifier auprès de la personne gérant votre serveur.

Contacter votre hébergeur

Sur un hébergement mutualisé, un hébergement infogéré ou un hébergeur spécialisé PrestaShop, PHP est géré pour vous. Les distributions Linux et les fournisseurs de support à long terme (LTS) ont reçu les correctifs à l'avance, de sorte que la plupart des hébergeurs sérieux déploient déjà les mises à jour.

Posez-leur une question simple : "Le correctif pour les vulnérabilités CVE-2026-109618 et CVE-2026-109619 a-t-il été appliqué à la version de PHP qui fait tourner ma boutique ?" Demandez une confirmation écrite. Un message prêt à être envoyé est disponible à la section 7.

Si vous gérez votre propre serveur

Si vous ou votre agence gérez le serveur (VPS, serveur dédié, instance cloud, conteneurs) :

• Installez les paquets PHP mis à jour depuis votre distribution Linux, ou depuis les versions officielles de PHP, dès que possible.
• Redémarrez chaque processus PHP après la mise à jour (pools PHP-FPM, Apache, LiteSpeed, workers FrankenPHP). Une mise à jour installée mais non chargée ne vous protège pas.
• Si vous utilisez le dépôt maintenu par des bénévoles rpms.remirepo.net : le projet PHP a annoncé qu'il n'aurait pas de mises à jour le 21 octobre et recommande de passer aux paquets de la distribution ou de compiler à partir des sources.
• Si votre boutique fonctionne sous Docker, reconstruisez vos images sur l'image de base mise à jour et redéployez.
• Après la mise à jour, vérifiez que votre boutique fonctionne : connexion au Back Office, ajout au panier, commande test.

Si vous n'êtes pas à l'aise pour mettre à jour PHP sur un serveur en production, vous pouvez trouver une agence spécialisée ou un freelance sur le portail PrestaShop Experts.

Surveiller les signes de compromission

• Fichiers .php inconnus ou récemment modifiés dans les dossiers de votre boutique.
• Comptes administrateurs que vous n'avez pas créés dans le Back Office.
• Redirections inattendues, contenu altéré ou page de paiement modifiée.
• En cas de doute, contactez immédiatement votre hébergeur.

4. Cas particulier : PHP 8.1 ou plus ancien

PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles du projet PHP. C'est courant dans l'écosystème PrestaShop, car PrestaShop 1.7 et 8 ne supportent pas PHP 8.2 ou ultérieur :

Sources : Prérequis système PrestaShop 9, Prérequis système PrestaShop 8, Prérequis système PrestaShop 1.7.

Si cela vous concerne :

• Demandez à votre hébergeur si votre version de PHP a été patchée. De nombreuses distributions Linux et fournisseurs LTS publient des paquets corrigés pour les versions qu'ils supportent encore. Le projet PHP a également publié des rétroportages (backports) minimaux pour PHP 7.4, PHP 8.0 et PHP 8.1.
• Si aucun correctif n'est encore disponible, appliquez les mesures provisoires de la section 5.
• Planifiez une mise à niveau vers PrestaShop 9, qui fonctionne sur des versions de PHP maintenues. Une mise à niveau majeure implique de vérifier la compatibilité de votre thème et de vos modules : un Expert PrestaShop peut vous y aider.

Notez également que PHP 8.2 atteindra sa fin de vie (EOL) le 31 décembre 2026. Si votre boutique fonctionne sous PHP 8.2 aujourd'hui, prévoyez également de passer à une version PHP plus récente.

5. Si PHP ne peut pas être mis à jour immédiatement

L'équipe de sécurité PHP est claire : il n'y a pas d'atténuation complète, et la mise à jour est le seul choix sûr. Les mesures ci-dessous ne font que réduire l'exposition pendant que la mise à jour est planifiée. Elles sont destinées aux hébergeurs, aux équipes techniques et aux Experts PrestaShop, et doivent d'abord être testées sur un environnement de pré-production (staging).

Pour CVE-2026-109618 (gestion de la mémoire saturée)

• Limitez la taille des requêtes : définissez post_max_size sur 32M et maintenez upload_max_filesize en dessous de cette valeur. PrestaShop utilise les téléchargements dans le Back Office (images de produits, imports CSV, installation de modules), donc 32M est la valeur pertinente plutôt que 8M. Les imports ou les archives de modules très volumineux devront peut-être être scindés.
• Appliquez également des limites de taille de requête au niveau du serveur web ou du reverse proxy.
• L'avis décrit également la définition de memory_limit=-1 via php_admin_value, combinée à une limite de mémoire de conteneur ou de cgroup. N'utilisez pas RLIMIT_AS ou RLIMIT_DATA pour cela, car ils peuvent déclencher le comportement vulnérable.

Pour CVE-2026-109619 (état obsolète entre les requêtes)

• Définissez session.upload_progress.enabled=0 dans php.ini, dans le pool PHP-FPM ou dans la configuration du serveur, puis redémarrez tous les workers PHP. Ne vous fiez pas aux fichiers ini_set() ou .user.ini. Ce paramètre n'a aucun impact sur PrestaShop, qui n'utilise pas cette fonctionnalité.
• Sur PHP 8.5, définissez également fatal_error_backtraces=0 et redémarrez les workers.

Masquer les erreurs (avec error_reporting, display_errors ou l'opérateur @) n'aide pas. L'avis officiel reste la liste complète et faisant autorité.

Vérification de la configuration

Avec un accès SSH, ces commandes affichent la version de PHP et les paramètres ci-dessus :

php -v
php -i | grep -E "session.upload_progress.enabled|post_max_size|upload_max_filesize"

La ligne de commande et le serveur web peuvent utiliser des configurations PHP différentes. Les valeurs qui comptent sont celles appliquées au site web : vérifiez-les auprès de votre hébergeur, ou via la version affichée dans Paramètres avancés > Informations.

Pare-feu d'application web (WAF)

Un WAF filtre les requêtes malveillantes avant qu'elles n'atteignent PHP, ce qui est important ici puisque l'attaque se produit avant l'exécution du code de l'application. Cloudflare, par exemple, a déployé des règles WAF dédiées pour php2shell, actives par défaut sur les forfaits gratuits et payants depuis le 21 octobre. Sur un forfait payant, vérifiez que l'ensemble de règles gérées s'exécute en mode blocage (block).

Un WAF est une couche supplémentaire bienvenue, mais la protection basée sur des signatures peut être contournée par des charges utiles retravaillées. Il ne remplace pas la mise à jour de PHP.

6. Bonnes pratiques et prévention

Une boutique dépend de nombreuses couches : le serveur, PHP, PrestaShop, le thème et chaque module. Une faiblesse dans l'une d'entre elles peut mettre en péril toute la boutique, même lorsque la couche en cause n'est pas PrestaShop. Les outils d'IA aident désormais les chercheurs à trouver des vulnérabilités plus rapidement, mais ils aident aussi les attaquants à transformer un correctif publié en une attaque fonctionnelle en quelques heures.

• Utilisez une version de PHP maintenue : une version en fin de vie dépend d'autres personnes pour rétroporter les correctifs critiques.
• Gardez PrestaShop et vos modules à jour : les versions récentes de PrestaShop prennent en charge les versions récentes de PHP.
• Choisissez des partenaires qui corrigent rapidement : vérifiez votre contrat d'hébergement pour savoir qui applique les mises à jour PHP et à quelle vitesse.
• Faites des sauvegardes régulières : fichiers et base de données, stockés hors du serveur.
• Suivez les annonces de sécurité : PHP, les avis de sécurité PrestaShop, le site de sécurité Friends of Presta et votre hébergeur.
• Mettez en place un plan de maintenance : un Expert PrestaShop peut s'en charger si vous n'avez pas d'équipe technique.

7. Quand contacter votre hébergeur ou un expert

Contactez votre hébergeur dès aujourd'hui si PHP est géré pour vous, si votre version est plus ancienne que celles listées à la section 3, ou si vous remarquez un comportement suspect. Contactez une agence ou un Expert PrestaShop si vous gérez votre propre serveur et avez besoin d'aide, ou pour préparer une mise à niveau vers PrestaShop 9.

Vous pouvez envoyer ce message à votre hébergeur :

Bonjour,

Le 21 octobre 2026, le projet PHP a publié des correctifs pour deux vulnérabilités critiques (CVE-2026-109618 et CVE-2026-109619).

Ma boutique fonctionne sous PHP [votre version].

Pourriez-vous s'il vous plaît me confirmer par écrit :

1. Si le correctif a été appliqué à la version de PHP qui fait tourner ma boutique, et quand ?
2. Que tous les processus PHP ont bien été redémarrés depuis ?
3. Si ma version de PHP n'est plus maintenue, fournissez-vous un paquet patché, ou quelles mesures provisoires avez-vous appliquées ?

Merci d'avance.

8. Points clés à retenir

• Les vulnérabilités se trouvent dans PHP, pas dans PrestaShop : il n'y a pas de patch PrestaShop, et le correctif est une mise à jour de PHP sur le serveur.
• Vérifiez votre version de PHP dans Paramètres avancés > Informations et comparez-la avec 8.5.12, 8.4.27, 8.3.36 ou 8.2.35.
• Contactez votre hébergeur dès aujourd'hui et demandez une confirmation écrite, ou mettez à jour et redémarrez PHP vous-même si vous gérez le serveur.
• Sous PHP 8.1 ou antérieur : demandez un paquet patché, appliquez les mesures provisoires et planifiez un passage à PrestaShop 9.
• Gardez un WAF devant votre boutique si vous le pouvez, mais cela ne remplace pas la mise à jour.

Sources

• Notification préalable PHP
• Avis de sécurité PHP
• Cloudflare : protection WAF pour php2shell
• Prérequis système PrestaShop 9
• Prérequis système PrestaShop 8
• Prérequis système PrestaShop 1.7