PHP2Shell, dix jours après : en Afrique, il faut désormais prouver la correction

Une alerte devenue opérationnelle

Dix jours après la publication des correctifs PHP du 21 octobre 2026, le niveau d'urgence a changé. CVE-2026-109618 et CVE-2026-109619, souvent regroupées sous le nom PHP2Shell, ne sont plus seulement deux vulnérabilités critiques décrites par leurs découvreurs. Le Centre canadien pour la cybersécurité rapporte que du code de démonstration est disponible et que des sources ouvertes font état d'exploitation dans la nature. Le 26 octobre, la CISA américaine a ajouté les deux références à son catalogue des vulnérabilités connues comme exploitées.

Ces signaux ne prouvent pas que chaque tentative observée réussit, ni qu'une organisation africaine précise a été compromise. Ils rendent toutefois intenable une réponse fondée uniquement sur l'absence d'alerte antivirus ou sur la promesse générique d'un hébergeur. Une application exposée doit être classée par version réellement chargée, mode d'exécution, correctif fournisseur et qualité des journaux disponibles.

Les deux défauts touchent le moteur PHP lorsqu'il traite des requêtes web. Le premier peut laisser des structures internes dans un état incohérent après une erreur de mémoire; le second permet à un état devenu obsolète de survivre entre des requêtes traitées par le même worker. Sous certaines conditions, cette corruption peut conduire à une exécution de code sans authentification. Le risque ne dépend donc pas du seul CMS visible : WordPress, Drupal, Laravel ou une application sur mesure peuvent tous reposer sur le même runtime vulnérable.

Les versions et les preuves attendues

Les versions amont corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Les branches 8.1 et antérieures ne sont plus maintenues normalement par le projet PHP, même si des distributions, prestataires de support longue durée et hébergeurs ont pu rétroporter le correctif. Le registre opérationnel du NCSC néerlandais montre précisément pourquoi le numéro affiché ne suffit pas : certains fournisseurs déclarent des builds anciens corrigés, d'autres des produits non vulnérables, et d'autres encore poursuivent leur analyse.

Une preuve acceptable doit relier le domaine public au processus qui reçoit sa requête. Pour PHP-FPM, il faut identifier le pool actif, le paquet ou l'image qui fournit son binaire, la révision du fournisseur et l'heure du dernier redémarrage. Pour Apache avec mod_php, la preuve doit porter sur le module chargé par le processus Apache. Pour Docker, il faut conserver le digest de l'image reconstruite et montrer que l'ancien conteneur n'est plus celui qui sert le trafic. La sortie de php -v dans le compte d'un administrateur peut décrire un autre binaire et ne clôt pas l'audit.

Cette nuance est particulièrement importante pour les hébergements mutualisés largement utilisés par les PME, médias, universités, collectivités et associations africaines. Le client n'a pas toujours accès au système d'exploitation. Il doit alors demander au prestataire une référence d'avis, un identifiant de build, la date de déploiement et la confirmation que les workers ont été renouvelés. Un en-tête HTTP masqué ou une version de CMS à jour n'apporte pas cette assurance.

Une troisième référence à ne pas confondre

PHP a également publié des précisions sur CVE-2026-115560. Cette vulnérabilité suppose une configuration et un comportement applicatif inhabituels : certains gestionnaires de sérialisation de session sont remplacés à l'exécution avant session_start(), tandis que la progression d'upload de session reste active. Le Centre canadien indique que les mises à jour du 21 octobre ne corrigent pas ce cas particulier. Dans cette configuration, la mesure temporaire recommandée est de désactiver session.upload_progress.enabled jusqu'à la publication d'un correctif adapté.

Il ne faut ni ignorer cette troisième référence ni la présenter comme une exposition universelle identique aux deux premières. L'équipe doit rechercher la configuration et le chemin applicatif concernés. En leur absence, elle documente le résultat; en leur présence, elle applique la mitigation et suit la prochaine version PHP.

Chercher une compromission sans surinterpréter

La correction et l'investigation sont deux travaux différents. Une mise à jour ferme la vulnérabilité pour les nouvelles requêtes; elle n'efface pas un accès obtenu auparavant. Les équipes doivent préserver les journaux du reverse proxy, du serveur web, de PHP-FPM, de l'EDR et du fournisseur cloud avant leur rotation. Elles peuvent ensuite rechercher des processus enfants inattendus lancés par le compte web, des fichiers exécutables nouvellement créés, des tâches planifiées inconnues, des modifications de comptes ou de clés, et des connexions sortantes inhabituelles.

Aucun de ces éléments, pris isolément, ne prouve PHP2Shell. À l'inverse, l'absence de résultat dans des journaux incomplets ne prouve pas l'absence de compromission. Si des indicateurs convergent, il faut isoler l'hôte, préserver une copie exploitable pour l'analyse, faire tourner les secrets accessibles et reconstruire depuis une base connue, plutôt que simplement supprimer un fichier suspect.

Les règles WAF publiées par plusieurs fournisseurs réduisent l'exposition à des formes connues de requêtes. Elles ne remplacent pas le correctif, comme le rappelle l'avis PHP. Les limites mémoire, la désactivation temporaire de certaines fonctions de session ou le retrait d'une route publique sont des mesures de réduction du risque, pas une certification de sécurité.

Ce que les responsables africains doivent exiger

Pour chaque service exposé, le tableau de suivi devrait contenir le domaine, le propriétaire métier, le SAPI PHP, la version ou le build actif, la source du correctif, la date de redémarrage, la preuve de validation et le résultat de la recherche d'indicateurs. Les équipements et logiciels qui embarquent PHP doivent être traités séparément : un portail d'administration, une appliance réseau ou un produit livré par un intégrateur peut contenir son propre moteur sans apparaître dans l'inventaire des serveurs classiques.

La réponse correcte n'est donc plus « nous avons lancé les mises à jour ». Elle est : « voici le processus qui servait ce domaine, voici le build corrigé qu'il charge maintenant, voici quand les anciens workers ont disparu, et voici ce que l'analyse des traces a ou n'a pas permis d'établir ». Cette discipline est accessible aux organisations africaines, y compris avec des moyens limités, et elle produit une assurance bien plus forte qu'un scan de surface ou qu'une déclaration non documentée.

— ◆ —