PHP2Shell : ce que l'alerte DGSSI change pour la gouvernance

Le 21 octobre 2026, la DGSSI a émis une alerte critique sur PHP2Shell, deux vulnérabilités de PHP notées 9,2 en CVSS v4.0 qui permettent d'exécuter du code à distance sans authentification [1][3]. Tout site ou application web en PHP est exposé, mais la loi 05-20 n'impose d'obligations qu'aux entités publiques, aux infrastructures d'importance vitale et à certains opérateurs [7]. Partout ailleurs, le conseil doit exiger un délai de correction mesuré et un responsable désigné, pas une simple confirmation que « c'est patché ».

Qu'est-ce que PHP2Shell et pourquoi la DGSSI l'a-t-elle classée critique ?

PHP2Shell désigne deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619. Une CVE est l'identifiant public unique attribué à une faille de sécurité. La première tient à la gestion des dépassements de mémoire, la seconde à un état interne qui survit à une requête et peut être réutilisé par la suivante [3]. Le projet PHP a publié les correctifs le 21 octobre : versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 [3].

Il note les deux failles 9,2 en CVSS v4.0 [3]. Le CVSS est l'échelle internationale de 0 à 10 qui mesure la gravité technique d'une faille. Trois éléments publiés par le projet expliquent ce niveau. L'attaquant n'a besoin d'aucun compte. Toutes les installations PHP qui servent des requêtes web sont concernées : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed [3]. PHP-FPM est le gestionnaire de processus qui exécute le code PHP derrière un serveur web. Enfin, aucune parade n'est complète : la mise à jour est la seule solution sûre [3]. Sur mod_php, une requête non authentifiée peut déclencher l'attaque avant l'exécution du moindre code applicatif [3]. L'authentification de l'application ne protège donc pas.

La menace s'est concrétisée en quelques jours. Le CERT-EU a signalé que des preuves de concept commençaient à circuler [4]. Une preuve de concept (PoC) est un code qui démontre qu'une faille est exploitable. Le 26 octobre, l'agence américaine CISA a inscrit les deux failles à son catalogue des vulnérabilités activement exploitées [5].

Que dit exactement la loi 05-20, et qui est concerné ?

La loi n° 05-20 relative à la cybersécurité a été promulguée par le dahir n° 1-20-69 du 25 juillet 2020 et publiée au Bulletin officiel n° 6906 du 6 août 2020 [7].

| Assujettis | Obligations principales | Articles | |---|---|---| | Entités : administrations de l'État, collectivités territoriales, établissements et entreprises publics, autres personnes morales de droit public | Conformité aux directives de l'autorité nationale ; audit ; déclaration des incidents | Art. 1, 3, 4, 8 | | Infrastructures d'importance vitale (IIV) désignées | Socle des entités ; liste des SI sensibles ; homologation avant mise en exploitation ; audit ; plan d'actions après audit ; prestataires qualifiés | Art. 14, 17, 19, 20, 24, 25 | | Opérateurs : télécoms, fournisseurs d'accès, prestataires de cybersécurité, fournisseurs de services numériques, éditeurs de plateformes | Obligations propres, dont informer leurs clients des vulnérabilités de leurs SI | Art. 26 à 31 | | Secteur privé non désigné | Recommandations et sensibilisation | Art. 37, 44 |

La loi définit les IIV comme les installations, ouvrages et systèmes indispensables au maintien des fonctions vitales de la société (art. 2). Elles sont désignées par secteur, après avis de l'autorité nationale, et leur liste reste secrète (art. 16) [7]. Seule une notification permet donc de savoir si une société est IIV.

La Directive nationale de la sécurité des systèmes d'information (DNSSI) complète ce dispositif. Entérinée en 2014, elle a été mise à jour par la circulaire du Chef du gouvernement n° 2/2023 du 12 janvier 2023, avec six mois pour s'y conformer [8][9]. Son champ couvre les administrations de l'État, les établissements et entreprises publics, les personnes morales de droit public, les collectivités territoriales et toutes les IIV, publiques ou privées [8].

Ce qui relève de la diligence pour un groupe privé

Un groupe privé qui n'est ni IIV ni opérateur n'est soumis ni à l'homologation, ni à la déclaration d'incident, ni à la DNSSI. La question ne disparaît pas pour autant. La DNSSI et les exigences faites aux IIV forment le référentiel public le plus précis pour apprécier ce qu'est une gestion raisonnable du risque cyber au Maroc. Après un incident, s'en être écarté se justifie plus difficilement que l'avoir suivi. Les fournisseurs d'IIV y sont souvent exposés par une autre voie : une IIV qui externalise sa cybersécurité doit recourir à des prestataires qualifiés (art. 25) [7] et peut reporter ses exigences sur ses partenaires par contrat.

Pourquoi le patch management est-il une question de conseil d'administration ?

Le mythe. Corriger une faille relèverait de l'exploitation : un ticket, une fenêtre de maintenance, un redémarrage.

La réalité. PHP2Shell montre où la décision quitte la salle serveur.

Il y a d'abord l'arbitrage entre disponibilité et exposition. Le 21 octobre, plusieurs administrations européennes ont mis des sites hors ligne à titre préventif, notamment en Allemagne, en France, en Belgique, aux Pays-Bas et en Finlande [6]. Couper un portail client ou un site marchand est une décision commerciale.

Vient ensuite le passif technique. Les versions 8.1 et antérieures ne reçoivent plus de mises à jour du projet PHP, hormis des correctifs minimaux en source [3]. Le support de sécurité de la branche 8.2 prend fin le 31 décembre 2026 [3]. Une application sur une version non maintenue ne se corrige pas, elle se migre. C'est une ligne budgétaire.

Reste l'imputabilité. Dans un groupe aux systèmes multiples (ERP, sites marchands, portails de filiales, applications de prestataires), « qui doit corriger ce serveur ? » n'a souvent pas de réponse immédiate. Tant que personne n'en répond, le délai ne se mesure pas.

Quelles questions le comité d'audit doit-il poser ?

« Sommes-nous patchés ? » appelle un oui rassurant et invérifiable. Le comité d'audit ou des risques gagne à demander :

1. Combien d'actifs exposés à Internet utilisaient PHP le 21 octobre, et selon quel inventaire ?
2. À quelle date le dernier a-t-il été corrigé ou isolé ?
3. Lesquels tournent sur une version non maintenue, et quel est le plan de migration chiffré ?
4. Qui est le responsable désigné de chaque système d'information, y compris chez les prestataires ?
5. Nos contrats d'hébergement et d'infogérance fixent-ils un délai de correction des failles critiques, et est-il tenu ?

Trois indicateurs suffisent pour suivre les réponses :

| Indicateur | Formule | |---|---| | Délai moyen de remédiation des vulnérabilités critiques (jours) | Σ (date de correction ou d'isolement − date de publication du correctif) ÷ nombre de vulnérabilités critiques traitées sur la période | | Part des actifs en version non maintenue (%) | Actifs exposés sur une version hors support ÷ total des actifs exposés × 100 | | Couverture des responsables (%) | SI critiques avec un responsable désigné ÷ total des SI critiques × 100 |

Que change la Stratégie nationale de cybersécurité 2030 ?

La DGSSI a dévoilé la Stratégie nationale de cybersécurité 2030 le 22 juillet 2024 [10]. Elle repose sur quatre piliers : gouvernance, sécurité et résilience, capacités et sensibilisation, coopération [11]. Les entreprises privées figurent parmi les acteurs à mobiliser [11].

Cette stratégie restera déclarative dans le privé tant que la cybersécurité s'y pilotera par les moyens plutôt que par les délais. Les conseils suivent déjà le risque fiscal ou contentieux avec des indicateurs et des responsables nommés. Le délai de remédiation d'une faille critique mérite le même traitement. PHP2Shell offre un cas d'école : une date de correctif connue, une exploitation avérée, aucune parade complète. Un conseil incapable de dire en combien de jours son groupe a traité cette alerte ne pilote pas ce risque.

> À retenir > > - PHP2Shell regroupe CVE-2026-109618 et CVE-2026-109619, deux failles de PHP notées 9,2 en CVSS v4.0 et corrigées le 21 octobre 2026 dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 [3]. > - La DGSSI a émis une alerte critique le 21 octobre 2026 ; la CISA a classé les deux failles comme activement exploitées le 26 octobre 2026 [1][5]. > - La loi 05-20 réserve l'homologation des systèmes d'information sensibles aux infrastructures d'importance vitale (art. 19) [7]. > - Pour un groupe privé ni IIV ni opérateur, la loi 05-20 et la DNSSI constituent un référentiel de diligence, sans obligation directe [7][8].

FAQ

PHP2Shell concerne-t-il un site WordPress ? Oui, si le serveur fait tourner une version de PHP antérieure aux correctifs du 21 octobre 2026. Le projet PHP considère comme exposée toute installation PHP qui sert des requêtes web, quel que soit le CMS [3]. C'est la version de PHP du serveur qu'il faut vérifier, pas celle de WordPress.

Une entreprise privée doit-elle déclarer un incident PHP2Shell à la DGSSI ? Pas au titre de la loi 05-20 si elle n'est ni IIV ni opérateur. L'obligation de déclaration de l'article 8 vise les entités publiques et, par renvoi de l'article 14, les IIV [7]. D'autres textes peuvent toutefois s'appliquer selon la nature des données touchées.

Comment savoir si une société est une infrastructure d'importance vitale ? Par notification. Les IIV sont désignées par secteur, après avis de l'autorité nationale, et leur liste est tenue secrète (art. 16 de la loi 05-20) [7]. Une société ne peut donc pas présumer son statut, ni dans un sens ni dans l'autre.

Une version PHP 8.1 peut-elle encore être corrigée ? Le projet PHP ne publie plus de mises à jour pour les versions 8.1 et antérieures, seulement des correctifs minimaux en source [3]. La solution durable est la migration vers une branche maintenue. La branche 8.2 sort elle-même du support de sécurité le 31 décembre 2026 [3].

Sources

1. « Cybersécurité : la DGSSI émet une alerte critique sur deux failles majeures affectant PHP au Maroc et à l'international », Hespress FR, 22 octobre 2026. https://fr.hespress.com/493526-cybersecurite-la-dgssi-emet-une-alerte-critique-sur-deux-failles-majeures-affectant-php-au-maroc-et-a-linternational.html
2. « Morocco's DGSSI Warns of Critical 'PHP2Shell' Vulnerabilities », Morocco World News, 22 octobre 2026. https://www.moroccoworldnews.com/2026/10/343335/moroccos-dgssi-warns-of-critical-php2shell-vulnerabilities/
3. PHP Group, avis de sécurité et annonces de versions des 20, 21 et 23 octobre 2026, php.net. https://www.php.net/archive/2026.php
4. CERT-EU, Security Advisory 2026-018 – Critical Vulnerabilities in PHP, 20 octobre 2026, mis à jour le 23 octobre 2026. https://cert.europa.eu/publications/security-advisories/2026-018
5. CISA, « CISA Adds Two Known Exploited Vulnerabilities to Catalog », 26 octobre 2026. https://content.govdelivery.com/accounts/USDHSCISA/bulletins/4309083
6. Reuters, « Factbox – Websites taken offline over PHP risks », repris par The Star, 21 octobre 2026. https://www.thestar.com.my/tech/tech-news/2026/10/21/factbox-websites-taken-offline-over-php-risks
7. Loi n° 05-20 relative à la cybersécurité, dahir n° 1-20-69 du 25 juillet 2020, BO n° 6906 du 6 août 2020, texte publié par Adala (ministère de la Justice). https://adala.justice.gov.ma/api/uploads/2024/03/20/La%20cybers%C3%A9curit%C3%A9-1710937403606.pdf
8. DGSSI, Directive nationale de la sécurité des systèmes d'information, version 2023. https://www.dgssi.gov.ma/sites/default/files/publications/pdf/2023-02/directive_nationale_de_la_securite_si_vf_12012023-3.pdf
9. CGEM, « Update of the National Directive on Information Systems Security », 27 février 2023. https://cgem.ma/en/activites/update-of-the-national-directive-on-information-systems-security/
10. Présentation de la Stratégie nationale de cybersécurité 2030 par la DGSSI, EcoActu, 24 juillet 2024. https://ecoactu.ma/dgssi-strategie-cybersecurite-2030-maroc/
11. « Cybersécurité 2030 : comment le Maroc veut renforcer son bouclier numérique », TelQuel, 23 octobre 2024. https://telquel.ma/instant-t/2024/10/23/cybersecurite-2030-comment-le-maroc-veut-renforcer-son-bouclier-numerique_1900255/