Faille du kernel Linux : votre boutique PrestaShop est-elle touchée ?

Votre boutique en ligne · 7 min de lecture

Faille du kernel Linux : votre boutique PrestaShop est-elle touchée ?

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.

Vérifier ma boutique pour 45 €

Que s'est-il passé avec le kernel Linux ?

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.

Peut-on entrer dans ma boutique PrestaShop par cette faille ?

À 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 :

  • Un module avec une faille de sécurité qui permet d'exécuter du code sur votre serveur.
  • Un autre site de votre propre compte, comme ce vieux WordPress que personne ne met à jour.
  • Le site d'un autre client, si vous êtes sur un hébergement mutualisé. CloudLinux, dont beaucoup d'hébergeurs utilisent le système, prévient qu'un client malveillant pourrait atteindre d'autres comptes de la même machine.
  • Une faille de PHP, comme PHP2Shell.

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.

Pourquoi mettre à jour le serveur ne suffit-il pas ?

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.

Que dois-je faire selon l'endroit où se trouve ma boutique ?

Si vous êtes sur un hébergement mutualisé

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.

Si vous avez un VPS ou un serveur dédié

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.

Si votre boutique tourne dans un conteneur

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.

Que faire aujourd'hui, dans l'ordre

  1. Déterminez votre cas : mutualisé, serveur propre ou conteneur. Si vous ne savez pas, demandez à votre hébergeur.
  2. Faites une sauvegarde complète, fichiers et base de données, et gardez-la hors du serveur.
  3. Envoyez le message à votre hébergeur, ou mettez à jour et redémarrez si le serveur est à vous.
  4. Fermez les portes d'entrée : PHP avec le correctif de PHP2Shell, modules à jour, et dehors ce que vous n'utilisez plus, modules ou vieux sites de votre compte. Le PHP accepté par chaque version se trouve dans quelle version de PHP pour PrestaShop.
  5. Cherchez des signes que quelqu'un est déjà entré, comme une fenêtre étrange en visitant votre boutique ou des fichiers que vous ne reconnaissez pas.

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.

Pour votre équipe technique

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.

Comment nous pouvons vous aider

Voir tous les services →
Un coup de main sur votre projet ? Parlons-en

Dites-nous ce dont votre entreprise a besoin

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.