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 explique tout sans jargon : ce qui s'est passé, comment savoir si vous êtes concerné, quoi faire aujourd'hui et quoi faire si votre boutique tourne sur une version qui ne reçoit pas 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 une autre : recevez-vous le correctif ? PHP a corrigé les failles dans les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour officielles : pour 7.4, 8.0 et 8.1, PHP a mis à disposition un correctif minimal à compiler à la main, et certains fournisseurs de support étendu l'intègrent à leurs paquets. Or chaque version de PrestaShop ne fonctionne qu'avec certaines versions de PHP :

• PrestaShop 1.6 : fonctionne avec PHP 5.6 à 7.1. Pas de correctif.
• PrestaShop 1.7 : PHP 7.4 au maximum. Pas de mise à jour officielle ; seule la 7.4 peut recevoir le correctif minimal compilé à la main.
• PrestaShop 8 : PHP 8.1 au maximum. Pas de mise à jour officielle ; le correctif minimal pour la 8.1 doit lui aussi être compilé à la main.
• PrestaShop 9 : fonctionne avec PHP 8.1 à 8.4. Avec PHP 8.2 ou plus, il reçoit la mise à jour ; s'il est en 8.1, il suffit de monter la version de PHP.

Autrement dit : si votre boutique n'est pas sous PrestaShop 9, il n'y a pas de mise à jour officielle à installer, car votre version de PrestaShop ne peut pas fonctionner avec un PHP qui l'a reçue. Reste le correctif minimal, qui est un travail de technicien et qui ne vous protégera pas non plus de la prochaine faille.

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 applique le correctif à votre version de PHP, demandez à votre technicien les mesures d'urgence décrites plus bas et fixez une date pour la mise à jour vers PrestaShop 9. C'est le seul moyen de retrouver un PHP qui reçoit des correctifs.

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 ma boutique ne peut pas recevoir 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 sert à gagner quelques jours, pas à rester ainsi. La prochaine fois qu'une faille sortira dans PHP — et il y en aura —, votre boutique se retrouvera dans la même situation, car PHP 8.1 et les versions antérieures ne reçoivent plus de mises à jour.

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 le correctif n'est pas à votre portée.

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 avoir à surveiller ce genre d'alertes, c'est exactement ce que couvre un contrat de maintenance : quelqu'un qui met à jour PHP, PrestaShop et les modules pour vous, et qui vous prévient avant que le problème n'atteigne votre 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 des branches avec le correctif minimal en code source, liées depuis son bulletin ; ce ne sont pas des versions officielles. Les mesures partielles données par PHP, 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, puis 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 les paquets du dépôt Remi (courant sous RHEL, AlmaLinux ou Rocky), Sansec prévenait que la mise à jour n'arrivait pas le jour même : vérifier la version installée avec php -v. Avec Cloudflare, limiter le port 443 de l'origine à ses plages d'IP ; sinon, l'attaque arrive directement sur l'IP du serveur.

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