Deux failles PHP critiques sont confirmées le 21 octobre 2026 : CVE-2026-109618 et CVE-2026-109619. Les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 corrigent les deux vulnérabilités. Ce récapitulatif arrêté au 21 octobre 2026 aide à organiser une campagne de correction : identifier les environnements, demander les preuves aux hébergeurs et vérifier que chaque service utilise effectivement le correctif.
Le mois est en cours. Cette synthèse couvre les deux avis PHP confirmés ci-dessous ; elle ne constitue pas un inventaire exhaustif des vulnérabilités de tous les CMS et frameworks.
Quelles failles PHP sont confirmées en octobre 2026 ?
Les deux avis php/php-src publiés le 21 octobre décrivent des défauts distincts de gestion de l’état interne du moteur PHP. Ils portent chacun un score CVSS 4.0 de 9,2/10, classé critique, et des conséquences pouvant aller jusqu’à l’exécution de code à distance sans authentification.
| Vulnérabilité | Défaut décrit par PHP | Conséquence pour la correction |
|---|---|---|
| CVE-2026-109618 | Corruption de l’état interne lors d’une erreur de mémoire insuffisante | Vérifier le correctif du moteur et les conditions propres à son mode web |
| CVE-2026-109619 | État interne conservé après la libération de la mémoire d’une requête | Vérifier aussi ce second correctif ; une mesure limitée aux téléversements ne couvre pas tout l’avis |
L’avis sur CVE-2026-109618 confirme une exécution de code sur mod_php. L’avis sur CVE-2026-109619 décrit notamment une validation sur mod_php et FPM pour un chemin lié aux sessions. Les conditions ne sont pas identiques selon les modes et les applications.
Pour qualifier un site précis, notre analyse de la faille PHP et des étapes de correction détaille les versions et les contrôles. Ici, l’objectif est de suivre plusieurs environnements sans confondre annonce, mise à jour et vérification.
Quelles dates retenir pour suivre l’alerte ?
La préannonce du 20 octobre, les annonces de disponibilité du 21 octobre et les entrées du ChangeLog doivent rester distinctes. Une veille utile conserve ces différences au lieu de les transformer en une date unique.
- 20 octobre 2026 : PHP annonce une prochaine publication de sécurité concernant deux vulnérabilités critiques, avec un score CVSS 4.0 de 9,2 pour chacune.
- 21 octobre 2026 : PHP annonce la disponibilité des quatre versions corrigées et publie les détails des vulnérabilités.
- 21 octobre 2026 : le CERT-FR publie l’alerte CERTFR-2026-ALE-014. La version consultée reprend encore la préannonce et l’horaire prévu pour les correctifs.
- 22 octobre 2026 : c’est la date affichée dans l’entrée 8.5.12 du ChangeLog lors de notre consultation du 21 octobre.
L’archive officielle PHP présente les correctifs comme disponibles. La différence avec le ChangeLog est une divergence de datation à signaler, sans inventer une heure de sortie ou reporter artificiellement la correction.
De même, une démonstration technique ne prouve pas à elle seule une exploitation active dans la nature. Les signalements d’attaques demandent leur propre source et leur propre date. Le besoin de correction reste établi par les avis de sécurité.
Quel correctif demander à son hébergeur ?
La demande doit citer les deux CVE et la branche PHP qui traite réellement les requêtes du site. Pour les versions amont, les premiers correctifs sont PHP 8.2.35 pour la branche 8.2, 8.3.36 pour 8.3, 8.4.27 pour 8.4 et 8.5.12 pour 8.5. Dans chacune de ces branches, les versions antérieures au seuil correspondant sont affectées.
Demandez au fournisseur le numéro complet de son paquet, l’avis de sécurité applicable et la confirmation de sa prise en compte par le service web. Une distribution peut rétroporter un correctif dans un paquet dont le numéro amont paraît ancien. Il faut alors la preuve documentaire couvrant les deux identifiants, puis la preuve que ce paquet est actif.
La page des versions supportées distingue maintien actif, correctifs de sécurité et fin de vie. PHP 8.2 reste sous support de sécurité jusqu’au 31 décembre 2026 ; cette échéance exige aussi une préparation de migration. Notre guide pour maintenir PHP à jour traite cette planification au-delà de l’alerte.
Comment prioriser les sites et les applications ?
La priorité doit combiner l’exposition, le mode d’exécution, la preuve du correctif et les conséquences d’une interruption. PHP vise les installations servant des requêtes web et considère le risque le plus élevé pour mod_php. La présence de PHP-FPM ne permet pas d’exclure les deux failles.
Voici une méthode de tri proposée pour le parc :
- Recenser les services exposés. Désigner un responsable pour chaque site, API, espace client ou application PHP, y compris ceux gérés par un prestataire.
- Lever les inconnues. Une version inconnue, un mode non identifié ou un rétroportage sans avis restent des points à vérifier. Ne pas les classer automatiquement comme corrigés.
- Préparer les interventions prioritaires. Examiner d’abord les services accessibles depuis Internet et les configurations sans preuve de correction, en tenant compte des conditions publiées et des dépendances métier.
- Suivre les autres environnements. Contrôler les services internes accessibles à des utilisateurs ou à d’autres applications, ainsi que les copies susceptibles d’être remises en ligne.
Pour les équipes qui exploitent aussi des agents, la gouvernance des agents IA aide à identifier qui décide des accès et des actions sur les systèmes reliés. Cette responsabilité doit rester explicite pendant une mise à jour d’urgence.
Les deux correctifs se suivent ensemble ; une atténuation ne remplace pas la mise à jour.
Quelles mesures temporaires peut-on retenir ?
Les mesures temporaires décrites par PHP et le CERT-FR diminuent certaines expositions sans remplacer les correctifs. L’alerte CERT-FR précise notamment que ses contournements ne sont pas qualifiés et que la désactivation du suivi de progression des téléversements n’agit que sur une des deux vulnérabilités.
L’équipe d’exploitation doit vérifier l’effet des restrictions envisagées sur les fonctions du service. Bloquer certains transferts peut aussi bloquer un formulaire utile. Si une application ne peut pas être corrigée, son isolement ou une restriction d’accès temporaire doivent être examinés avec son responsable.
Un pare-feu applicatif déclaré, un changement de configuration ou une page d’accueil fonctionnelle ne suffisent pas à fermer une ligne de suivi. Notez la mesure appliquée, sa limite, son responsable et la correction qui reste à effectuer. Pour les anciennes branches, demandez une preuve fournisseur ou organisez la migration vers une branche maintenue.
Comment suivre l’avancement sans perdre les preuves ?
Une campagne de correction peut être suivie avec trois états simples : à qualifier, à corriger et vérifié. Cette méthode proposée évite qu’une demande envoyée à l’hébergeur soit confondue avec une intervention terminée.
Pour chaque environnement, conservez la branche et la version web, la révision du paquet, le fournisseur, les deux CVE couvertes et l’avis utilisé. Ajoutez la date de l’intervention, le renouvellement des processus, les parcours testés et l’identité du responsable de validation. Le registre de preuves en production offre une logique transposable à ce suivi documentaire.
Avant la clôture, vérifiez que les contrôles portent sur chaque environnement et chaque groupe de processus concerné. Une confirmation pour un site ne vaut pas automatiquement pour les autres sites du même contrat d’hébergement.
La gouvernance IA fournit aussi un cadre pour attribuer les responsabilités lorsque des services PHP alimentent des systèmes IA. Si l’alerte révèle des dépendances mal connues, l’intégration des innovations peut servir à recadrer leurs interfaces et leurs conditions d’exploitation.
Comment Noolya intervient
Noolya intervient pour transformer l’alerte PHP en un plan de vérification et de correction adapté à vos environnements. L’intervention peut comprendre le diagnostic d’exposition, la coordination avec les hébergeurs, le plan de mise à jour, la mise à jour autorisée, les tests de non-régression, le durcissement et la vérification après correction. Le périmètre est établi avec les responsables techniques et métier.
Le diagnostic faille PHP prépare un premier état des informations connues. Cette auto-évaluation déclarative ne réalise aucun scan de site ou de serveur et ne prouve pas l’installation d’un correctif.
Noolya intervient : vérification et correction. Prenez rendez-vous avec Noolya pour organiser un diagnostic détaillé et définir les prochaines actions sur votre parc.
Questions fréquentes
Ce récapitulatif couvre-t-il tout le mois d’octobre 2026 ? Cette version est arrêtée au 21 octobre 2026 et porte sur les deux avis PHP explicitement sourcés. Le mois étant en cours, elle ne prétend pas couvrir toutes les publications ultérieures ni tous les composants de l’écosystème PHP.
Les deux CVE exigent-elles deux mises à jour séparées ? Les versions PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 corrigent les deux vulnérabilités dans leurs branches respectives. Pour un paquet de distribution, l’avis fournisseur doit confirmer que les deux correctifs sont inclus.
Un ancien numéro PHP signifie-t-il toujours que le paquet est vulnérable ? Un fournisseur peut avoir rétroporté les correctifs sans adopter le numéro amont. Il faut examiner l’avis et la révision exacte du paquet, puis vérifier le moteur effectivement chargé pour le service web.
Peut-on clore la campagne quand les pages répondent normalement ? Le fonctionnement des pages constitue seulement une partie des contrôles. La clôture demande aussi la preuve du correctif actif et les résultats des parcours retenus pour chaque environnement concerné.
Sources
-
CVE-2026-109618 dans la NVD et CVE-2026-109619 dans la NVD : fiches reçues, source PHP Group, consultées le 21 octobre 2026 ; ces fiches ne constituent pas une évaluation indépendante du NIST.
-
Security advisory: Critical remote code execution vulnerabilities, update now : PHP ; annonces des 20 et 21 octobre 2026, versions et recommandations.
-
RCE via OOM corruption : php/php-src ; CVE-2026-109618, conditions, versions et gravité.
-
RCE via stale global state : php/php-src ; CVE-2026-109619, conditions, versions et gravité.
-
PHP 8 ChangeLog : entrée 8.5.12 affichant le 22 octobre, distincte des annonces de disponibilité.
-
Multiples vulnérabilités dans PHP : CERT-FR ; alerte du 21 octobre et limites des contournements provisoires.
-
Supported Versions : PHP ; branches supportées et échéances de maintenance.
Couverture : logo PHP de Colin Viebrock, CC BY-SA 4.0, intégré à une composition éditoriale diffusée sous la même licence. Référence officielle PHP. Aucune approbation de PHP n’est suggérée.
