Faille PHP « PHP2Shell » CVE-2026-109618 et CVE-2026-109619 : versions à installer et vérifications

La réponse courte : deux failles du moteur PHP, CVE-2026-109618 et CVE-2026-109619, surnommées « PHP2Shell », permettent à un attaquant distant et non authentifié d’exécuter du code sur un serveur web. Le projet PHP les a corrigées le 21 octobre 2026 dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. La CISA les a inscrites le 26 octobre à son catalogue des vulnérabilités exploitées. Toute entreprise qui fait tourner un site, une boutique, un ERP ou une API en PHP doit mettre à jour, redémarrer les processus PHP et contrôler la version réellement en service.

Au Maroc, PHP est partout : sites WordPress, boutiques en ligne, ERP Dolibarr, intranets et outils métiers développés sur mesure, souvent confiés à un hébergeur ou à une agence. Le maCERT de la DGSSI a publié plusieurs bulletins sur le sujet depuis le 21 octobre et demande d’étendre la vérification aux prestataires. Cette alerte rassemble ce que disent les sources officielles et les contrôles à faire.

Ce qui est touché

Les deux failles se situent dans la gestion interne des requêtes par PHP, pas dans une application particulière :

• CVE-2026-109618 : lors d’une erreur de mémoire insuffisante, PHP interrompt la requête alors que certaines données ne sont pas encore initialisées ; la procédure de nettoyage les lit quand même. Plusieurs façons de provoquer cette situation mènent à une exécution de code à distance.
• CVE-2026-109619 : un état global de PHP peut continuer à pointer vers la mémoire d’une requête déjà libérée, et être relu par une requête suivante traitée par le même processus. Là aussi, l’exécution de code à distance est possible.

Selon l’avis de PHP, tous les déploiements web sont exposés : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. L’avis indique qu’une exploitation complète a été validée sur Apache mod_php, et considère PHP-FPM, FrankenPHP et LiteSpeed comme vulnérables ou probablement vulnérables.

Produit	Versions touchées	Version corrigée
PHP 8.5	antérieures à 8.5.12	8.5.12
PHP 8.4	antérieures à 8.4.27	8.4.27
PHP 8.3	antérieures à 8.3.36	8.3.36
PHP 8.2	antérieures à 8.2.35	8.2.35 (fin de vie le 31 décembre 2026)
PHP 8.1, 8.0, 7.4	toutes	aucune version officielle : correctifs minimaux à compiler, paquets de distribution ou migration
PHP pour Windows	versions antérieures aux builds corrigés	8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1 (publiés le 26 octobre, avec Brotli 1.2.1)

Sources : annonces de sécurité de php.net du 21 et du 26 octobre 2026, avis GHSA-w8hw-w9fx-j79w et GHSA-6wmf-4rv5-p3rp.

Gravité et exploitation

• Gravité publiée : le projet PHP attribue aux deux failles un score CVSS v4.0 de 9.2, niveau critique, repris par la NVD. Le maCERT les classe à un niveau de risque et d’impact critique (bulletin 69782110/26).
• Exploitation : la CISA a ajouté les deux CVE à son catalogue KEV le 26 octobre 2026, sous les noms « PHP Memory Corruption Vulnerability » et « PHP Stale Internal Request-State Vulnerability ». Le maCERT signale qu’un code d’exploitation est disponible publiquement.
• Produits tiers : plusieurs équipements et logiciels embarquent PHP. Le maCERT a publié des bulletins dédiés aux produits Citrix, Cisco, F5, QNAP et Tenable concernés par PHP2Shell. Pour ces appareils, c’est la mise à jour de l’éditeur de l’équipement qu’il faut attendre et appliquer, pas une mise à jour manuelle de PHP.

Les mesures d’attente, si la mise à jour doit attendre quelques heures

L’avis de PHP les décrit comme partielles : elles réduisent le risque, elles ne le suppriment pas.

1. Contre CVE-2026-109619 : régler session.upload_progress.enabled = 0 dans php.ini, dans le pool PHP-FPM ou dans la configuration du serveur, puis redémarrer tous les processus. Un réglage par ini_set() ou .user.ini ne compte pas. Sur PHP 8.5, régler aussi fatal_error_backtraces = 0.
2. Contre CVE-2026-109618 : l’avis propose d’imposer administrativement memory_limit = -1, en vérifiant qu’aucun pool ni aucune application ne rétablit une limite, et de garder un post_max_size prudent. Il déconseille formellement RLIMIT_AS et RLIMIT_DATA, qui déclenchent justement le chemin vulnérable.
3. En amont du serveur : limiter au niveau du reverse proxy ou du pare-feu applicatif la taille des requêtes, le nombre de champs, de parties multipart et d’en-têtes. Si l’application n’utilise pas de formulaires d’envoi de fichiers, bloquer les requêtes multipart.

Le maCERT a publié le 22 octobre un bulletin spécifique sur un piège fréquent : croire la remédiation faite alors que le serveur exécute toujours l’ancien moteur.

Les vérifications à faire

• Inventorier tout ce qui exécute PHP : sites publics, sites de préproduction oubliés, ERP, API, intranets, panneaux d’hébergement, sans oublier ce que gèrent vos prestataires et votre hébergeur.
• Contrôler la version en service, pas celle du paquet : php -v donne la version de l’outil en ligne de commande, qui peut différer de celle de PHP-FPM ou d’Apache. Vérifiez la version de chaque service PHP et sa date de démarrage, qui doit être postérieure à la mise à jour.
• Redémarrer réellement : PHP-FPM, Apache avec mod_php, services CGI. Pour Docker, recréer les conteneurs à partir de l’image corrigée ; télécharger la nouvelle image ne suffit pas.
• Vérifier l’origine du correctif : pour PHP 8.1 et antérieur, un paquet de la distribution ou d’un fournisseur de support, jamais un correctif non officiel trouvé en ligne.
• Chercher des traces : nouveaux fichiers PHP dans les répertoires web, comptes administrateurs créés récemment, tâches planifiées inconnues, connexions sortantes inhabituelles du serveur. La CISA demande d’ailleurs aux agences fédérales américaines une analyse forensique en plus du correctif.
• Contrôler les équipements tiers : appliquer les mises à jour publiées par Citrix, Cisco, F5, QNAP ou Tenable pour les produits listés par le maCERT.

Notre lecture pour les entreprises au Maroc

Le cas le plus risqué que nous rencontrons est le serveur dont personne ne se sent responsable : le site vitrine refait il y a quelques années par une agence, l’ancien serveur Dolibarr resté en ligne après une migration, la préproduction exposée sur internet. Le second est l’hébergement mutualisé : vous ne pouvez pas mettre à jour PHP vous-même, mais vous pouvez et devez demander à l’hébergeur sa version et sa date d’application. Si vous utilisez Dolibarr, notre guide Dolibarr au Maroc : hébergement et mise en place détaille comment séparer et maintenir le serveur.

Une faille de ce type rappelle aussi trois fondamentaux : une sauvegarde 3-2-1 immuable pour pouvoir reconstruire un serveur compromis, une supervision et un EDR managés 24/7 pour repérer un comportement anormal, et une méthode de mise à jour planifiée comme celle que nous décrivons pour les mises à jour FortiOS. Pour les organismes concernés, la loi 05-20 et les exigences de la DGSSI imposent par ailleurs de traiter ces alertes.

Comment nous pouvons vous aider

Nous inventorions vos serveurs et applications PHP, y compris ceux confiés à des tiers, appliquons les versions corrigées avec redémarrage contrôlé, vérifions l’absence de traces de compromission et mettons en place la supervision 24/7, avec une prise en charge des incidents critiques en moins de 15 minutes. Retrouvez notre approche de la cybersécurité des entreprises au Maroc, puis demandez votre audit initial offert : nous vous répondons sous 24 h ouvrées.

Sources : annonces de sécurité PHP, avis GHSA-w8hw-w9fx-j79w, catalogue CISA KEV, NVD CVE-2026-109618, NVD CVE-2026-109619, bulletins du maCERT (DGSSI).