Faille PHP2Shell : ce que doivent faire les sites marocains

Le 21 octobre 2026, le projet PHP a corrigé deux failles critiques, surnommées PHP2Shell, qui permettent à un attaquant d’exécuter du code sur un serveur web sans le moindre identifiant. Si votre site tourne sur PHP, comme la très grande majorité des sites WordPress, WooCommerce ou PrestaShop au Maroc, vous devez vérifier aujourd’hui que votre serveur utilise une version corrigée.

Ce guide explique ce que sont ces failles, comment vérifier votre site en cinq minutes, que faire selon votre type d’hébergement, et ce que la loi marocaine impose aux entreprises et aux administrations. Tout ce qui suit s’appuie sur les annonces officielles du projet PHP, de la DGSSI et des textes de loi marocains.

Ce qu’il faut faire, en une minute

Si vous ne lisez que cette partie, retenez trois gestes.

1. Vérifiez la version de PHP de votre site et, chez un hébergeur mutualisé, la date à laquelle elle a été compilée.
2. Faites passer votre site sur une version corrigée : 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou une version équivalente fournie par votre hébergeur et datée du 21 octobre 2026 ou plus tard.
3. Surveillez les traces d’une éventuelle intrusion : nouveaux comptes administrateurs, fichiers modifiés, pages inconnues.

Le projet PHP est catégorique dans ses notes de version : il n’existe aucune protection complète en dehors de la mise à jour. Les réglages de contournement ne servent qu’à gagner quelques heures.

PHP2Shell : de quoi parle-t-on exactement ?

PHP2Shell désigne deux failles distinctes du moteur PHP, référencées CVE-2026-109618 et CVE-2026-109619. Le projet PHP les décrit uniquement par ces numéros ; le surnom vient des bulletins de sécurité, notamment ceux de la DGSSI au Maroc.

La première faille est liée à la gestion des erreurs de mémoire. Selon l’annonce officielle du projet PHP, une erreur de mémoire insuffisante peut interrompre PHP alors que certaines données internes d’une requête ne sont que partiellement initialisées. La seconde concerne des données internes qui survivent après la libération de la mémoire qui les contenait. Dans les deux cas, un attaquant peut détourner ce comportement pour exécuter son propre code.

Les deux failles sont notées 9,2 sur 10 selon la méthode d’évaluation CVSS dans sa version 4.0, ce qui les place dans la catégorie critique. Le point le plus inquiétant tient en deux mots : sans authentification. L’attaquant n’a besoin d’aucun mot de passe, d’aucun compte, d’aucun accès préalable. Il lui suffit d’envoyer des requêtes à un serveur vulnérable.

Le projet PHP précise que toutes les installations qui servent des pages web sont concernées, quelle que soit la façon dont PHP est exécuté : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. LiteSpeed est justement la technologie de nombreux hébergeurs mutualisés utilisés par les entreprises marocaines.

Votre site est-il concerné ?

Votre site est concerné s’il utilise PHP et que son serveur n’a pas encore reçu le correctif. Concrètement, cela inclut :

• Les sites WordPress, qu’ils soient vitrines, blogs ou boutiques WooCommerce.
• Les boutiques PrestaShop et les sites Joomla ou Drupal.
• Les applications sur-mesure en PHP, notamment celles construites avec Laravel ou Symfony.
• Les formulaires et scripts PHP ajoutés à un site par ailleurs statique, comme un formulaire de contact ou un outil en ligne.

La faille ne vient pas de WordPress. L’équipe francophone de WordPress l’a rappelé dans sa communication sur cette mise à jour de sécurité : aucune mise à jour de WordPress n’est requise, c’est PHP qu’il faut corriger. Mettre à jour vos extensions et votre thème reste une bonne pratique, mais ne protège pas contre PHP2Shell.

Les sites hébergés sur des plateformes fermées, comme Shopify, ne dépendent pas de votre propre installation de PHP : c’est la plateforme qui gère sa sécurité. En revanche, une boutique YouCan ou Shopify reliée à un site annexe en PHP, par exemple un blog WordPress, doit faire vérifier ce site annexe.

Comment connaître la version de PHP de votre site

Trois méthodes, de la plus simple à la plus technique.

Dans WordPress. Ouvrez votre administration, puis Outils, Santé du site, onglet Informations, rubrique Serveur. La version de PHP y est affichée. C’est la méthode indiquée par l’équipe de WordPress elle-même.

Dans le panneau de votre hébergeur. La plupart des hébergeurs affichent la version de PHP de chaque site dans une rubrique dédiée, souvent nommée « Configuration PHP » ou « Version de PHP ». C’est aussi là que vous pouvez en changer.

En demandant à votre hébergeur. C’est la méthode la plus fiable, surtout en hébergement mutualisé. Posez une question précise par écrit : « Le correctif des failles CVE-2026-109618 et CVE-2026-109619 est-il installé sur le serveur qui héberge mon site ? » Une réponse vague doit vous alerter.

Un conseil de prudence : si un prestataire vous propose de créer une page qui affiche toutes les informations techniques de PHP, demandez-lui de la supprimer aussitôt la vérification faite. Une telle page laissée en ligne renseigne précisément les attaquants sur votre serveur.

Les versions corrigées, branche par branche

Le projet PHP maintient plusieurs branches en parallèle. Chacune a reçu sa propre version corrigée, sauf les branches qui ne sont plus maintenues.

Branche	Version corrigée	Statut de la branche
PHP 8.5	8.5.12	Maintenue
PHP 8.4	8.4.27	Maintenue
PHP 8.3	8.3.36	Correctifs de sécurité jusqu’au 31 décembre 2027
PHP 8.2	8.2.35	Correctifs de sécurité jusqu’au 31 décembre 2026
PHP 8.1	Aucune version officielle	Fin de vie depuis le 31 décembre 2025
PHP 8.0 et 7.x	Aucune version officielle	Fin de vie depuis 2022 et 2023

Deux remarques importantes. D’abord, PHP 8.2 arrive en fin de maintenance le 31 décembre 2026 : si votre site est sur cette branche, la correction de PHP2Shell est le bon moment pour préparer le passage à une version plus récente. Ensuite, WordPress recommande désormais PHP 8.3 ou plus, ce qui donne une cible claire pour les sites WordPress.

Pour les branches en fin de vie, le projet PHP a publié des correctifs minimaux destinés aux distributions Linux et aux spécialistes qui maintiennent ces versions. Un site professionnel ne devrait pas en dépendre : la seule voie durable est de migrer.

Hébergement mutualisé : vérifier la date de compilation

C’est le cas de la plupart des sites vitrines et des petites boutiques au Maroc. Sur un hébergement mutualisé, vous ne gérez pas PHP vous-même : c’est l’hébergeur qui installe les correctifs sur ses serveurs.

Il existe ici un piège fréquent. Certains hébergeurs intègrent le correctif dans leurs propres versions de PHP sans changer le numéro affiché. Votre tableau de bord peut donc indiquer une version qui semble ancienne alors que le serveur est déjà protégé, ou l’inverse.

Hostinger, par exemple, l’explique dans sa communication officielle sur PHP2Shell : selon l’hébergeur, le correctif a été installé sur tous ses serveurs d’hébergement web, cloud et cPanel, mais pas sur les VPS, que leurs propriétaires gèrent eux-mêmes. Sa page d’état précise que le critère à vérifier est une date de compilation de PHP au 21 octobre 2026 ou plus tard, même si le numéro de version reste inchangé.

Pour un autre hébergeur, la règle est la même : ne vous contentez pas du numéro de version, et demandez une confirmation écrite qui cite les deux références de la faille. Si votre hébergeur ne sait pas vous répondre clairement, c’est une information en soi sur la qualité du service que vous payez.

Sur un VPS ou un serveur dédié : mettre à jour vous-même

Sur un VPS, un serveur dédié ou un serveur géré par votre équipe informatique, personne ne fera la mise à jour à votre place. C’est le cas fréquent des applications sur-mesure, des plateformes à fort trafic et des systèmes d’information des administrations.

La marche à suivre est classique, mais chaque étape compte :

1. Sauvegardez les fichiers et la base de données, et vérifiez que la sauvegarde se restaure.
2. Installez la version corrigée de votre branche, via les paquets de votre distribution ou les dépôts que vous utilisez.
3. Redémarrez tous les processus PHP, y compris les processus PHP-FPM ou LiteSpeed. Un correctif installé mais non chargé ne protège rien.
4. Vérifiez la version réellement utilisée par le site, pas seulement celle de la ligne de commande : les deux peuvent différer.
5. Testez les fonctions critiques du site : connexion, formulaires, paiement, envois d’e-mails.

La DGSSI a d’ailleurs publié un bulletin spécifique sur les risques de mauvaise application de ce correctif, en insistant sur le redémarrage des processus et sur le caractère temporaire des contournements.

Si vous ne pouvez pas mettre à jour aujourd’hui

Il arrive qu’une mise à jour immédiate soit impossible : application ancienne, prestataire injoignable, serveur partagé avec d’autres services. Dans ce cas, des mesures temporaires existent, avec des limites qu’il faut connaître.

Le projet PHP indique que désactiver le réglage session.upload_progress.enabled dans la configuration principale de PHP, puis redémarrer tous les processus, bloque les chemins d’attaque confirmés de la seconde faille. Il précise que ce réglage ne doit pas être appliqué depuis le code de l’application ni par un fichier de configuration local, et qu’il ne bloque pas toutes les variantes. Pour la première faille, les mesures proposées réduisent le risque sans le supprimer.

Les agences de cybersécurité vont plus loin. L’agence américaine CISA et le centre britannique NCSC recommandent d’envisager la mise hors ligne des systèmes qui ne peuvent pas être corrigés. Pour un site vitrine, une page de maintenance temporaire vaut mieux qu’un serveur compromis. Pour une boutique ou un service public, cette décision se prend avec la direction, en mesurant le risque.

Si vous êtes dans cette situation et que votre site est en production, ne restez pas seul avec le problème : c’est exactement le genre de situation où une intervention de dépannage WordPress rapide évite des jours de nettoyage plus tard.

Comment savoir si votre site a déjà été visé

La faille a été rendue publique le 21 octobre 2026, mais les attaques peuvent avoir commencé avant. Le service de renseignement sur les menaces d’Amazon a indiqué avoir observé une tentative d’exploitation datant du 17 octobre, sans pouvoir dire si elle avait réussi, et la DGSSI signale qu’un code d’exploitation de démonstration est disponible.

Après la mise à jour, prenez donc le temps de vérifier quelques signes :

• Des comptes administrateurs que vous ne connaissez pas dans WordPress ou dans votre application.
• Des fichiers PHP récents dans des dossiers qui n’en contiennent normalement pas, comme le dossier des médias téléversés.
• Des pages ou des redirections inconnues, souvent visibles dans Google en tapant le nom de votre domaine précédé de « site: ».
• Une hausse inhabituelle de l’utilisation du processeur ou des envois d’e-mails signalée par votre hébergeur.
• Des alertes de sécurité dans la Search Console de Google.

Si l’un de ces signes apparaît, mettre PHP à jour ne suffit plus : une porte dérobée installée avant le correctif reste ouverte après. La procédure complète de nettoyage est détaillée dans mon guide sur le site WordPress piraté.

Gardez enfin une trace écrite de vos vérifications : la date, la version de PHP constatée, la réponse de l’hébergeur et ce que vous avez contrôlé. En cas d’incident découvert plus tard, ce document montre que vous avez agi dès l’annonce de la faille, ce qui compte face à un client, à un assureur ou à une autorité.

Administrations et établissements publics : ce que prévoit la loi 05-20

Pour les institutions marocaines, PHP2Shell n’est pas seulement un sujet technique : c’est aussi une question d’obligations légales.

La loi n° 05-20 relative à la cybersécurité, promulguée par le dahir n° 1-20-69 du 25 juillet 2020, s’applique notamment aux administrations de l’État, aux collectivités territoriales, aux établissements et entreprises publics, aux infrastructures d’importance vitale, ainsi qu’à certains opérateurs comme les fournisseurs d’accès et de services numériques. Son texte officiel publié par la DGSSI prévoit à l’article 8 que chaque entité doit, dès qu’elle prend connaissance d’un incident, le déclarer à l’autorité nationale. Le décret d’application n° 2-21-406 désigne cette autorité : la Direction générale de la sécurité des systèmes d’information. L’article 50 punit le manquement à ces obligations de déclaration d’une amende de 100 000 à 200 000 dirhams.

Dans la pratique, ces déclarations passent par le maCERT, le centre de veille et de réponse aux incidents de la DGSSI, qui publie aussi des alertes. Sur PHP2Shell, il a diffusé plusieurs bulletins successifs, dont le bulletin de sécurité sur les vulnérabilités critiques affectant PHP, classé critique, suivi d’un bulletin sur les risques de mauvaise application du correctif et d’un complément demandant d’étendre les vérifications à tout l’écosystème numérique, partenaires et interfaces de programmation compris.

Ce dernier point est souvent oublié. Une administration peut avoir corrigé son portail principal, tout en laissant tourner un sous-domaine de prise de rendez-vous, un ancien site d’événement ou un formulaire développé par un prestataire. Ce sont précisément ces services oubliés qui ouvrent la porte.

Ce que l’affaire de la CNSS a rappelé

En avril 2025, le Maroc a vécu l’une des fuites de données les plus médiatisées de son histoire récente. Le 8 avril, un groupe de pirates se présentant sous le nom de Jabaroot DZ a revendiqué une attaque contre la Caisse nationale de sécurité sociale et diffusé des documents présentés comme des données de salariés et d’entreprises affiliés. Le groupe a avancé des chiffres de l’ordre de deux millions de salariés et de près de 500 000 entreprises, chiffres que la CNSS n’a pas confirmés.

Dans son communiqué relayé par l’agence MAP, la CNSS a évoqué une série d’attaques visant à contourner ses dispositifs de sécurité, indiqué que ses premières vérifications révélaient le caractère souvent faux, inexact ou tronqué des documents diffusés, et annoncé la saisine des autorités judiciaires. La CNDP a de son côté rappelé que toute utilisation de données obtenues en dehors du cadre légal est illicite. Le ministère de l’Emploi, également visé, a démenti toute compromission de données sensibles.

Il faut être précis sur un point : aucune cause technique officielle n’a été publiée, et rien ne relie cette affaire à PHP. Si je la cite ici, c’est pour une autre raison. Elle a montré concrètement ce que coûte une faille pour une institution marocaine : des données personnelles de citoyens exposées, une confiance entamée, une crise de communication, une enquête judiciaire. Une faille critique non corrigée sur un serveur public peut produire exactement ce scénario.

Entreprises privées : la loi 09-08 et la sécurité des données

Une entreprise privée qui n’entre pas dans le champ de la loi 05-20 n’en est pas quitte pour autant. Dès qu’elle traite des données personnelles, ce qui est le cas de tout site avec un formulaire de contact, un compte client ou une boutique, elle relève de la loi n° 09-08 relative à la protection des données personnelles.

L’article 23 de cette loi impose au responsable du traitement de mettre en œuvre les mesures techniques et organisationnelles appropriées pour protéger les données contre la destruction, la perte, l’altération, la diffusion ou l’accès non autorisés. L’article 58 sanctionne le manquement à ces obligations de sécurité d’un emprisonnement de trois mois à un an et d’une amende de 20 000 à 200 000 dirhams, ou de l’une de ces deux peines.

Laisser tourner un serveur avec une faille critique connue, corrigée et largement annoncée, alors qu’une mise à jour existe, est difficile à défendre comme une mesure de sécurité appropriée. Le texte de la loi 09-08 ne contient pas d’obligation explicite de notifier une fuite à la CNDP, mais l’obligation de sécurité, elle, est claire.

Si votre site recueille des données, c’est le moment de vérifier aussi vos mentions légales et votre politique de confidentialité, sujet détaillé dans mon article sur les obligations légales d’un site marocain.

Mettre à jour PHP sans casser votre site

C’est la crainte légitime de beaucoup de propriétaires de sites : changer de version de PHP peut faire apparaître des erreurs, surtout sur un site ancien.

Le risque dépend surtout de l’écart entre l’ancienne et la nouvelle version. Passer de 8.2.34 à 8.2.35 ne change rien au fonctionnement du site : c’est une correction de sécurité dans la même branche. Passer de PHP 7.4 à PHP 8.3, en revanche, peut casser une extension ancienne, un thème abandonné ou du code sur-mesure écrit il y a des années.

La méthode prudente tient en quatre points :

1. Sauvegarde complète des fichiers et de la base de données avant toute modification.
2. Copie de test du site, quand l’hébergeur le permet, pour essayer la nouvelle version sans risque.
3. Mise à jour préalable de WordPress, du thème et des extensions, qui sont généralement compatibles avec les versions récentes de PHP.
4. Vérification des fonctions qui rapportent : formulaires, paiement, réservation, envois d’e-mails, espace client.

Si une erreur apparaît après le changement, la plupart des hébergeurs permettent de revenir à la version précédente en quelques clics. Ce retour en arrière doit rester exceptionnel et temporaire, le temps de corriger l’incompatibilité.

Après PHP2Shell : la routine qui protège de la prochaine faille

PHP2Shell ne sera pas la dernière faille critique. La vraie question est de savoir si vous l’apprendrez à temps la prochaine fois.

Pour un site d’entreprise, trois habitudes suffisent. Tenir une liste à jour de tous vos sites et sous-domaines, avec leur hébergeur et leur version de PHP. Suivre les bulletins de la DGSSI, qui publie des alertes en français sur les failles qui touchent le Maroc. Et confier la maintenance à quelqu’un d’identifié, avec un engagement écrit sur les délais d’intervention en cas de faille critique.

C’est précisément le rôle d’un contrat de maintenance, dont le contenu est détaillé dans mon article sur le contrat de maintenance d’un site WordPress. Le choix de l’hébergeur compte aussi : sa réactivité sur ce type d’incident en dit plus long que son prix, comme je l’explique dans le comparatif des hébergements au Maroc.

Pour une administration, la routine est plus exigeante : inventaire complet des services exposés sur Internet, procédure de mise à jour d’urgence, contact identifié avec le maCERT, et clauses de sécurité imposées à chaque prestataire qui développe ou héberge un service public.

Par où commencer

Faites trois choses aujourd’hui. Vérifiez la version et, chez un hébergeur mutualisé, la date de compilation de PHP sur chacun de vos sites. Demandez à votre hébergeur une confirmation écrite qui cite les failles CVE-2026-109618 et CVE-2026-109619. Puis contrôlez les comptes administrateurs et les fichiers récents de vos sites.

Si tout est en ordre, notez la date de cette vérification : c’est le début de votre routine de sécurité.

Et si vous n’êtes pas sûr de votre situation, ou si vous gérez plusieurs sites dont certains sont anciens, envoyez-moi leurs adresses : je vérifie leur exposition à PHP2Shell, je vous dis ce qui doit être corrigé en priorité, et je peux m’en charger dans le cadre d’une intervention de dépannage WordPress.