PHP2Shell : la faille PHP qui menace votre boutique PrestaShop

Le 20 octobre, une alerte a mis la moitié d'internet sur le qui-vive : deux failles graves dans PHP, le langage qui fait tourner votre boutique PrestaShop, permettent à un inconnu de prendre le contrôle du serveur sans identifiant ni mot de passe. On les appelle PHP2Shell. PHP a publié le correctif le 21 octobre, et ce que vous devez faire dépend d'une seule chose : la version de PHP sur laquelle tourne votre boutique.

On vous l'explique sans jargon : ce qui s'est passé, comment savoir si vous êtes concerné, quoi faire aujourd'hui et comment savoir si votre hébergeur a déjà appliqué le correctif.

Qu'est-ce que PHP2Shell et pourquoi est-ce si grave ?

PHP est le moteur qui se trouve sous PrestaShop, WordPress, Magento et la plupart des boutiques et des sites du monde. Les deux failles, enregistrées sous les références CVE-2026-109618 et CVE-2026-109619, ont une note de gravité de 9,2 sur 10. Concrètement, celui qui sait les exploiter peut exécuter ce qu'il veut sur votre serveur : laisser une porte dérobée, voler les données de vos clients ou glisser dans votre boutique un faux captcha comme celui de ClickFix.

Ce qui distingue PHP2Shell des autres alertes, c'est que l'attaque ne passe ni par PrestaShop ni par aucun module. Elle se produit dans PHP, avant même que votre boutique ne lise la visite. Peu importe le soin que vous y apportez : si le PHP du serveur est vulnérable, la boutique l'est aussi.

Et l'information avait fuité avant l'heure. La société de sécurité Sansec explique qu'avec l'alerte est apparue la capture d'un outil d'attaque déjà prêt, et elle s'attendait à des attaques massives dès la publication du correctif. Selon la même source, Cloudflare avait déjà repéré les premières tentatives et a mis en place des règles pour les bloquer.

Ma boutique PrestaShop est-elle concernée ?

Très probablement, oui. Dans son bulletin de sécurité, PHP considère comme exposée toute installation qui sert des pages web, quelle que soit la façon dont le serveur l'exécute, et le risque le plus élevé concerne les serveurs Apache avec mod_php, où une attaque fonctionnant sans identifiant ni mot de passe a déjà été démontrée. Sansec parle de tout serveur sous PHP 5.4 ou plus récent, c'est-à-dire, en pratique, toutes les boutiques PrestaShop en ligne aujourd'hui.

La question qui compte vraiment est ailleurs : le correctif vous parvient-il ? PHP l'a corrigé dans les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour les anciennes versions, qui n'ont plus de support officiel, PHP a publié le correctif sans nouvelle version, et en un ou deux jours les panneaux et systèmes qu'utilisent les hébergeurs en ont fait une mise à jour normale : cPanel et CloudLinux, de PHP 5.2 à 8.1 ; DirectAdmin, Ubuntu, Red Hat, AlmaLinux et le dépôt Remi, pour les versions 7.4 à 8.1 qu'ils maintiennent encore. Et chaque version de PrestaShop ne fonctionne qu'avec certaines versions de PHP :

• PrestaShop 1.6 : fonctionne avec PHP 5.6 à 7.1. Il existe un correctif si votre hébergeur utilise cPanel ou CloudLinux ; ailleurs, seulement avec un support étendu payant, comme celui de TuxCare ou de Zend.
• PrestaShop 1.7 : PHP 7.4 au maximum. Le 7.4 corrigé existe déjà sur presque tous les panneaux : il reste à votre hébergeur à l'installer.
• PrestaShop 8 : PHP 8.1 au maximum. Comme pour la 1.7 : le 8.1 corrigé existe déjà et dépend de votre hébergeur.
• PrestaShop 9 : fonctionne avec PHP 8.1 à 8.4. Avec PHP 8.2 ou plus, il reçoit la mise à jour officielle ; en 8.1, il suffit de monter la version de PHP.

Autrement dit : presque n'importe quelle boutique peut tourner aujourd'hui sur un PHP sans cette faille. Mais si ce n'est pas PrestaShop 9, cela dépend de votre hébergeur, et comme le numéro de version ne change pas, cela ne se voit pas : il faut lui poser la question. C'est aussi un correctif d'urgence : PHP 8.1 et les versions antérieures n'ont plus de support officiel, et à la prochaine faille vous dépendrez de nouveau de quelqu'un qui la corrige de son côté.

Comment savoir quelle version vous avez

Connectez-vous au back-office de votre boutique et ouvrez Paramètres avancés → Informations. Vous y verrez la version de PrestaShop et, un peu plus bas, celle de PHP. Avec ces deux numéros, vous savez déjà dans quel cas vous êtes.

Ce qu'il faut faire aujourd'hui, dans l'ordre

1. Regardez vos deux versions, PrestaShop et PHP, comme expliqué plus haut.
2. Faites une sauvegarde complète, fichiers et base de données, et gardez-la hors du serveur. En cas de problème, c'est la seule chose qui vous permet de revenir en arrière.
3. Si votre boutique est sous PrestaShop 9, demandez à votre hébergeur de mettre à jour PHP en 8.2.35, 8.3.36, 8.4.27 ou 8.5.12 ou plus récent, ou faites-le vous-même depuis le panneau de l'hébergement s'il vous laisse choisir la version. Si vous êtes en PHP 8.1, profitez-en pour passer en 8.3 ou 8.4.
4. Si vous utilisez Cloudflare, vérifiez que le nuage de votre domaine est orange : le trafic passe alors par ses règles avant d'arriver à votre serveur. Cela ne sert pas à grand-chose si l'adresse de votre serveur est connue et accepte les visites de n'importe qui, alors demandez à votre technicien de ne l'ouvrir qu'à Cloudflare.
5. Si votre boutique est en 1.6, 1.7 ou 8, demandez à votre hébergeur s'il a déjà installé le correctif PHP2Shell pour votre version de PHP. S'il ne l'a pas, demandez à votre prestataire les mesures d'urgence décrites plus bas. Et fixez une date pour la mise à jour vers PrestaShop 9 : c'est ainsi qu'on retrouve un PHP avec support officiel.

Passer la boutique en maintenance depuis le back-office ne vous protège pas cette fois : PHP lit la visite avant que PrestaShop ne décide d'afficher la page de maintenance.

Et si mon hébergeur n'a pas le correctif ?

PHP propose des réglages du serveur qui ferment certaines voies d'attaque, et prévient qu'ils ne suffisent pas à sécuriser la boutique : seule la mise à jour le fait. Sansec ajoute une autre mesure d'urgence : bloquer sur le serveur le type d'envoi qui transporte les fichiers qu'on téléverse sur un site. Elle a un prix : tant qu'elle est en place, personne ne peut envoyer de fichiers sur votre boutique. Ni vous les photos d'un nouveau produit, ni vos clients une pièce jointe dans le formulaire de contact. La boutique continue de vendre normalement.

Cela fait gagner quelques jours, pas plus : soit votre hébergeur installe le correctif, soit vous passez chez un hébergeur qui l'a. Et à la prochaine faille de PHP — il y en aura —, votre boutique en dépendra de nouveau, car PHP 8.1 et les versions antérieures n'ont plus de support officiel.

Quel PHP accepte chaque version de PrestaShop, et jusqu'à quand il reçoit des correctifs : tout est dans un tableau, dans quelle version de PHP pour PrestaShop.

Est-ce le moment de mettre à jour PrestaShop ?

C'est la question qu'on repousse toujours parce que la boutique fonctionne. PHP2Shell, c'est ce qui arrive quand on la repousse trop longtemps : le jour où le problème arrive, ce n'est pas vous qui le choisissez, et que le correctif vous parvienne dépend d'autres que vous.

Passer à PrestaShop 9 vous place sur un PHP qui reçoit des correctifs pendant des années. Cela se fait sans fermer la boutique, vous gardez vos produits, vos clients, vos commandes et vos positions sur Google, et une petite boutique coûte à partir de 690 €. On vous explique tout dans mettre à jour PrestaShop 1.7 ou 1.6 vers 9, et sur notre page de migration de PrestaShop 1.6 et 1.7 vers 9.

Et si vous préférez ne pas surveiller ce genre d’alertes, c’est le rôle du contrat de maintenance PrestaShop : nous surveillons votre boutique, tenons ses modules à jour et, si elle est sur un serveur BK Modules, PHP aussi, pour qu’une alerte comme celle-ci ne vous prenne pas au dépourvu.

Besoin d'aide aujourd'hui ?

Si vous ne savez pas dans quel cas vous êtes, si votre hébergeur ne vous répond pas ou si votre boutique est en 1.6, 1.7 ou 8 et que vous voulez en sortir, indiquez-nous votre version de PrestaShop et celle de PHP. On vous dit quoi faire aujourd'hui et, si besoin, on vous donne un prix ferme pour passer à PrestaShop 9.

Je veux mettre à jour ma boutique

Pour votre équipe technique

Versions corrigées : 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Pour 7.4, 8.0 et 8.1, PHP publie le correctif minimal en code source, lié depuis son avis, sans nouvelle version. Les paquets corrigés gardent leur numéro de version, donc php -v ne les distingue pas : il faut vérifier la révision du paquet (rpm -q, dpkg -l). Révisions corrigées : cPanel EasyApache 4 ea-php74 7.4.33-19, ea-php80 8.0.30-12, ea-php81 8.1.34-5; CloudLinux ea-php / alt-php 5.2–8.5 (21–22/10); Remi 7.4.33-31, 8.0.30-21, 8.1.34-6; Ubuntu 22.04 8.1.2-1ubuntu2.28. Les mesures partielles que donne PHP se mettent dans le php.ini, dans le pool PHP-FPM (php_admin_value) ou dans la configuration du serveur, jamais avec ini_set() ni .user.ini, en redémarrant tous les processus :

; CVE-2026-109618
memory_limit = -1
post_max_size = 32M   ; 8M si aucun fichier n'est envoyé
; CVE-2026-109619
session.upload_progress.enabled = 0
; uniquement en PHP 8.5
fatal_error_backtraces = 0

PHP demande de ne pas remplacer memory_limit par des limites du système (RLIMIT_AS, RLIMIT_DATA). La mesure de Sansec, bloquer multipart/form-data (elle casse tous les envois de fichiers, back-office compris), sous Apache :

RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Sous Nginx :

if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Avec Cloudflare, limiter le port 443 de l'origine à ses plages d'IP ; sinon, l'attaque arrive directement sur l'IP du serveur.