PHP corrige deux RCE critiques : l'Afrique doit vérifier ses serveurs, pas seulement ses sites

L'alerte est devenue un correctif urgent

Le 21 octobre 2026, le projet PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 pour corriger deux vulnérabilités critiques : CVE-2026-109618 et CVE-2026-109619. Toutes deux peuvent conduire à une exécution de code à distance sans authentification. L'avis officiel considère comme concernés les environnements PHP qui servent des requêtes web, notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. Le risque est jugé particulièrement élevé avec mod_php, pour lequel une exploitation avant même l'exécution du code applicatif a été démontrée.

Le premier défaut concerne le traitement des erreurs de mémoire insuffisante. PHP peut interrompre une requête alors que certaines données internes ne sont que partiellement initialisées; la phase de nettoyage peut ensuite interpréter cet état invalide comme légitime. Le second concerne un état global devenu obsolète : des références appartenant à une requête peuvent survivre après la libération de leur mémoire et être réutilisées par une requête ultérieure traitée par le même worker. Ce sont des défauts du moteur, pas des vulnérabilités propres à WordPress, Drupal ou à une application métier particulière.

Les sources officielles consultées ne permettent pas d'affirmer qu'une campagne d'exploitation massive vise déjà des organisations africaines. Cette absence de confirmation ne réduit pas la priorité : la vulnérabilité est exploitable avant ou autour du démarrage normal de l'application, là où un correctif de CMS ou une règle fonctionnelle ne suffit pas.

Les versions corrigées sont connues

Les branches maintenues doivent atteindre au minimum PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. PHP 8.1 et les branches antérieures ne reçoivent plus de mises à jour régulières du projet. Face à la gravité de l'incident, l'équipe PHP a néanmoins fourni des rétroportages minimaux pour les personnes qui compilent PHP 7.4, 8.0 ou 8.1 elles-mêmes. Cela ne transforme pas ces branches en versions maintenues.

Une distribution Linux ou un fournisseur de support longue durée peut aussi rétroporter le correctif sans reprendre le numéro de version publié par PHP.net. L'équipe technique doit donc vérifier l'avis du fournisseur réel du paquet, sa révision et le binaire chargé par le service. La sortie de php -v dans un terminal n'est pas toujours une preuve suffisante : la commande peut utiliser un autre binaire que PHP-FPM, Apache ou le conteneur qui reçoit les requêtes publiques.

Le 23 octobre, PHP a publié une précision distincte sur CVE-2026-115560. Ce cas suppose une combinaison inhabituelle : certains gestionnaires de sérialisation de session sont configurés puis remplacés à l'exécution avant session_start(), tandis que la progression d'upload de session reste activée. PHP recommande de désactiver temporairement session.upload_progress.enabled dans cette configuration jusqu'à la prochaine version corrective régulière. Il ne faut pas confondre cette condition étroite avec les deux RCE critiques du 21 octobre, pour lesquelles la mise à jour immédiate reste la réponse complète.

Pourquoi l'exposition africaine est difficile à mesurer

De nombreuses administrations, universités, médias, PME, établissements de santé et plateformes de commerce utilisent PHP sans le gérer directement. Le moteur peut appartenir à un hébergeur mutualisé, un intégrateur, une image Docker ancienne ou un panneau cPanel. L'équipe qui met à jour l'application n'est donc pas nécessairement celle qui doit corriger le runtime.

Cette fragmentation crée un risque de faux positif comme de faux sentiment de sécurité. Voir un en-tête X-Powered-By n'établit ni la version exacte ni l'exploitabilité. À l'inverse, masquer cet en-tête ne corrige rien. La preuve utile relie quatre éléments : le service public, le processus qui traite sa requête, le paquet ou l'image qui fournit PHP, et la version corrigée effectivement chargée après redémarrage.

La dépendance aux prestataires renforce l'enjeu de gouvernance. Une réponse générique comme « le serveur est sécurisé » ne suffit pas. Le client doit obtenir la branche utilisée, la référence du correctif fournisseur, la date de déploiement et une méthode de validation. Pour un service essentiel, le contrat devrait également préciser le délai de correction des vulnérabilités critiques et le plan de continuité si la mise à jour provoque une incompatibilité.

Une méthode d'audit qui produit des preuves

La première étape est un inventaire en lecture seule : paquets système, services PHP-FPM, modules Apache, binaires CGI, conteneurs, images de base, tâches planifiées et environnements de démonstration. Chaque runtime doit être associé à ses domaines, ports, propriétaires et données traitées. Les versions installées mais inactives doivent être distinguées des versions réellement exposées.

Avant la correction, il faut préserver les bases, fichiers téléversés, volumes et configurations, puis vérifier les sauvegardes avec des empreintes. Les journaux web et PHP doivent être conservés pour rechercher des requêtes anormales, fichiers récemment créés, processus inattendus ou connexions sortantes inhabituelles. L'absence de tels signaux dans des journaux incomplets ne prouve toutefois pas l'absence de compromission.

Si la correction ne peut pas être appliquée immédiatement, l'avis PHP propose des réductions d'exposition, notamment des limites strictes de requêtes et la désactivation de la progression d'upload de session. Il précise aussi qu'aucune mitigation n'offre une protection complète. Pour une démonstration ou un service non essentiel, retirer temporairement la route publique ou arrêter le runtime vulnérable est souvent plus défendable que d'empiler des règles WAF non vérifiées.

Corriger signifie reconstruire et vérifier

Dans un conteneur, modifier le binaire à la main ne constitue pas une correction durable. Il faut reconstruire depuis une image de base corrigée, épingler la version, déployer un nouveau conteneur et retirer l'ancienne image après validation. Sur un serveur classique, il faut installer le paquet du fournisseur, redémarrer les workers concernés et vérifier la version depuis le contexte qui sert réellement le trafic.

La validation doit couvrir les parcours essentiels : authentification, formulaires, uploads, paiement, génération de documents, files de travaux et tâches planifiées. Elle doit aussi confirmer que PHP-FPM et les bases ne sont pas directement publiés, que l'application s'exécute avec le minimum de privilèges et que les secrets ne sont pas accessibles depuis le web.

Enfin, le suivi ne s'arrête pas au numéro de version. Les organisations doivent documenter la date de correction, l'actif concerné, la preuve obtenue, le responsable et les risques résiduels. Cet exercice transforme une alerte mondiale en amélioration locale mesurable.

La leçon pour les décideurs africains

Les deux failles PHP révèlent moins une faiblesse d'un langage qu'un problème d'inventaire et de responsabilité. Une organisation peut posséder une application moderne tout en l'exécutant sur une couche oubliée et vulnérable. Elle peut aussi payer un hébergement managé sans disposer de preuve sur le délai de mise à jour.

La priorité est donc simple : identifier chaque runtime qui sert le web, relier chaque actif à un responsable, appliquer le correctif du fournisseur et vérifier le processus réellement chargé. Pour PHP 8.2, dont la fin de vie amont est proche, la correction urgente doit s'accompagner d'un plan de migration. Pour les branches plus anciennes sans maintenance contractuelle démontrée, l'isolement ne peut être qu'une mesure provisoire. La cybersécurité du web africain dépend autant de cette discipline opérationnelle que de la publication des correctifs eux-mêmes.

— ◆ —