Le 21 octobre 2026, l’équipe chargée de PHP a publié en urgence plusieurs mises à jour corrigeant deux vulnérabilités critiques. Référencées sous les identifiants CVE-2026-109618 et CVE-2026-109619, elles ont toutes deux reçu une note de gravité de 9,2 sur 10.

Leur danger tient en quelques mots : dans certaines configurations, une personne non authentifiée peut envoyer une requête spécialement préparée à un serveur vulnérable et parvenir à y exécuter du code.

Autrement dit, l’attaquant n’a pas nécessairement besoin d’un compte administrateur ni d’un mot de passe compromis. Une exploitation réussie pourrait lui permettre de consulter des fichiers, d’accéder à une base de données, de modifier un site, d’installer un logiciel malveillant ou d’utiliser le serveur comme point de départ vers d’autres systèmes.

L’incident ne concerne donc pas une simple extension WordPress défectueuse. Les failles se trouvent au cœur même de PHP, l’un des principaux moteurs techniques du Web.

PHP : l’infrastructure invisible derrière des millions de sites

PHP est un langage exécuté sur les serveurs. Il permet notamment de générer les pages, traiter les formulaires, interroger les bases de données et administrer les comptes des utilisateurs.

Au 26 octobre 2026, PHP était utilisé par 69,2 % des sites dont le langage serveur pouvait être identifié. WordPress, qui repose sur PHP, équipait pour sa part près de 40 % de l’ensemble des sites Web.

Cette présence massive explique la gravité de l’alerte. Un même défaut peut potentiellement affecter des catégories très différentes de services :

Plusieurs administrations européennes ont temporairement désactivé des services en ligne pendant leurs opérations de sécurisation. Des autorités nationales de cybersécurité ont également demandé aux organisations concernées d’appliquer immédiatement les correctifs.

Comment fonctionnent les deux failles ?

Les deux vulnérabilités concernent la gestion de la mémoire par PHP.

La première, CVE-2026-109618, peut apparaître lorsqu’une requête dépasse la mémoire autorisée. PHP interrompt alors son traitement, mais certaines données internes peuvent rester partiellement initialisées. Lors du nettoyage, le programme risque de considérer ces données invalides comme légitimes.

La seconde, CVE-2026-109619, permet à certaines informations liées à une requête de subsister après la libération de la mémoire qui les contenait. Une requête suivante peut alors provoquer l’utilisation de cet état devenu obsolète.

Dans les deux cas, cette corruption de mémoire peut conduire à une exécution de code à distance. Des chercheurs ont regroupé ces vulnérabilités sous le nom de PHP2Shell.

Il ne suffit pas qu’un serveur utilise PHP pour qu’une attaque réussisse automatiquement. L’exploitation dépend de sa configuration et de la capacité de l’attaquant à provoquer des conditions précises. Mais l’étendue des versions concernées et la possibilité d’une attaque sans authentification justifient le niveau d’alerte maximal.

Quelles versions sont concernées ?

Les vulnérabilités affectent les versions de PHP allant de la branche 5.4 jusqu’à PHP 8.5.11.

Les versions corrigées sont :

PHP 8.1 et les branches antérieures ne reçoivent pas ces correctifs, car elles ne sont plus prises en charge. Les sites qui les utilisent doivent donc migrer vers une version maintenue, et pas simplement attendre une mise à jour mineure. PHP 8.2 arrivera par ailleurs en fin de vie le 31 décembre 2026.

L’équipe PHP est catégorique : il n’existe pas de mesure de contournement complète. Installer une version corrigée reste le seul choix considéré comme sûr.

Mettre WordPress à jour ne suffit pas

L’une des principales sources de confusion concerne WordPress. Un administrateur peut avoir installé la dernière version du CMS, actualisé tous ses thèmes et corrigé ses extensions, tout en restant exposé.

La raison est simple : PHP se trouve sous WordPress, au niveau du serveur. Sa mise à jour relève généralement de l’hébergeur, de l’administrateur système ou du responsable technique de l’organisation.

Dans WordPress, la version utilisée peut être consultée dans Outils → Santé du site → Informations → Serveur → Version de PHP.

Cependant, modifier directement la version depuis un tableau de bord d’hébergement peut rendre une ancienne application incompatible. Une sauvegarde et un test préalable sont donc nécessaires, surtout pour les sites développés sur mesure.

Pourquoi le risque est particulièrement important en Afrique

Il n’existe pas encore de mesure publique fiable indiquant combien de serveurs africains sont vulnérables aux deux failles. Affirmer que la majorité des sites africains sont touchés serait donc prématuré.

Plusieurs caractéristiques de l’écosystème numérique continental augmentent néanmoins le risque.

1. Une forte dépendance aux solutions accessibles

PHP, WordPress et les hébergements mutualisés ont permis à des milliers de PME, médias, écoles, ONG et institutions africaines de se mettre en ligne à moindre coût.

Cette accessibilité constitue une force. Mais elle crée aussi une dépendance à des logiciels et serveurs dont les propriétaires de sites ne maîtrisent pas toujours la maintenance.

Une entreprise peut ainsi croire qu’elle dispose d’un « simple site WordPress », alors qu’elle dépend en réalité d’une version précise de PHP, du système d’exploitation du serveur, de son hébergeur, de plusieurs extensions et parfois d’un prestataire qui n’assure plus le suivi.

2. Des versions anciennes encore très présentes

À l’échelle mondiale, 26,7 % des sites utilisant PHP fonctionnent toujours avec la version 7 et 7,7 % avec la version 5, deux branches arrivées en fin de vie.

Cette statistique n’est pas propre à l’Afrique. Mais elle illustre une réalité familière sur le continent : de nombreux sites sont livrés comme des projets ponctuels, sans budget de maintenance récurrent, inventaire technique ou contrat imposant l’installation rapide des correctifs.

Le problème n’est donc pas seulement la nouvelle vulnérabilité. C’est l’absence de responsabilité claire après la mise en ligne.

3. Des services numériques de plus en plus critiques

Les sites Web africains ne sont plus uniquement des vitrines institutionnelles. Ils collectent des candidatures, des paiements, des dossiers étudiants, des informations sanitaires, des données clients et des pièces d’identité.

La compromission d’un serveur PHP peut donc entraîner :

Cette exposition intervient dans un contexte déjà difficile. Selon INTERPOL, les services financiers, les télécommunications et les administrations comptent parmi les secteurs africains les plus affectés par les cybermenaces. Son rapport 2026 décrit la cybercriminalité comme une menace désormais systémique pour l’économie et les institutions du continent.

4. Une capacité de réponse encore inégale

Toutes les organisations ne disposent pas d’un responsable de la sécurité, d’une équipe informatique permanente ou d’une procédure de réponse aux incidents.

INTERPOL rapporte que 94 % des agences africaines interrogées manquent d’outils suffisants de criminalistique numérique, tandis que 78 % signalent des insuffisances budgétaires ou humaines. Ces chiffres concernent les services chargés des enquêtes, mais ils illustrent plus largement les contraintes qui ralentissent la détection et la réponse aux incidents sur le continent.

Pendant ce temps, les attaquants peuvent scanner automatiquement de très nombreux serveurs afin de rechercher ceux qui n’ont pas été corrigés.

Une faille découverte grâce à l’intelligence artificielle

L’incident révèle également une nouvelle dimension de la cybersécurité : l’IA accélère désormais la recherche de vulnérabilités.

Des chercheurs travaillant avec OpenAI ainsi que l’entreprise Wiz ont contribué à identifier et démontrer les failles. L’un des problèmes avait donné lieu à de premiers signaux dès 2024, mais son potentiel d’exploitation n’avait pas été suffisamment établi. La PHP Foundation a reconnu que le retard de traitement constituait une « défaillance structurelle ».

Cette évolution comporte deux faces.

L’IA peut aider les défenseurs à analyser des millions de lignes de code, repérer des comportements inhabituels et tester plus rapidement les correctifs. Mais une fois les informations publiées, les mêmes capacités peuvent faciliter l’analyse des mises à jour et l’automatisation des tentatives d’exploitation.

Pour l’Afrique, le message est important : l’IA ne doit pas seulement être envisagée comme un outil de productivité ou de création de contenu. Elle devient également un instrument de cyberdéfense — et potentiellement de cyberattaque. INTERPOL estime qu’elle intervient déjà dans 55 % des cybercrimes signalés sur le continent, en rendant certaines opérations plus rapides et plus faciles à déployer à grande échelle.

Ce que les organisations doivent faire maintenant

Les entreprises, administrations, médias, universités, ONG et agences Web devraient entreprendre cinq actions immédiates.

1. Identifier tous les services utilisant PHP

Il faut examiner les sites publics, sous-domaines, anciennes plateformes, interfaces internes et applications abandonnées mais toujours accessibles.

2. Vérifier la version réellement exécutée par le serveur

La version affichée dans les documents du projet peut différer de celle installée par l’hébergeur.

3. Installer une version corrigée

Les versions minimales sûres sont PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les branches 8.1 et antérieures doivent être remplacées.

4. Rechercher des signes de compromission

La mise à jour ferme la faille, mais n’efface pas une intrusion déjà réussie. Il faut examiner les journaux, nouveaux comptes, fichiers modifiés, tâches planifiées, connexions inhabituelles et transferts de données suspects.

5. Clarifier la responsabilité de la maintenance

Chaque contrat de développement ou d’hébergement devrait indiquer qui surveille les alertes, installe les correctifs, réalise les sauvegardes et intervient en cas d’incident.

Si une organisation ne peut pas corriger immédiatement un serveur exposé, les autorités recommandent d’en limiter l’accès ou de le retirer temporairement d’Internet. Pour un service essentiel, cette décision doit être accompagnée d’un plan de continuité.

Le véritable problème : nous finançons la création, rarement la maintenance

Cette crise rappelle une faiblesse profonde de nombreux projets numériques africains.

Les budgets financent souvent la conception d’un site, son lancement et sa communication. Ils couvrent beaucoup plus rarement sa maintenance pendant trois ou cinq ans. Après la livraison, le développeur passe à un autre projet, le prestataire disparaît ou l’organisation perd l’accès technique au serveur.

Or, un service numérique n’est jamais définitivement terminé. Il doit être corrigé, surveillé, sauvegardé, documenté et régulièrement testé.

La question posée par les failles PHP dépasse donc la technologie : qui reste responsable d’un service numérique après son inauguration ?

Tant que les administrations, entreprises et partenaires de développement considéreront la maintenance comme une dépense facultative, de nouvelles vulnérabilités continueront à transformer des infrastructures utiles en portes d’entrée pour les attaquants.

La transformation numérique africaine ne pourra être durable que si chaque investissement dans une plateforme s’accompagne d’un investissement dans sa sécurité, son exploitation et son renouvellement.

Sources principales

Les informations techniques et l’état des versions correspondent aux publications disponibles le 26 octobre 2026. Les administrateurs doivent vérifier les éventuelles mises à jour ultérieures auprès de PHP et de leur hébergeur.