Quelle version de PHP pour PrestaShop ? Tableau 1.6, 1.7, 8 et 9
Le PHP accepté par chaque version de PrestaShop, jusqu'à quand chaque PHP reçoit des correctifs, et que faire avant la…
Si vous avez lu qu'il y a une faille grave du kernel Linux, le noyau du système, et que vous avez une boutique PrestaShop, il y a de fortes chances que cela vous concerne : presque toutes les boutiques tournent sous Linux. Cette faille ne permet à personne d'entrer directement dans votre boutique depuis internet, mais celui qui a déjà réussi à exécuter quelque chose sur votre serveur peut s'emparer de toute la machine. Ce que vous devez faire aujourd'hui dépend de l'endroit où se trouve votre boutique : sur un hébergement mutualisé, vous interrogez votre fournisseur ; sur votre propre serveur, vous mettez à jour et vous redémarrez.
L'alerte qui a relancé le sujet est tombée le 28 octobre, quand l'agence américaine de cybersécurité, la CISA, a ajouté la faille Fragnesia à sa liste des vulnérabilités déjà utilisées dans de vraies attaques.
Pas le temps de tout lire ? Pour 45 €, nous regardons avec vous dans quel cas se trouve votre boutique et ce qu'il faut demander à votre hébergeur. C'est une heure de support à prix fixe ; s'il en faut plus, nous vous le disons avant de continuer. Nous répondons en moins de 12 heures, week-end compris.
Le kernel, ou noyau, est la pièce centrale de Linux : celle qui commande tout ce qui tourne sur le serveur. Plusieurs failles graves se sont succédé cette année, d'où tous ces titres : Copy Fail, Dirty Frag, Fragnesia, GhostLock, Vghost. Depuis mai, la CISA a ajouté huit failles du kernel à cette liste.
Inutile d'apprendre les noms. Ces cinq-là ont en commun ce qui compte vraiment pour vous : ce sont des failles locales.
À elle seule, non. Microsoft l'explique à propos de Copy Fail : l'attaquant doit déjà avoir un pied sur la machine. Et Red Hat dit la même chose de Fragnesia : il faut un accès local au système.
Imaginez votre serveur comme un immeuble de bureaux. Ces failles n'ouvrent pas la porte sur la rue. Mais à celui qui est déjà à l'intérieur, même dans un placard, elles donnent les clés de tout l'immeuble.
Et comment arrive-t-on dans ce placard ? Par des chemins assez courants :
Ce dernier cas n'a rien de théorique. Dans sa fiche sur Fragnesia, la CISA avertit que cette faille peut s'enchaîner avec PHP2Shell pour installer une porte dérobée et exécuter des commandes avec le contrôle total du serveur. La CISA n'a pas donné de détails sur ces attaques et ce que nous avons lu ne parle pas de boutiques en ligne : pas de raison de paniquer, mais toutes les raisons de fermer les deux.
Parce qu'un nouveau kernel ne sert à rien tant que le serveur n'a pas démarré dessus. Ubuntu, AlmaLinux et le centre canadien pour la cybersécurité le rappellent : mettre à jour et redémarrer. Un serveur peut avoir le correctif installé depuis des semaines et tourner encore sur l'ancien kernel.
L'autre façon de faire est le correctif à chaud : des outils comme KernelCare, qui appliquent le correctif sur le kernel en marche, sans redémarrer. Sur un hébergement mutualisé, chaque redémarrage coupe le service de tous les clients ; « nous n'avons pas redémarré » n'est donc pas mauvais signe si l'on vous dit que le correctif à chaud est en place.
Vous entrez dans un panneau, comme cPanel ou Plesk, et vous n'administrez pas le serveur. Le kernel est l'affaire de votre fournisseur ; la vôtre est de lui poser la question. Copiez et envoyez ceci :
Bonjour. Ma boutique est hébergée chez vous, sur le domaine [votre domaine]. Au sujet des failles du kernel Linux publiées cette année, en particulier Fragnesia (CVE-2026-46300), pouvez-vous me confirmer les points suivants ?
1. Quelle version du kernel tourne en ce moment sur mon serveur et si elle contient le correctif de cette faille.
2. Si le serveur a redémarré après son installation ou s'il est protégé par un correctif à chaud.
3. Si le PHP de mon compte contient le correctif de PHP2Shell (CVE-2026-109618 et CVE-2026-109619).
4. Comment mon compte est isolé des autres sites de la même machine.
Merci.
Une bonne réponse contient des données : une version, une date, le nom de l'outil. Si l'on vous répond seulement « nous sommes à jour », redemandez la version. Si ce n'est pas clair au bout de quelques jours, c'est le bon moment pour envisager de changer.
Ici, c'est à vous de jouer, ou à celui qui s'en occupe : installer les mises à jour de sécurité et redémarrer. Choisissez une heure creuse, car la boutique est coupée quelques minutes, et au retour vérifiez qu'on peut acheter.
Comparez ensuite la version qui tourne avec celle de l'avis de votre système : Ubuntu, Debian, AlmaLinux ou Red Hat. Chaque système numérote à sa façon : regardez toujours le vôtre.
Docker et consorts, ainsi que certains VPS bon marché qui sont en réalité des conteneurs. Ils partagent le kernel de la machine qui les héberge : mettre à jour de l'intérieur ne change donc rien. Le correctif revient à celui qui administre cette machine : si c'est votre fournisseur, envoyez-lui le message ci-dessus.
Mettre à jour ferme la porte, mais ne met pas dehors celui qui est déjà entré. Microsoft prévient que les mesures de protection peuvent ne pas défaire ce qu'un attaquant a déjà fait.
Si quelque chose vous semble louche, commencez par à quoi ressemble une boutique piratée par ClickFix, et ne supprimez rien avant qu'on ait vérifié : ces fichiers disent par où ils sont entrés.
Vous préférez que quelqu'un s'en charge ? Avec la maintenance PrestaShop, nous surveillons votre boutique, nous corrigeons ses pannes et nous gardons ses modules à jour, testés avant d'être appliqués : c'est la porte d'entrée qui est entre vos mains. Et si votre boutique est sur un serveur géré par BK Modules, nous nous occupons aussi de son PHP, de ses e-mails et de ses certificats.
Kernel en marche : uname -r face à celui qui est installé (rpm -q kernel, dpkg -l 'linux-image*'). Les correctifs arrivent par backport sans changement visible de version : c'est la révision du paquet qui compte, pas le numéro de kernel.org.
Révisions avec le correctif de Fragnesia (CVE-2026-46300) : Ubuntu 26.04 7.0.0-22.22, 24.04 6.8.0-124.124, 22.04 5.15.0-181.191 ; AlmaLinux 8 4.18.0-553.124.3.el8_10, 9 5.14.0-611.54.5.el9_7, 10 6.12.0-124.56.3.el10_1. Chaque CVE a la sienne : installez la dernière de votre branche.
Pas encore fermée sur toutes les branches : Vghost (CVE-2026-74580). Au 4 novembre, Ubuntu la donne corrigée sur 26.04 et 22.04 et en cours sur 24.04. Red Hat la situe surtout sur les machines de virtualisation et elle exige un accès à /dev/vhost-* : en attendant le correctif, ne l'exposez ni aux conteneurs ni aux utilisateurs non fiables.
Vous préférez que nous nous en chargions ? Nous le laissons en place dans votre boutique, avec suivi et support.
Un module, une application, un serveur qui pose problème ou quelque chose d’urgent. Nous répondons sous 24 heures, avec un devis ferme, prix et date compris.