Par Adri 
Pour une grande partie du Web, PHP est un composant invisible. Les visiteurs ne le voient pas, ne l'installent pas et ignorent souvent jusqu'à son existence. Pourtant, ce langage fonctionne derrière des millions de sites et d'applications, des petites vitrines commerciales aux services en ligne les plus fréquentés.
Lorsqu'une vulnérabilité touche directement le moteur PHP, son importance dépasse donc celle d'un simple problème dans une application isolée.
Depuis le 20 octobre, les responsables du langage et plusieurs agences nationales de cybersécurité sont mobilisés autour de deux failles critiques. Le 21 octobre, quatre versions corrigées ont été publiées en urgence.
Le 23 octobre, l'équipe PHP a ajouté une troisième vulnérabilité à ce dossier. CERT-EU et le centre néerlandais de cybersécurité ont actualisé leurs recommandations, tandis que TechCrunch consacrait un épisode de son podcast Equity à ce qu'il présente comme le Black October du langage.
La situation reste sérieuse. Mais les informations disponibles permettent désormais de distinguer plusieurs risques, avec des conditions d'exploitation et des mesures correctives différentes.
Deux failles critiques au cœur du moteur PHP
Les vulnérabilités initiales sont identifiées sous les références CVE-2026-109618 et CVE-2026-109619.
Toutes deux ont reçu un score CVSS v4.0 de 9,2, correspondant à une gravité critique.
Elles concernent le fonctionnement interne de PHP plutôt qu'une erreur de programmation propre à WordPress ou à un autre système de gestion de contenu.
Leur exploitation peut permettre, dans certaines conditions, l'exécution de code arbitraire sur un serveur sans authentification préalable.
C'est ce dernier point qui justifie l'urgence. Un attaquant qui parvient à exécuter des commandes dans le contexte d'un processus PHP peut potentiellement accéder aux ressources auxquelles ce processus possède des droits.
La portée exacte d'une compromission dépend ensuite des permissions du serveur, de son isolation et de ses autres mécanismes de protection.
Une exécution de code à distance n'implique donc pas automatiquement que l'attaquant obtient immédiatement tous les privilèges de la machine.
Elle constitue néanmoins une frontière de sécurité majeure franchie.
CVE-2026-109618 : quand une limite mémoire devient dangereuse
La première faille touche la gestion des dépassements de mémoire.
PHP permet de limiter la mémoire qu'un processus peut utiliser pour traiter une requête. Lorsqu'une opération dépasse cette limite, le moteur peut interrompre son exécution.
Le problème découvert concerne ce qui se produit lorsque cette interruption survient pendant une opération interne dont certaines structures de données ne sont pas encore complètement initialisées.
Une étape de nettoyage peut alors manipuler ces données comme si elles étaient valides.
Cette situation crée un risque de corruption mémoire.
Dans leur avis de sécurité, les développeurs PHP expliquent que le problème peut notamment apparaître pendant certaines opérations liées au traitement des données envoyées à un serveur.
Ce n'est pas une vulnérabilité qui se limite à l'utilisation explicite de fonctions dangereuses dans le code applicatif.
Elle concerne une situation interne au moteur, susceptible d'être déclenchée avant même que la logique principale d'une application soit exécutée.
C'est pourquoi les recommandations officielles visent les installations PHP exposées aux requêtes Web, et pas seulement les applications dont les développeurs utiliseraient une bibliothèque particulière.
CVE-2026-109619 : un état global réutilisé après sa destruction
La seconde vulnérabilité relève également de la gestion de la mémoire, mais son mécanisme est différent.
Certaines informations internes associées à une requête peuvent rester accessibles après que la mémoire correspondante a été libérée.
Lorsqu'une autre requête est traitée par le même processus, le moteur peut réutiliser cet état devenu invalide avant sa réinitialisation normale.
On parle d'un problème d'état global périmé, ou stale global state.
Le risque apparaît notamment lorsqu'une erreur fatale ou une interruption inhabituelle modifie l'ordre habituel des opérations.
Comme pour la première vulnérabilité, une exploitation réussie peut conduire à l'exécution de code à distance.
Les deux défauts partagent donc une conséquence potentiellement grave, sans être identiques dans leur fonctionnement.
Cette distinction explique pourquoi les mesures de réduction du risque ne sont pas les mêmes.
Quelles versions de PHP doivent être corrigées ?
L'équipe PHP a publié quatre versions de sécurité le 21 octobre 2026.
Les installations de la branche 8.5 doivent utiliser au minimum PHP 8.5.12.
Celles de la branche 8.4 doivent passer à PHP 8.4.27.
Pour la branche 8.3, la version corrigée est PHP 8.3.36.
Enfin, les utilisateurs de PHP 8.2 doivent installer PHP 8.2.35.
Ces versions corrigent les deux vulnérabilités critiques identifiées au début de la semaine.
La situation des branches plus anciennes demande davantage d'attention.
PHP 8.1 et les versions antérieures ne bénéficient plus des mises à jour régulières du projet.
Certains fournisseurs de distributions Linux et de support à long terme ont néanmoins accès à des correctifs rétroportés.
Les responsables PHP ont également publié des correctifs minimaux du code source pour les branches 7.4, 8.0 et 8.1.
Ces publications exceptionnelles ne constituent pas une réouverture du support normal des anciennes versions.
Pour les infrastructures concernées, la démarche recommandée reste de vérifier les correctifs proposés par leur fournisseur et de préparer une migration vers une branche maintenue.
Le 23 octobre, une troisième vulnérabilité apparaît
L'annonce la plus récente concerne CVE-2026-115560.
L'équipe PHP la signale dans un avis d'information publié le vendredi 23 octobre.
Cette vulnérabilité peut également créer un risque d'exécution de code à distance, mais elle nécessite une configuration inhabituelle.
Plusieurs conditions doivent se rencontrer.
L'application doit utiliser initialement un gestionnaire de sérialisation des sessions configuré sur php_binary ou php_serialize.
Elle doit ensuite modifier ce gestionnaire pendant l'exécution pour utiliser php, avant de démarrer une session.
La fonctionnalité de suivi des téléversements dans les sessions doit également rester activée.
Cette combinaison est suffisamment peu courante pour que le projet PHP considère la probabilité d'exploitation comme limitée.
Les mainteneurs ont donc décidé de traiter le problème dans le cycle habituel de publication de correctifs, plutôt que de produire une nouvelle version d'urgence.
C'est une différence importante avec les deux vulnérabilités précédentes.
Les premières ont déclenché des publications exceptionnelles le 21 octobre. La troisième fait l'objet d'une mesure temporaire explicite en attendant sa correction complète.
Une protection temporaire contre la troisième faille
Pour CVE-2026-115560, le projet PHP recommande de désactiver la fonctionnalité session.upload_progress.enabled jusqu'à la prochaine publication régulière.
Cette option permet normalement de suivre l'avancement des téléversements dans une session.
Sa désactivation retire le mécanisme requis par la combinaison vulnérable décrite dans l'avis du 23 octobre.
Le changement doit être appliqué dans la configuration PHP effectivement utilisée par les processus concernés.
Les processus doivent ensuite être redémarrés pour que la modification soit prise en compte.
L'équipe PHP précise que les administrateurs ayant déjà appliqué cette mesure à la suite de l'avis du 21 octobre n'ont pas besoin d'effectuer une nouvelle modification pour cette troisième vulnérabilité.
Il ne faut toutefois pas confondre cette protection ciblée avec une correction complète des deux premières failles.
Les développeurs indiquent explicitement que les mesures temporaires ne rendent pas une installation vulnérable entièrement sûre.
Pour CVE-2026-109618 et CVE-2026-109619, la mise à jour vers les versions corrigées demeure indispensable.
Quels serveurs et logiciels sont concernés ?
Les vulnérabilités critiques initiales touchent les installations PHP servant des requêtes Web.
Les développeurs citent notamment PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed.
Le risque dépend de la version exécutée et de la configuration réelle.
L'équipe PHP considère les déploiements mod_php comme particulièrement exposés.
Dans ce contexte, les chercheurs ont démontré qu'une requête non authentifiée pouvait provoquer une exploitation avant l'exécution du code applicatif.
Cela explique pourquoi un site utilisant un CMS réputé sûr peut néanmoins dépendre d'un moteur PHP vulnérable.
Un correctif WordPress ou Magento ne remplace pas nécessairement une mise à jour du moteur PHP.
Inversement, l'utilisation de WordPress ne signifie pas qu'un site est forcément vulnérable.
Un site dont l'hébergeur a déjà installé les correctifs appropriés peut être protégé contre les deux vulnérabilités initiales.
La vérification doit porter sur l'environnement serveur effectivement utilisé, pas seulement sur le nom du logiciel visible depuis le navigateur.
Les premières craintes d'exploitation massive sont à nuancer
L'urgence de la situation a conduit plusieurs organisations à prendre des mesures exceptionnelles.
Aux Pays-Bas, le Centre national de cybersécurité a temporairement mis son propre site hors ligne à titre préventif.
D'autres organismes ont également interrompu certains services Web pendant les vérifications.
Mais les informations publiées le 23 octobre apportent une nuance importante concernant les attaques.
Le NCSC-NL indique que l'exploitation pratique des deux failles critiques semble plus complexe que les premières estimations ne le suggéraient.
L'organisme mentionne un signalement potentiel d'exploitation à l'étranger, sans pouvoir confirmer que l'attaque concernée a réussi.
Des démonstrations techniques et des tentatives d'exploitation existent.
Elles ne prouvent pas à elles seules qu'un grand nombre de serveurs ont été compromis.
Le risque reste suffisamment sérieux pour justifier les mises à jour immédiates.
La bonne qualification consiste donc à parler de vulnérabilités critiques exploitables, de tentatives signalées et d'un nombre de compromissions réussies non établi dans les sources officielles examinées.
L'intelligence artificielle a accéléré la découverte des failles
Un autre aspect de cette crise concerne les outils utilisés par les chercheurs.
Google Cloud indique que des équipes de Wiz ont participé à la découverte et à l'analyse des deux vulnérabilités.
Des modèles d'intelligence artificielle, dont Gemini 4 Argon, ont contribué à identifier des problèmes, à étudier leur exploitation et à vérifier les correctifs.
OpenAI a également publié un retour sur son initiative Patch the Planet.
L'entreprise précise que Calif a identifié une faille critique avec l'aide de GPT-5.6 Sol.
Elle indique que Wiz a découvert et signalé indépendamment les deux vulnérabilités principales.
Cette multiplicité des contributions rappelle que la recherche de failles n'est pas attribuable à un seul modèle ou à une seule entreprise.
Les mainteneurs PHP ont conservé la responsabilité des corrections et de leur publication.
Les chercheurs, les fournisseurs de sécurité et plusieurs entreprises ont contribué à coordonner la réponse.
L'IA est donc présentée comme un outil d'assistance à la recherche, pas comme un substitut complet à l'expertise humaine nécessaire pour comprendre les défauts et valider les modifications du code.
Des vulnérabilités anciennes dans un logiciel omniprésent
TechCrunch souligne que certaines faiblesses découvertes dans PHP trouvent leur origine dans des comportements ou des structures du langage présents depuis de nombreuses années.
Ce type de situation n'a rien d'exceptionnel dans les logiciels historiques.
Un langage utilisé pendant plusieurs décennies accumule des fonctionnalités, des mécanismes de compatibilité et des interactions complexes.
Des chemins d'exécution peu fréquents peuvent rester difficiles à tester, même lorsque le projet bénéficie d'une maintenance active.
L'importance de PHP dans le Web amplifie les conséquences potentielles de tels défauts.
De nombreuses applications reposent sur le même moteur, même lorsque leur code fonctionnel et leur présentation diffèrent complètement.
Un problème situé dans cette couche commune possède donc un périmètre potentiel très large.
Mais ce périmètre théorique ne doit pas être confondu avec un nombre effectif de victimes.
La proportion de sites utilisant PHP ne permet ni de calculer les installations non corrigées ni d'estimer les compromissions.
Une crise qui met aussi en lumière les moyens du logiciel libre
La maintenance de PHP repose sur une communauté de développeurs et sur plusieurs organisations participant à son financement.
La PHP Foundation contribue notamment au soutien financier des personnes travaillant sur le moteur du langage.
Elle a également annoncé en mai 2026 la création d'une équipe consacrée à la sécurité de l'écosystème.
Cette structure cherche à améliorer le traitement des signalements, à développer des outils et à soutenir les responsables de projets open source.
La crise d'octobre montre l'importance de ces efforts.
Lorsqu'une faille critique est découverte dans une technologie utilisée à très grande échelle, les mainteneurs doivent analyser le problème, développer un correctif, coordonner sa diffusion et informer les utilisateurs.
Le travail ne s'arrête pas à la publication d'une nouvelle version.
Les fournisseurs de systèmes d'exploitation, les hébergeurs et les responsables d'applications doivent ensuite intégrer les correctifs à leurs propres environnements.
Cette chaîne de responsabilités peut prendre du temps, particulièrement lorsqu'elle concerne des infrastructures anciennes.
L'épisode rappelle ainsi qu'un logiciel gratuit à utiliser n'est pas gratuit à maintenir.
Que doivent faire les administrateurs maintenant ?
La priorité consiste à inventorier les services qui exécutent PHP.
Il ne suffit pas d'examiner les sites publics les plus visibles.
Des interfaces d'administration, des applications métiers, des équipements réseau et des services embarqués peuvent également utiliser le langage.
Les systèmes accessibles depuis Internet doivent être examinés en premier.
Les administrateurs doivent ensuite vérifier la version de PHP réellement exécutée et la disponibilité des correctifs adaptés à leur distribution.
Pour les branches officiellement prises en charge, les versions publiées le 21 octobre servent de références.
Pour les distributions utilisant des rétroportages de sécurité, le numéro de version affiché peut ne pas suffire à déterminer si le correctif est présent.
Il faut consulter les bulletins du fournisseur.
Après l'installation, les processus concernés doivent être redémarrés et le fonctionnement des applications vérifié.
Les journaux de sécurité peuvent également être examinés pour rechercher des comportements suspects, sans considérer toute erreur PHP comme une preuve d'attaque.
Enfin, les administrateurs utilisant les fonctions de progression des téléversements de session doivent prendre connaissance de l'avis du 23 octobre concernant CVE-2026-115560.
Que faire lorsqu'une mise à jour immédiate est impossible ?
CERT-EU et le NCSC britannique recommandent d'envisager l'isolement temporaire des applications exposées lorsqu'une correction ne peut pas être installée rapidement.
La réduction de l'accès public limite les possibilités d'attaque à distance.
L'équipe PHP documente également plusieurs mesures temporaires concernant la gestion de la mémoire, les limites de requêtes et certaines fonctionnalités de session.
Ces paramètres ne doivent pas être modifiés mécaniquement sans examiner leurs effets.
Désactiver une limite mémoire ou modifier le traitement des téléversements peut avoir des conséquences opérationnelles sur une application.
Surtout, les mainteneurs PHP précisent que ces mesures ne constituent pas une protection complète contre les deux vulnérabilités critiques.
Elles servent uniquement à réduire l'exposition en attendant l'installation des correctifs.
Une application durablement accessible avec une version vulnérable ne devient pas sûre simplement parce qu'un paramètre de configuration a été modifié.
Le 23 octobre change le bilan, pas la priorité
La découverte d'une troisième vulnérabilité modifie la compréhension de la crise, mais ne remet pas en cause les recommandations essentielles.
Les deux failles critiques initiales disposent de correctifs publiés le 21 octobre.
La troisième, dévoilée le 23 octobre, nécessite une configuration inhabituelle et fait l'objet d'une protection temporaire documentée avant son traitement dans une prochaine version régulière.
Les autorités indiquent également que l'exploitation pratique pourrait être plus complexe que prévu, sans considérer le danger comme écarté.
Le Black October de PHP ne correspond donc pas à la compromission démontrée de l'ensemble du Web.
Il révèle un risque majeur dans un composant largement partagé par les sites et applications.
La priorité ne change pas : identifier les installations, installer les corrections appropriées, vérifier les configurations particulières et conserver une vision précise de ce qui est effectivement confirmé.
L'affaire illustre enfin une réalité parfois oubliée : la sécurité du Web dépend aussi du temps, des ressources et de l'expertise consacrés à la maintenance de logiciels que la plupart des internautes ne voient jamais.