En bref
- PHP2Shell désigne deux failles critiques de l'interpréteur PHP (CVE-2026-109618 et CVE-2026-109619, score CVSS 4.0 de 9,2), corrigées le 21 octobre 2026 dans les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Elles permettent l'exécution de code à distance sans authentification.
- Toute application web en PHP est concernée, y compris des outils que l'on ne range pas dans cette catégorie : l'interface web de Zabbix, GLPI, de nombreux pare-feu et consoles d'administration.
- Des tentatives d'exploitation à grande échelle sont signalées par l'agence de cybersécurité de Singapour, et des preuves de concept circulent.
- Les 72 premières heures décident de l'issue : savoir où se trouve PHP (0 à 24 h), corriger et prouver la correction (24 à 48 h), chercher les traces et rendre compte (48 à 72 h).
- Au Maroc, les administrations, les établissements publics et les infrastructures d'importance vitale doivent déclarer tout incident à la DGSSI dès qu'ils en ont connaissance (loi 05-20, articles 8 et 14).
Le 21 octobre 2026, le projet PHP a publié en urgence le correctif de deux failles qui touchent le langage lui-même, et non une application particulière. Pour une direction générale, la question n'est pas de comprendre la corruption mémoire. Elle est de savoir, d'ici trois jours, si l'organisation sait où PHP tourne chez elle, qui décide de couper un service exposé, et comment elle prouvera que le risque est traité.
Qu'est-ce que PHP2Shell, et qui est concerné ?
PHP2Shell regroupe deux vulnérabilités de l'interpréteur PHP. La première exploite une mauvaise gestion de l'épuisement de la mémoire pendant le traitement d'une requête. La seconde exploite un état interne qui survit d'une requête à l'autre et pointe vers de la mémoire déjà libérée. Dans les deux cas, un attaquant non authentifié peut, sous certaines conditions, exécuter son propre code sur le serveur.
Le PHP Group, qui gère les identifiants de ces failles, leur attribue un score CVSS 4.0 de 9,2 sur 10. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les versions 8.1 et antérieures ne sont plus maintenues : le projet a publié des correctifs minimaux pour 7.4, 8.0 et 8.1, mais la voie normale est un correctif rétroporté par l'éditeur de la distribution, ou une migration.
Tous les modes d'exécution qui servent des pages web sont concernés : Apache avec mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. D'après l'analyse de Rapid7, mod_php est le plus exposé, car l'attaque peut aboutir avant même l'exécution du code de l'application.
Le calendrier a pris tout le monde de vitesse. Des détails ont fuité le 20 octobre, avant la publication coordonnée. Le 22 octobre, l'agence de cybersécurité de Singapour (CSA) fait état de tentatives d'exploitation généralisées et de plusieurs preuves de concept publiques. Le SANS Internet Storm Center a relevé son niveau d'alerte au jaune.
Pourquoi les outils de supervision et de service sont en première ligne
Lorsqu'une alerte PHP tombe, le réflexe est de penser au site institutionnel ou au portail client. Les outils qui font tourner le système d'information passent sous le radar, parce que personne ne les considère comme des « applications web ».
C'est pourtant le cas de beaucoup d'entre eux. Le moteur de Zabbix est écrit en C, mais son interface web est en PHP. GLPI est une application PHP. Il en va de même pour de nombreuses consoles de pare-feu, d'outils de sauvegarde ou de gestion de parc. Dans les déploiements en conteneurs, le problème est plus discret encore : la version de PHP dépend de l'image de base, et une mise à jour de l'image ne garantit pas que le PHP corrigé soit présent.
Ces outils posent un risque particulier pour trois raisons.
- Ils voient tout. Une console de supervision connaît l'inventaire complet du système d'information, ses adresses et ses dépendances. C'est la carte que cherche un attaquant.
- Ils détiennent des secrets. Identifiants de base de données, comptes de collecte, macros secrètes, accès aux équipements : une console d'exploitation concentre des droits que peu de serveurs possèdent.
- Ils agissent. Selon leur configuration, ces outils peuvent lancer des scripts sur les équipements supervisés ou créer des tickets qui déclenchent des changements. Compromettre la console, c'est potentiellement agir partout où elle a la main.
À cela s'ajoute une habitude répandue : des interfaces d'administration accessibles depuis Internet pour le confort des astreintes, protégées par un compte générique partagé entre plusieurs personnes. Le SANS Internet Storm Center rappelle à propos de PHP2Shell qu'une interface d'administration web ne doit pas être exposée sur Internet. Ce conseil vaut au-delà de cette crise.
Les 72 premières heures : une méthode en trois temps
De 0 à 24 h : savoir où est PHP et décider de l'isolement
La première journée ne sert pas à corriger, mais à savoir. L'objectif est une liste fiable de toutes les instances PHP, classées selon deux critères : l'exposition (accessible depuis Internet, depuis le réseau interne, ou isolée) et la criticité (ce que l'outil contrôle ou détient).
- Interroger chaque serveur et chaque conteneur sur la version de PHP réellement installée, sans se limiter aux applications connues comme « en PHP ».
- Inclure les outils de supervision, de gestion des services, de sauvegarde, les consoles d'équipements réseau et les applications fournies par des prestataires.
- Pour chaque instance exposée sur Internet et non corrigeable dans la journée, décider de l'isolement : retrait d'Internet, accès réservé au VPN, ou authentification en amont du serveur PHP, au niveau du reverse proxy. La page de connexion de l'application ne protège pas, puisque l'attaque vise l'interpréteur avant l'application.
La décision difficile est celle de couper un outil de production. Retirer de l'accès distant la console de supervision, c'est accepter une astreinte moins confortable pendant quelques jours. Ne pas le faire, c'est laisser la carte du système d'information à portée d'un attaquant. Cet arbitrage revient à la direction, pas à l'administrateur de garde.
De 24 à 48 h : corriger et prouver la correction
La correction elle-même est simple : installer le paquet corrigé de la distribution ou la version corrigée de PHP. La difficulté est de prouver qu'elle est effective.
- Le bon paquet. Pour un paquet de distribution, le numéro de version de base ne suffit pas : il faut comparer la révision exacte à l'avis de sécurité de l'éditeur, car les correctifs sont souvent rétroportés.
- Le bon processus. Un PHP mis à jour sur le disque ne protège rien tant que les processus qui servent les pages n'ont pas été redémarrés. La commande
php -ven ligne de commande ne dit rien du runtime qui sert réellement le site. - La bonne image. Pour les conteneurs, il faut reconstruire l'image et vérifier ensuite la version de PHP à l'intérieur du conteneur en service.
En attendant la correction, des mesures partielles réduisent l'exposition : désactiver session.upload_progress.enabled, limiter la taille des requêtes, filtrer avec un pare-feu applicatif. Elles ne remplacent pas le correctif, et un filtrage chez un fournisseur ne protège que si le serveur n'accepte pas de trafic qui le contourne.
De 48 à 72 h : chercher les traces et rendre compte
Un correctif n'efface pas une intrusion qui aurait eu lieu avant son installation. Des tentatives d'exploitation ont été signalées avant la divulgation publique : pour les instances exposées, il faut partir de l'hypothèse qu'elles ont pu être visées.
- Conserver les journaux du serveur web et de PHP depuis le 20 octobre au moins, avant qu'une rotation ne les efface.
- Rechercher les signes inhabituels : requêtes multipart anormales, redémarrages répétés des processus PHP, fichiers récents dans les répertoires web, comptes créés dans les outils d'administration.
- Changer les identifiants stockés dans les outils exposés : comptes de base de données, comptes de collecte, macros secrètes, comptes d'administration. Remplacer au passage les comptes génériques par des comptes nominatifs.
- Documenter ce qui a été fait, quand et par qui. Cette trace sert à l'audit, à l'assureur et, le cas échéant, à l'autorité.
Ce que la loi 05-20 impose aux organisations marocaines
La loi 05-20 relative à la cybersécurité oblige les entités publiques (administrations de l'État, collectivités territoriales, établissements et entreprises publics) à déclarer à l'autorité nationale tout incident affectant la sécurité ou le fonctionnement de leurs systèmes d'information, dès qu'elles en ont connaissance (article 8). L'article 14 étend cette obligation aux infrastructures d'importance vitale. L'article 50 prévoit une amende de 100 000 à 200 000 dirhams en cas de manquement.
La DGSSI a rappelé en janvier 2026 que la déclaration doit être immédiate et systématique, après avoir constaté des retards. Une vulnérabilité non exploitée n'est pas un incident. Une compromission découverte pendant la recherche de traces en est un. La règle de déclaration doit donc être décidée avant le début de la recherche, pas au moment où l'on trouve quelque chose.
Pour les organisations privées hors de ce périmètre, l'obligation légale ne s'applique pas de la même façon, mais les exigences des régulateurs sectoriels, des assureurs et des clients conduisent au même besoin : pouvoir démontrer, dates à l'appui, que l'alerte a été traitée.
Les décisions qui reviennent au comité de direction
| Décision | Responsable | Échéance |
|---|---|---|
| Déclencher la cellule de crise et désigner un pilote unique | Direction générale | Heure 0 |
| Valider l'isolement des outils exposés non corrigés, en acceptant l'impact sur l'exploitation | DG et DSI | 24 h |
| Exiger des prestataires et hébergeurs une confirmation écrite de leur correction | DSI, achats | 24 h |
| Fixer la règle de déclaration à la DGSSI ou au régulateur en cas de compromission | DG, RSSI, juridique | 24 h |
| Recevoir la preuve de correction instance par instance | RSSI | 48 h |
| Arbitrer la rotation des secrets et ses impacts | DSI, RSSI | 72 h |
| Lancer la revue de fond : inventaire des dépendances, exposition des consoles, comptes partagés | Comité de direction | 30 jours |
Ce que cette crise révèle : la dette des dépendances
PHP2Shell rappelle que la sécurité d'un outil dépend de composants que personne, dans l'organisation, n'a explicitement sous sa responsabilité. L'équipe supervision gère Zabbix, l'équipe support gère GLPI, l'équipe système gère les serveurs : la version de PHP dans l'image du conteneur, elle, n'appartient à personne.
La réponse durable n'est pas une meilleure réaction à la prochaine alerte, mais trois décisions de gouvernance : tenir un inventaire des composants logiciels de chaque outil d'exploitation, ne plus exposer de console d'administration sur Internet sans couche d'authentification en amont, et attribuer un responsable à chaque dépendance critique. Ces décisions coûtent peu au regard de ce qu'une console de supervision compromise permettrait à un attaquant.
Questions fréquentes
Zabbix est-il vulnérable à PHP2Shell ?
Le moteur de Zabbix, écrit en C, n'est pas concerné. Son interface web, écrite en PHP, l'est si elle tourne sur une version de PHP non corrigée. Il faut donc vérifier la version de PHP qui sert réellement l'interface et la mettre à jour, puis redémarrer les processus PHP.
Quelles versions de PHP corrigent PHP2Shell ?
PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, publiées le 21 octobre 2026. Pour les paquets de distribution, il faut comparer la révision exacte du paquet avec l'avis de sécurité de l'éditeur, car les correctifs sont souvent rétroportés sans changer le numéro de version de base.
Mettre à jour PHP suffit-il ?
Non. Il faut redémarrer les processus qui servent les pages, vérifier le runtime réellement actif, puis chercher d'éventuelles traces d'intrusion antérieures au correctif. Une mise à jour ne supprime pas un accès qu'un attaquant aurait déjà obtenu.
Que faire si la mise à jour est impossible tout de suite ?
Retirer l'application d'Internet ou la placer derrière un VPN, ou ajouter une authentification au niveau du reverse proxy. Désactiver session.upload_progress.enabled et limiter la taille des requêtes réduit l'exposition, sans rendre l'installation sûre.
Faut-il déclarer PHP2Shell à la DGSSI ?
La seule présence de la vulnérabilité n'est pas un incident. En revanche, une entité publique ou une infrastructure d'importance vitale qui découvre une compromission doit la déclarer à la DGSSI dès qu'elle en a connaissance, en application des articles 8 et 14 de la loi 05-20.
Transparence
Alton conseille, déploie et exploite des outils de supervision et de gestion des services, dont Zabbix et GLPI. Cet article ne recommande aucun outil : la méthode s'applique à toute application qui repose sur PHP. Pour approfondir la gouvernance de vos outils d'exploitation, voir notre approche pilotage et gouvernance et nos travaux sur la résilience des processus métiers et des applications.
Sources
- PHP Group, fiche CVE-2026-109618, publiée le 21 octobre 2026.
- PHP Group, fiche CVE-2026-109619, publiée le 21 octobre 2026.
- CERT-EU, Security Advisory 2026-018, 21 octobre 2026.
- Cyber Security Agency of Singapore, Critical Vulnerabilities in PHP (PHP2Shell), mise à jour du 22 octobre 2026.
- SANS Internet Storm Center, Critical PHP Vulnerability, infocon yellow, 21 octobre 2026.
- Rapid7, CVE-2026-109618 and CVE-2026-109619, 21 octobre 2026.
- Loi n° 05-20 relative à la cybersécurité, texte publié sur adala.justice.gov.ma, articles 8, 14 et 50.
- TelQuel, la DGSSI exige une déclaration immédiate des incidents, 21 janvier 2026.
