PHP2Shell : que faire face à CVE-2026-109618 et CVE-2026-109619 sur PrestaShop, même sans pouvoir mettre votre boutique à niveau

Le 21 octobre 2026, le projet PHP a publié en urgence des versions corrigeant deux vulnérabilités critiques de PHP lui-même, désormais regroupées sous le nom de PHP2Shell : CVE-2026-109618 et CVE-2026-109619. Toutes deux peuvent permettre à un attaquant d’exécuter du code sur un serveur web sans se connecter et, dans certaines configurations, avant même qu’une seule ligne du code de votre boutique ne soit exécutée.

Pour la plupart des sites, le conseil tient en quelques mots : mettez PHP à jour et redémarrez-le. Pour les boutiques PrestaShop, les choses sont plus compliquées, d’où cet article. Toutes les versions de PrestaShop antérieures à la 9.0 prennent officiellement en charge PHP 8.1 au maximum, et aucune version officielle corrigée n’a été publiée pour PHP 8.1 ni pour les branches plus anciennes. Une grande partie des boutiques PrestaShop dans le monde ne peuvent donc pas simplement « mettre PHP à jour » cette semaine.

Ce guide explique ces vulnérabilités, comment savoir si votre boutique est réellement exposée (le numéro de version ne suffit pas), les mesures à prendre pour chaque version de PrestaShop et la solution transitoire que nous utilisons pour les boutiques qui ne peuvent pas être mises à niveau maintenant : les faire passer à un PHP 7.4 corrigé par un fournisseur, d’abord sur une copie de staging, et corriger les portions de code qui ne fonctionnent plus. C’est une étape de transition, pas une solution définitive. C’est aussi bien préférable à laisser la boutique exposée ou à la fermer.

PHP2Shell, en termes simples

Les deux failles se trouvent dans le moteur PHP, la partie qui reçoit une requête web et la prépare avant que le code de votre boutique ne démarre. C’est pourquoi aucune mise à jour de PrestaShop, aucun module ni aucun thème ne peut les corriger. Seul un PHP corrigé le peut.

Des chercheurs ont aussi démontré qu’un attaquant pouvait lire la mémoire des processus PHP sans se connecter. Cette mémoire peut contenir des mots de passe, des jetons de session et des clés API provenant des requêtes d’autres visiteurs. Voilà pourquoi la section consacrée aux vérifications après correction, en fin de guide, reste importante même si personne n’a déposé de fichier malveillant sur votre serveur.

Toutes les installations PHP qui traitent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le projet PHP estime que le risque est le plus élevé avec mod_php, pour lequel il a démontré une exploitation qui se déclenche avant toute exécution du code de l’application. Ce détail compte pour les marchands PrestaShop : l’authentification du back-office, le mode maintenance et tous les modules de sécurité interviennent après l’analyse de la requête par PHP. Aucun ne peut donc faire barrage.

La protection doit se trouver en amont de PHP. Tout ce qui est dans PrestaShop s'exécute une fois le mal fait.

La chronologie

Pourquoi la situation est plus compliquée pour les boutiques PrestaShop

Voici le tableau qui pose problème. Il indique la version maximale de PHP officiellement prise en charge par chaque branche de PrestaShop, d’après les prérequis système de PrestaShop, et précise s’il existe une version officielle corrigée de PHP dans cette plage.

« Non » dans la troisième colonne ne signifie pas « aucun correctif n’existe ». Cela signifie que le correctif doit venir d’ailleurs que de php.net : d’une distribution Linux, du fournisseur de votre panneau d’hébergement, d’un prestataire de support à long terme ou d’un PHP que vous compilez à partir des sources avec le backport minimal du projet PHP. C’est vers ces solutions que la plupart des boutiques PrestaShop doivent se tourner cette semaine, et c’est aussi là que se trouvent les bonnes nouvelles.

Chaque ligne sans case verte dépend d'un rétroportage fournisseur ou de la transition par PHP 7.4.

Étape 1 : déterminer ce que votre boutique utilise réellement

Deux pièges guettent presque tout le monde à ce stade.

Premier piège : le PHP que vous voyez en SSH n’est pas forcément celui qui fait fonctionner votre boutique. Plusieurs versions de PHP cohabitent souvent sur un serveur, et la ligne de commande peut en utiliser une autre que le serveur web. Dans PrestaShop, ouvrez Paramètres avancés > Informations (Advanced Parameters > Information) : la version PHP affichée est celle qui traite réellement les requêtes de votre boutique. Le réglage PHP du domaine dans votre panneau d’hébergement doit indiquer la même version.

Second piège : le numéro de version ne permet pas de savoir si le correctif est installé. Les distributions et les fournisseurs d’hébergement intègrent les correctifs de sécurité par backport dans votre version existante et conservent son ancien numéro. Un « PHP 7.4.33 » peut être entièrement corrigé sur un serveur et totalement vulnérable sur un autre. La preuve se trouve dans l’avis de sécurité du fournisseur pour votre paquet exact, ou dans une réponse écrite de votre hébergeur.

# Facultatif : certains serveurs indiquent leur version PHP. Cela ne prouve pas la présence du correctif.
curl -sS -I https://www.example-shop.com/ | grep -i '^X-Powered-By:'

# Indices dans les journaux de modifications des paquets. Les deux CVE présentes sont un bon signe.
# Aucun résultat ne prouve rien : certains fournisseurs ne consignent qu'un changement de version. Interrogez-les alors.
# Adaptez le nom du paquet à la version PHP et au gestionnaire qui servent votre boutique.

# Debian et Ubuntu
zgrep -E 'CVE-2026-10961[89]' /usr/share/doc/php7.4-fpm/changelog.Debian.gz

# PHP système de RHEL, AlmaLinux, Rocky et CloudLinux
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'

# cPanel EasyApache (ea-php) et CloudLinux PHP Selector (alt-php)
rpm -q --changelog ea-php74-php-fpm | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog alt-php74-common | grep -E 'CVE-2026-10961[89]'

Votre hébergeur dispose peut-être déjà d’un ancien PHP corrigé, même PHP 5

C’est ce que la plupart des propriétaires de boutiques anciennes ignorent. Plusieurs fournisseurs d’hébergement distribuent leurs propres compilations d’anciennes versions de PHP et les ont également corrigées :

• CloudLinux PHP Selector (alt-php) : les versions corrigées pour PHP 5.2 à 5.6, 7.0 à 7.4 et 8.0 à 8.5 sont arrivées dans les dépôts stables le 22 octobre, sur CloudLinux 7, 8 et 9 (CloudLinux 10 les reçoit via le dépôt de TuxCare).
• Les compilations CloudLinux de PHP pour cPanel (ea-php) : corrigées de ea-php52 à ea-php85, en conservant les anciens numéros de version.
• Le PHP EasyApache fourni directement par cPanel : versions officielles pour les branches 8.2 à 8.5 et backports pour les branches 8.1 (8.1.34-5), 8.0 (8.0.30-12) et 7.4 (7.4.33-19). Les compilations de PHP 7.3 et antérieurs fournies directement par cPanel n’ont pas reçu de correctif ; cPanel oriente leurs utilisateurs vers TuxCare.
• Red Hat et les distributions qui en recompilent les sources : les correctifs sont publiés flux par flux. Consultez les errata correspondant au flux PHP exact activé sur votre serveur, et ne supposez pas qu’une simple mise à jour du système a suffi : les premiers signalements indiquaient que certains flux étaient corrigés et que d’autres attendaient encore.
• TuxCare Endless Lifecycle Support : support payant à long terme avec des correctifs pour les versions de PHP en fin de vie.

Ainsi, le même libellé « PHP 7.1 » dans un panneau d’hébergement peut désigner une version corrigée chez un hébergeur et vulnérable chez un autre. Avant de prévoir la moindre intervention sur le code, posez une question précise à votre hébergeur. Voici un message que vous pouvez envoyer tel quel :

Objet : PHP2Shell (CVE-2026-109618, CVE-2026-109619) sur mon hébergement

Bonjour,
Ma boutique fonctionne sous PHP X.Y (gestionnaire : PHP-FPM / mod_php / LiteSpeed) sur vos serveurs.
La compilation PHP qui sert mon site inclut-elle les correctifs pour CVE-2026-109618 et
CVE-2026-109619 ? Merci de m'indiquer la version exacte du paquet et de me confirmer si les processus PHP
ont été redémarrés depuis son installation. Si ma version ne dispose d'aucun correctif,
vers quelles versions corrigées de PHP puis-je basculer avec mon offre ?
Merci.

Si la réponse est « oui, les deux failles sont corrigées et les processus ont été redémarrés », l’urgence est réglée sans toucher à une ligne de code. Lisez la section sur la recherche d’une éventuelle compromission, puis préparez votre mise à niveau sereinement.

Étape 2 : choisir la marche à suivre pour votre version de PrestaShop

Quelle que soit votre version, le premier choix reste le même : un paquet corrigé pour la branche PHP que votre boutique utilise déjà. Passer à une autre branche PHP est une intervention plus importante, qui doit toujours commencer sur une copie de staging, avec des tests de vos modules, de vos overrides et du parcours de commande.

Interrogez votre hébergeur avant de prévoir des modifications du code : la voie la moins coûteuse est une version corrigée déjà à votre disposition.

PrestaShop 9

Installez la version corrigée de votre branche : 8.2.35, 8.3.36 ou 8.4.27, ou 8.5.12 avec PrestaShop 9.1. Redémarrez et confirmez la version sur la page Informations. Si votre boutique en 9.0 utilise encore PHP 8.1, passer à 8.2 ou à une version plus récente constitue un changement de branche : testez-le d’abord en staging, ou utilisez entre-temps un PHP 8.1 corrigé par un fournisseur.

PrestaShop 8.0 à 8.2

Ces versions prennent officiellement en charge PHP 7.2 à 8.1, et aucune de ces branches ne dispose d’une version corrigée publiée par php.net. Les fournisseurs offrent toutefois plus de possibilités qu’il n’y paraît : un PHP 8.1 corrigé (8.1.34-5 de cPanel, alt-php81 de CloudLinux, le paquet php8.1 d’Ubuntu 22.04, TuxCare), mais aussi un PHP 8.0 ou 7.4 corrigé chez ces mêmes fournisseurs, tous compris dans la plage officielle de PrestaShop 8. Si aucune compilation corrigée ne vous est accessible, la réponse durable est une mise à niveau vers PrestaShop 9. En attendant de disposer d’un environnement PHP corrigé, appliquez les mesures temporaires ci-dessous.

PrestaShop 1.7.8

PHP 7.4 est son plafond officiel, et les compilations corrigées de cette branche sont relativement faciles à trouver : cPanel 7.4.33-19, CloudLinux alt-php74, TuxCare et les paquets des distributions dont le fournisseur les a publiés. Si votre boutique utilise un PHP plus ancien, passer à un PHP 7.4 corrigé reste dans la plage officielle de PrestaShop 1.7.8. Testez tout de même ce changement en staging.

PrestaShop 1.6.1.x et 1.7.0 à 1.7.7

Ces versions s’arrêtent officiellement à PHP 7.1, 7.2 ou 7.3. Demandez d’abord à votre hébergeur s’il dispose d’une compilation corrigée de votre version actuelle (voir ci-dessus). Si c’est le cas, adoptez-la : l’urgence est réglée. Sinon, c’est ici qu’intervient notre solution transitoire.

Notre solution transitoire : passer par un PHP 7.4 corrigé

C’est ce que nous faisons concrètement pour les boutiques dont nous assurons le suivi et qui ne peuvent pas être mises à niveau ce mois-ci. Le principe : faire fonctionner la boutique sur un PHP 7.4 qu’un fournisseur continue de corriger, même si sa version de PrestaShop s’arrête officiellement avant PHP 7.4, puis corriger les portions de code incompatibles. D’après notre expérience, le cœur de PrestaShop 1.6.1 et 1.7 produit surtout des notices et des avertissements de dépréciation sous PHP 7.4, plutôt que des erreurs fatales. Les vrais blocages viennent généralement d’une poignée d’anciens modules et overrides. C’est une solution transitoire, et nous le disons clairement : pendant un temps, votre configuration sort de la matrice de compatibilité officielle de PrestaShop. Mais elle ferme la faille et permet à la boutique de continuer à vendre pendant que vous préparez la véritable mise à niveau.

Une transition, pas une destination : elle ferme la faille et permet à la boutique de vendre jusqu'à la vraie mise à niveau.

Un exemple concret explique pourquoi PHP 7.4 peut fonctionner là où PHP 8 échouerait : le fichier Cookie.php de PrestaShop 1.6.1.23 contient $this->_path{0}. Sous PHP 7.4, cette syntaxe avec accolades est simplement dépréciée ; sous PHP 8.0, elle provoque une erreur fatale. Cette seule ligne fait la différence entre une transition qui tient et une boutique qui ne se charge plus.

1. Créer une copie de staging et la rendre inoffensive

Copiez les fichiers et la base de données dans un espace séparé, par exemple un sous-domaine protégé par mot de passe. Puis, avant que cette copie ne réponde à la moindre requête :

• Faites-la pointer vers sa propre base de données. La configuration copiée contient encore les identifiants de la base de production (config/settings.inc.php sur PrestaShop 1.6, app/config/parameters.php sur PrestaShop 1.7). Remplacez-les par ceux de la base de staging, idéalement avec un utilisateur de base de données sans accès à la production. Toute la suite suppose que vous avez commencé par là.
• Bloquez ses communications sortantes. Avant que la copie ne réponde à sa première requête ou n’exécute la moindre tâche, bloquez au niveau du serveur, indépendamment de PrestaShop, les e-mails sortants et les connexions à vos services de production (API de paiement, de transporteurs et de places de marché). Autorisez uniquement les services sandbox que vous souhaitez tester. Les réglages de PrestaShop ne suffisent pas : certains modules envoient des e-mails ou communiquent avec les places de marché via leurs propres connexions. Désactivez ensuite les tâches cron copiées et passez chaque module de paiement en mode test ou sandbox.
• Bloquez l’accès aux visiteurs et aux moteurs de recherche avec une protection par mot de passe sur le serveur web.

Puis, uniquement dans la base de données de staging :

-- BASE DE STAGING UNIQUEMENT. Remplacez ps_ par votre préfixe de tables.
-- 1. PrestaShop lui-même n'envoie jamais d'e-mail depuis cette copie
UPDATE ps_configuration SET value = '3' WHERE name = 'PS_MAIL_METHOD';

-- 2. Faire pointer la copie vers sa propre adresse (boutique unique, installée à la racine du domaine)
SELECT id_shop_url, id_shop, domain, domain_ssl, physical_uri FROM ps_shop_url;
UPDATE ps_shop_url
SET domain = 'staging.example-shop.com', domain_ssl = 'staging.example-shop.com', physical_uri = '/'
WHERE id_shop_url = 1;
UPDATE ps_configuration SET value = 'staging.example-shop.com'
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL');

Sur une installation multiboutique, faites correspondre séparément les URL de chaque boutique au lieu d’utiliser cet exemple pour une boutique unique.

2. Passer la copie au PHP 7.4 corrigé et relever toutes les erreurs

Sélectionnez le PHP 7.4 corrigé pour le site de staging dans votre panneau d’hébergement. Réglez error_reporting sur E_ALL, consignez les erreurs dans un fichier et désactivez leur affichage à l’écran. Vérifiez que le journal reçoit bien des entrées, puis classez les problèmes par fréquence décroissante :

# Classer les erreurs PHP du staging par fréquence décroissante (format de journal PHP standard)
grep -E 'PHP (Fatal error|Parse error|Recoverable fatal error|Warning|Notice|Deprecated):' /path/to/php-error.log \
  | sed -E 's/^\[[^]]*\] //' | sort | uniq -c | sort -rn | head -40

3. Examiner le code qui pose habituellement problème

Avant de parcourir la boutique, une analyse statique rapide des modules, des overrides et du thème permet de repérer les suspects habituels. Cette vérification reste partielle : elle ne détecte pas les appels indirects, les appels répartis sur plusieurs lignes ni certains accès par indice avec accolades. Un résultat vide ne prouve donc pas la compatibilité. Examinez chaque occurrence.

# Fonctions supprimées ou dépréciées par PHP 7.x
grep -rnE --include='*.php' \
  '\beach\s*\(|create_function\s*\(|get_magic_quotes_(gpc|runtime)\s*\(|\bmysql_[a-z_]+\s*\(|\beregi?(_replace)?\s*\(|\bsplit\s*\(|mcrypt_[a-z_]+\s*\(' \
  modules override themes

# Appels à preg_replace : vérifier chacun pour repérer le modificateur /e supprimé
grep -rnE --include='*.php' '\bpreg_replace\s*\(' modules override themes

# Accès aux caractères avec accolades ($str{0}), déprécié en PHP 7.4
grep -rnE --include='*.php' '\$[A-Za-z_][A-Za-z0-9_]*\{[^}$]*\}' modules override themes

# Vérification de la syntaxe de chaque fichier PHP avec le binaire PHP cible, depuis la racine du staging
# (son nom varie : php7.4, php74, /opt/cpanel/ea-php74/root/usr/bin/php ...)
find . -type f -name '*.php' -exec php7.4 -l {} \; | grep -v '^No syntax errors'

Une vérification syntaxique sans erreur prouve seulement que les fichiers peuvent être analysés. Elle ne dit rien des extensions manquantes ni du comportement du parcours de commande, ce que vous vérifierez à l’étape 5.

4. Corriger les problèmes en commençant par le changement minimal

Voici les problèmes que nous rencontrons le plus souvent lorsqu’une ancienne boutique passe à PHP 7.4, et la correction à apporter à chacun :

Corrigez d’abord les erreurs fatales, puis les avertissements sur le parcours de commande, puis le reste. Les notices et les avertissements de dépréciation ne sont pas anodins sous prétexte que les visiteurs ne les voient jamais : le gestionnaire d’erreurs d’un module peut les transformer en exceptions, et leur accumulation peut saturer le disque. Lorsqu’une mise à jour du module est disponible auprès de son auteur, préférez-la à votre propre correctif. Tenez aussi une liste écrite de chaque fichier modifié : vous en aurez besoin pour le passage en production, puis pour la véritable mise à niveau. Pendant que vous intervenez sur la configuration, supprimez les lignes php_value et php_flag du fichier .htaccess correspondant à des paramètres que PHP ne reconnaît plus. L’avis de sécurité PHP demande expressément de retirer les paramètres par requête invalides ou dépréciés.

<?php
// config/defines_custom.inc.php (PrestaShop 1.6 inclut automatiquement ce fichier)
// PHP 7.2+ est livré sans mcrypt, mais la signature des cookies de la 1.6.1 lit toujours cette
// constante. Même valeur que celle définie par l'extension mcrypt : les cookies existants restent valides.
if (!defined('MCRYPT_RIJNDAEL_128')) {
    define('MCRYPT_RIJNDAEL_128', 'rijndael-128');
}

Voici le code concerné, inchangé depuis PrestaShop 1.6.1.23 (classes/Rijndael.php) :

// PrestaShop 1.6.1.23, classes/Rijndael.php
protected function generateHmac($encrypted)
{
    $macKey = $this->generateKeygenS2k('sha256', $this->_key, $this->_iv, 32);
    return hash_hmac(
        'sha256',
        $this->_iv . MCRYPT_RIJNDAEL_128 . $encrypted,
        $macKey
    );
}

5. Tester tout le parcours de vente, puis basculer avec les correctifs

Sur le staging, passez en revue tout ce qui génère des ventes ou du travail : page d’accueil, pages de catégories avec filtres, recherche, fiches produits avec déclinaisons, panier, parcours de commande avec chaque transporteur et chaque moyen de paiement en mode test, confirmation de commande, page de commande du back-office, PDF des factures et des bons de livraison, page de configuration de chaque module, imports et URL des tâches cron.

Lorsque le journal ne signale plus de problème, prévoyez la bascule en production à une heure creuse :

• Effectuez une sauvegarde dont vous avez réellement testé la restauration au moins une fois, fichiers et base de données compris.
• Déployez les correctifs de code testés et changez de PHP en même temps. Les correctifs restent sur le staging tant que vous ne les avez pas copiés en production. Ne remplacez jamais la base de production par celle du staging.
• Vérifiez immédiatement le parcours de commande, puis surveillez le journal d’erreurs pendant 48 heures.
• Si vous devez revenir en arrière vers l’ancien PHP non corrigé, restreignez l’accès à la boutique pendant l’opération et maintenez cette restriction jusqu’au retour à un environnement PHP corrigé.

En attendant le correctif : les mesures temporaires

Le projet PHP a publié des mesures qui réduisent l’exposition à certains vecteurs d’attaque. Il précise lui-même qu’elles ne sécurisent pas une installation et que seule une mise à jour apporte une correction complète. Elles ne garantissent pas non plus un délai d’attente sans risque. Elles méritent d’être appliquées pendant les quelques heures ou jours qui vous séparent d’un PHP corrigé pour votre boutique. Voici comment les mettre en œuvre sur PrestaShop.

Les paramètres PHP

Ces paramètres doivent être définis dans php.ini, dans le pool PHP-FPM ou dans la configuration du serveur, pas dans .user.ini ni avec ini_set(). Redémarrez ensuite tous les processus PHP.

; Mesures temporaires PHP2Shell dans php.ini (redémarrer PHP ensuite)
; Le cœur de PrestaShop n'utilise pas le suivi de progression des envois : il peut être désactivé sans risque
session.upload_progress.enabled = 0
; Réduire la taille des corps de requête. Valeurs d'exemple : adaptez-les aux besoins réels de votre boutique,
; sans jamais augmenter une limite existante plus basse
post_max_size = 32M
upload_max_filesize = 24M
max_file_uploads = 10

; Dans un fichier de pool PHP-FPM (par exemple /etc/php/7.4/fpm/pool.d/shop.conf), les mêmes
; paramètres s'écrivent ainsi ; retirez les points-virgules en début de ligne pour les activer :
; php_admin_flag[session.upload_progress.enabled] = off
; php_admin_value[post_max_size] = 32M
; php_admin_value[upload_max_filesize] = 24M

Après avoir modifié les limites, testez les envois de fichiers que votre équipe utilise réellement : une archive de module volumineuse ou une grande image produit peut les dépasser. La liste officielle suggère aussi memory_limit = -1 contre la faille liée à l’épuisement de mémoire, en imposant ce réglage pour qu’aucun paramètre de l’application ne puisse rétablir une limite. Une seule requête peut alors utiliser toute la mémoire du serveur. Cette mesure s’adresse donc uniquement aux administrateurs capables d’encadrer PHP par une limite mémoire de conteneur ou de cgroup et qui savent ce qui se passe lorsqu’elle est atteinte. Elle ne ferme pas complètement la faille, et l’avis déconseille d’utiliser RLIMIT_AS ou RLIMIT_DATA à la place. Sur un hébergement mutualisé, laissez votre hébergeur s’en charger. Pour PHP 8.5, l’avis mentionne aussi fatal_error_backtraces = 0.

Refuser les envois de fichiers là où la boutique n’en a pas besoin

L’exploit connu arrive sous la forme d’une requête multipart/form-data, le format utilisé par les navigateurs pour envoyer des fichiers. La majeure partie du front-office d’une boutique PrestaShop n’en a jamais besoin. Bloquer ces requêtes en dehors du back-office coupe ce vecteur connu. Ce qui cesse de fonctionner : les pièces jointes du formulaire de contact, les champs de fichier de la personnalisation produit et tout module permettant aux clients d’envoyer des fichiers. Pour la plupart des boutiques, c’est un compromis acceptable pendant quelques jours.

Une condition préalable : l’exception pour le back-office n’a de sens que si son accès est limité à vos propres adresses IP au niveau du serveur web, afin que les requêtes provenant d’ailleurs n’atteignent jamais PHP. Une page de connexion PrestaShop ne peut pas protéger contre une faille qui se déclenche avant l’exécution de PrestaShop. Notre article sur la sécurité du back-office propose des listes d’autorisation prêtes à l’emploi pour Apache et nginx. Si vous ne pouvez pas verrouiller le back-office, supprimez l’exception et suspendez aussi les envois de fichiers depuis le back-office pendant quelques jours.

Sur Apache, placez ceci tout en haut du fichier .htaccess de la boutique, au-dessus de la ligne # ~~start~~, pour que PrestaShop le conserve lorsqu’il régénère le fichier. Remplacez admin-folder-name par le nom de votre dossier de back-office :

# Mesure temporaire PHP2Shell : refuser les requêtes multipart hors du back-office.
# À retirer après installation du correctif.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteCond %{REQUEST_URI} !^/admin-folder-name/
RewriteRule ^ - [F]
</IfModule>

Cette règle ne fonctionne que si mod_rewrite est actif et si les fichiers .htaccess sont autorisés à l’utiliser. Testez-la : l’envoi d’un fichier inoffensif via le formulaire de contact doit désormais renvoyer une page d’erreur 403, et cette page d’erreur ne doit pas elle-même être un script PHP.

Sur nginx, dans le bloc server de la boutique :

# Mesure temporaire PHP2Shell : refuser les requêtes multipart hors du back-office.
set $block_multipart 0;
if ($http_content_type ~* "multipart/form-data") { set $block_multipart 1; }
if ($uri ~ "^/admin-folder-name/") { set $block_multipart 0; }
if ($block_multipart) { return 403; }

Utilisez $uri, le chemin normalisé, comme ci-dessus. La variable brute $request_uri pourrait être trompée par un chemin tel que /admin-folder-name/../index.php.

Les protections en amont de votre boutique

• Cloudflare a déployé des règles WAF contre les vecteurs d’exploitation connus, y compris pour les offres gratuites. Elles ne sont utiles que si tout le trafic de votre boutique passe réellement par Cloudflare et si personne ne peut accéder directement à votre serveur. Sur les offres payantes, vérifiez aussi que les règles gérées sont configurées pour bloquer. Des attaquants auraient déjà cherché des moyens de les contourner.
• Imunify360, courant sur les hébergements mutualisés, a publié des règles qui bloquent l’outil d’exploitation public et des variantes de CVE-2026-109619. D’après CloudLinux, ses règles ne couvrent pas encore CVE-2026-109618. Les autres pare-feu ont leur propre couverture, qui diffère.
• Le mode maintenance ne protège pas. PrestaShop décide d’afficher la page de maintenance après que PHP a déjà traité la requête. Si votre hébergeur ne peut pas corriger rapidement, demandez-lui s’il peut empêcher toute requête non fiable d’atteindre PHP.

Après le correctif : rechercher une éventuelle compromission

Des tentatives ont été observées avant la divulgation, et la faille de lecture de la mémoire peut laisser fuiter des secrets sans laisser de trace dans votre boutique. Si votre boutique était accessible sur Internet avec un PHP non corrigé après la mi-octobre, consacrez une heure à ces vérifications. Elles permettent de trouver des traces courantes ; un résultat sans anomalie ne prouve pas qu’il ne s’est rien passé.

# Fichiers exécutables dans les dossiers censés contenir des images et des fichiers envoyés.
# PrestaShop fournit un index.php dans presque chaque dossier : comparez-les aussi à une copie saine.
find img upload download -type f \( -iname '*.php' -o -iname '*.phtml' -o -iname '*.phar' \)

# Fichiers modifiés depuis les premières tentatives d'exploitation (17 octobre 2026), caches compris.
# De simples pistes : les horodatages peuvent être falsifiés. Lisez toute la liste.
find . -type f -newermt '2026-10-17 00:00:00 UTC'

-- Comptes du back-office, du plus récent au plus ancien. Un compte vous est inconnu ?
SELECT id_employee, firstname, lastname, email, active, last_connection_date
FROM ps_employee
ORDER BY id_employee DESC;

La comparaison la plus fiable se fait avec une copie saine de votre version de PrestaShop, de vos modules et une sauvegarde antérieure au 17 octobre. Incluez les fichiers JavaScript, où se logent les scripts injectés qui dérobent les données de paiement. Si vous trouvez quelque chose, conservez les preuves et endiguez la compromission avant de changer le moindre mot de passe, sinon les nouveaux identifiants fuiteront de la même façon.

Renouvelez ensuite, depuis un appareil de confiance, les secrets qu’une fuite de mémoire aurait pu exposer : tous les mots de passe du back-office, les clés API des modules de paiement, de transporteurs et de places de marché, les clés du webservice et les mots de passe SMTP. Pour le mot de passe de la base de données, changez-le simultanément sur le serveur de base de données et dans la configuration de la boutique (config/settings.inc.php sur PrestaShop 1.6, app/config/parameters.php à partir de PrestaShop 1.7), ainsi que dans tout autre service qui l’utilise pour se connecter, sinon la boutique deviendra indisponible.

Questions fréquentes

Sources

• Projet PHP : avis de sécurité et annonces de publication, avec les avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp
• PrestaShop : prérequis système des versions 1.6 et 1.7, 8 et 9
• CloudLinux : couverture de PHP2Shell et état des paquets
• Sansec : recherche sur PHP2Shell pour le e-commerce