OUFRIDpar Imad Oufrid
Sécurité

Faille Linux exploitée et PHP2Shell : ce que les propriétaires de sites et de VPS au Maroc doivent vérifier

Par · publié le

Lire le guide PHP2Shell pas à pas →

Le 28 octobre 2026, l'agence américaine de cybersécurité (CISA) a ajouté une faille du noyau Linux, surnommée « Fragnesia », à sa liste des failles exploitées. Selon elle, des attaquants l'enchaînent avec PHP2Shell, la faille PHP corrigée le 21 octobre : d'abord un accès au serveur par PHP, puis les pleins pouvoirs (root) grâce au noyau. La veille, une autre faille du noyau, dans TCP, avait fait parler d'elle. Voici ce qui est établi, qui est concerné et quoi vérifier.

En bref

Ce qui s'est passé

Fragnesia. Publiée le 13 mai 2026 avec une démonstration, elle est notée 7,8 sur 10 : il faut déjà pouvoir exécuter du code sur le serveur pour l'utiliser. C'est justement ce qu'apporte PHP2Shell (CVE-2026-109618 et CVE-2026-109619), que la CISA a classée comme exploitée le 26 octobre. Dans sa fiche du 28 octobre, la CISA écrit que Fragnesia « peut être enchaînée » avec ces deux failles « pour implanter des web shells PHP et exécuter des commandes en tant que root ». Elle a fixé aux administrations fédérales américaines une date limite au 31 octobre.

L'attaque concrète a été décrite le 26 octobre par l'entreprise de sécurité Dream. Une seule requête HTTPS exploite PHP2Shell, puis Fragnesia donne les droits root ; l'attaquant laisse ensuite une page PHP piégée (un « web shell ») pour revenir quand il veut. Dream dit avoir trouvé environ 25 systèmes compromis aux États-Unis, au Japon, à Taïwan et en Corée du Sud. Précision importante : il s'agissait de pare-feu Palo Alto dont l'interface d'administration était exposée sur Internet, pas de sites web. Mais rien dans la technique ne la limite à ces appareils : tout serveur Linux qui exécute un PHP vulnérable sur un noyau non corrigé présente le même enchaînement possible.

CVE-2026-98432. C'est une erreur de mémoire dans le code TCP du noyau, déclenchable pendant l'ouverture d'une connexion, avant toute authentification. L'équipe du noyau la note 9,8 sur 10 ; Red Hat, Oracle et SUSE 8,1, car la course à gagner est difficile. Le 27 octobre, Anthropic a publié un billet de recherche : un de ses modèles d'IA a écrit, en laboratoire, un exploit qui donne un accès root à distance sur un serveur Linux ayant un écouteur multipath TCP (MPTCP) actif. L'exploit n'a pas été publié et aucune attaque réelle n'est rapportée. Ce n'est pas une raison de paniquer, mais c'en est une d'appliquer le correctif dès qu'il arrive.

KSMBD. Les 21 et 22 octobre, deux failles du serveur de partage de fichiers SMB intégré au noyau (ksmbd), notées 9,0 par la Zero Day Initiative, ont été rendues publiques avant tout correctif : elles ne concernent que les serveurs où ce module est chargé, ce qui est rare sur un serveur web.

Qui est concerné ?

Comment vérifier sur un VPS

Ces commandes ne modifient rien : elles affichent seulement des informations.

1. Quel noyau tourne réellement ?

uname -r

2. Le correctif Fragnesia est-il dans ce noyau ?

# AlmaLinux, Rocky, Red Hat
rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-46300

# Debian, Ubuntu
apt changelog linux-image-$(uname -r) | grep CVE-2026-46300

Une ligne s'affiche : le correctif est présent. Rien : vérifiez l'avis de votre distribution. Repères : sur Red Hat 9, le noyau corrigé est le 5.14.0-687.10.1.el9_8 (20 mai 2026) ou plus récent ; sur Ubuntu 24.04, 6.8.0-124 ou plus récent ; sur Debian 12, 6.1.174-1 ou plus récent. Sur un serveur AlmaLinux 9 que j'administre, le noyau 5.14.0-687.59.1.el9_8 contient bien le correctif.

3. Un redémarrage est-il en attente ?

# AlmaLinux, Rocky, Red Hat
dnf needs-restarting -r

# Debian, Ubuntu
ls /var/run/reboot-required

Si un noyau plus récent est installé mais pas encore chargé, le serveur tourne toujours sur l'ancien.

4. MPTCP est-il actif ?

sysctl net.mptcp.enabled
ss -Mln

La seconde commande liste les services qui écoutent en MPTCP. Si elle ne renvoie rien, vous n'êtes pas dans le cas démontré par Anthropic. Cela ne dispense pas de mettre à jour : les avis officiels ne disent pas que les autres serveurs sont à l'abri.

5. Le module ksmbd est-il chargé ?

lsmod | grep ksmbd

Aucune ligne : non concerné par les failles KSMBD.

Que faire ?

  1. Mettre à jour PHP, puis redémarrer PHP-FPM ou Apache. Toute la méthode est dans mon guide PHP2Shell, je ne la répète pas ici.
  2. Mettre à jour le noyau (dnf upgrade kernel* ou apt upgrade), puis redémarrer le serveur. C'est l'étape la plus souvent oubliée : un serveur qui n'a pas redémarré depuis mai tourne peut-être encore sur un noyau vulnérable à Fragnesia, même si le correctif est installé sur le disque.
  3. Chercher des fichiers PHP suspects dans les dossiers d'envoi, où il ne devrait y en avoir aucun :
find /chemin/du/site/wp-content/uploads -name '*.php'

Si vous trouvez quelque chose, ne vous contentez pas de le supprimer : suivez la section « Ai-je été compromis ? » du guide.

  1. En hébergement mutualisé, écrivez au support : « Avez-vous appliqué les correctifs PHP du 21 octobre 2026 et le correctif du noyau pour CVE-2026-46300, et le serveur a-t-il été redémarré depuis ? »
  2. Pour CVE-2026-98432, installez le noyau corrigé dès que votre distribution le publie, puis redémarrez.

Ce que nous ne savons pas encore

Je mettrai cet article à jour quand ces points seront clarifiés.

Vous gérez un VPS et vous préférez qu'un professionnel s'en charge ? Je propose la maintenance et la surveillance de serveurs. Pour une question précise, contactez-moi.

Sources

← Toutes les actualités