Faille PHP CVE-2026-109618 : vérifier et corriger son site

La faille PHP CVE-2026-109618 fait partie de deux vulnérabilités critiques annoncées le 21 octobre 2026, capables de permettre une exécution de code à distance sans authentification. Les premières versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12. La décision utile consiste à identifier le moteur qui traite réellement les requêtes web, appliquer un correctif couvrant aussi CVE-2026-109619, puis vérifier sa prise en compte.

Vérification documentaire : 21 octobre 2026. Les versions et conditions ci-dessous proviennent des annonces PHP et des avis php/php-src.

Que sait-on de la faille PHP CVE-2026-109618 ?

CVE-2026-109618 concerne une corruption de l’état interne de PHP lors du traitement d’une erreur de mémoire insuffisante. Selon l’avis officiel RCE via OOM corruption, le nettoyage d’une requête peut ensuite utiliser des données internes invalides. L’impact confirmé comprend une exécution de code avec les droits du processus web.

L’avis classe cette vulnérabilité comme critique, avec un score CVSS 4.0 de 9,2/10. Elle accompagne CVE-2026-109619, qui concerne un état interne conservé après la libération de la mémoire associée. Les deux problèmes sont corrigés par les mêmes versions.

Ces descriptions établissent un risque technique sérieux. Une démonstration publiée ne suffit cependant pas à établir une exploitation active dans la nature. Il faut distinguer la possibilité documentée, les observations d’attaques et les constats propres à son environnement.

Quels serveurs PHP faut-il vérifier ?

PHP demande de mettre à jour les installations qui servent des requêtes web, notamment mod_php, PHP-FPM, php-cgi, FrankenPHP et LiteSpeed. L’annonce de sécurité du 21 octobre considère le risque le plus élevé pour Apache avec mod_php, où l’exécution de code a été démontrée avant le lancement du code applicatif.

Une page de connexion dans le CMS ne suffit donc pas à écarter cette exposition. Le composant à examiner se trouve sous l’application.

Pour CVE-2026-109618, l’avis décrit PHP-FPM comme susceptible d’être concerné, sans démonstration complète pour ce mode dans le document consulté. Pour CVE-2026-109619, une exécution de code liée au cycle des sessions a été validée sur mod_php et FPM, avec des conditions applicatives propres à FPM. Le seul choix de PHP-FPM ne constitue donc pas une preuve de protection.

Quelles versions de PHP corrigent les deux CVE ?

Chaque branche PHP possède son propre seuil de correction : les comparaisons doivent rester dans la branche installée. Les avis php/php-src donnent les bornes suivantes pour les versions amont.

Les annonces de disponibilité portent la date du 21 octobre 2026, tandis que l’entrée 8.5.12 du ChangeLog PHP affiche le 22 octobre 2026. Cette divergence de datation ne doit pas devenir une affirmation selon laquelle les correctifs seraient encore attendus : les annonces les présentent comme disponibles.

Pour un paquet de distribution, demandez son avis de sécurité : un correctif peut être rétroporté sans reprendre le numéro amont. Les branches PHP 8.1 et antérieures ne reçoivent plus de mises à jour ordinaires du projet PHP. Leur situation exige une preuve fournisseur couvrant les deux CVE ou une migration, détaillée dans notre guide pour maintenir PHP à jour.

Comment vérifier la version réellement utilisée par le site ?

La version à contrôler est celle du moteur PHP chargé pour le trafic web, avec sa révision de paquet et son mode d’exécution. Un résultat obtenu dans un terminal peut concerner un autre binaire. Il ne suffit pas à qualifier tous les sites hébergés sur la machine.

Demandez à l’administrateur ou à l’hébergeur de réunir ces éléments depuis les interfaces d’administration autorisées :

• la version PHP et la révision exacte du paquet qui sert le site ;
• le mode d’exécution, le système et le fournisseur du paquet ;
• l’avis fournisseur confirmant la correction des deux identifiants CVE ;
• les éventuels autres pools ou environnements qui servent la même application.

La documentation de php_sapi_name distingue notamment apache2handler, fpm-fcgi et cli. Ces libellés aident à vérifier ce que l’on mesure. La documentation de phpinfo rappelle que cet outil expose aussi des informations d’environnement et de configuration : évitez toute page de diagnostic accessible publiquement et tout partage de sa sortie brute.

Le diagnostic déclaratif prépare la vérification technique et ne constitue pas un test de sécurité.

Que faire si la mise à jour ne peut pas être immédiate ?

Les mesures temporaires réduisent certaines possibilités d’attaque ; PHP indique que seule la mise à jour apporte une solution complète. Le choix d’une mesure doit tenir compte des fonctions réellement utilisées et de son effet sur la disponibilité.

L’alerte CERTFR-2026-ALE-014 décrit notamment la désactivation du suivi de progression des téléversements et le filtrage des requêtes multipart. Elle précise que ces contournements ne sont pas qualifiés et que la première mesure ne réduit la surface d’attaque que pour une des deux vulnérabilités. Cette alerte reprend encore la préannonce du 20 octobre : consultez aussi les avis PHP publiés avec les correctifs.

Avec l’exploitant, envisagez de restreindre temporairement l’accès aux services concernés ou d’isoler un environnement sans correctif disponible. Vérifiez les conséquences sur les formulaires et les transferts de fichiers. La présence d’un pare-feu applicatif ou l’absence de formulaire de téléversement ne suffit pas à conclure que le moteur est corrigé.

Comment appliquer le correctif sans perdre la maîtrise du site ?

Une mise à jour maîtrisée associe préparation, remplacement du moteur et vérification du service réellement exécuté. Voici une méthode proposée pour organiser l’intervention avec l’équipe qui exploite l’application.

1. Préparer la reprise. Vérifier les sauvegardes restaurables, les dépendances nécessaires et la procédure de retour arrière. Identifier les fonctions dont l’indisponibilité bloque l’activité.
2. Valider la cible. Choisir le paquet corrigé de la branche ou le correctif documenté du fournisseur. Tester la compatibilité dans un environnement séparé lorsque celui-ci existe.
3. Activer la correction. Installer le paquet et renouveler les processus PHP selon la procédure de l’hébergement. Une mise à jour présente sur disque ne prouve pas que les anciens processus ont quitté le service.
4. Relire l’état effectif. Contrôler à nouveau la version web, les pools concernés et les résultats des parcours retenus. Conserver les éléments avant et après intervention.

Notre accompagnement à l’intégration des innovations peut aussi aider à cadrer les dépendances entre une application, ses API et les usages IA qu’elle alimente.

Quels contrôles effectuer après la remise en service ?

Les contrôles doivent confirmer la correction et le fonctionnement des parcours utiles. Testez l’authentification, les sessions, les formulaires, les transferts de fichiers autorisés, les tâches planifiées et les échanges avec les applications reliées. Examinez les erreurs nouvelles et les processus encore actifs.

Conservez l’avis couvrant les deux CVE, la révision installée et les résultats des vérifications. La logique du registre de preuves en production aide à rendre ces décisions relisibles par une autre personne.

Si plusieurs sites sont concernés, notre récapitulatif des failles PHP d’octobre 2026 propose un suivi des priorités et des preuves par environnement.

Pour une application reliée à des agents IA, revoyez aussi les droits des connecteurs et les données accessibles, comme dans notre guide pour sécuriser les agents et leurs accès. Si des indices de compromission existent, ouvrez une investigation dédiée : la pose du correctif ne tranche pas ce qui s’est produit auparavant.

Comment Noolya intervient

Noolya intervient pour vérifier l’exposition et organiser la correction avec les responsables de l’hébergement et de l’application. Le périmètre peut comprendre l’identification du moteur web, l’examen du correctif fournisseur, 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. Les responsabilités et conditions d’accès sont définies au cadrage.

Commencez par le diagnostic faille PHP pour préparer les informations disponibles. Il s’agit d’une auto-évaluation déclarative, sans scan de votre site, qui ne constitue ni un test de sécurité ni une preuve de correction.

Noolya intervient : vérification et correction. Prenez rendez-vous avec Noolya pour définir un diagnostic détaillé et les vérifications adaptées à votre environnement.

Questions fréquentes

Mettre à jour WordPress suffit-il à corriger cette faille PHP ? La correction doit couvrir le moteur PHP qui sert WordPress. Une mise à jour du CMS ne prouve pas que ce moteur ou le paquet de l’hébergeur a reçu les deux correctifs.

PHP 8.4.26 est-il corrigé contre ces deux CVE ? La première version amont corrigée de la branche 8.4 est 8.4.27. Un paquet portant un numéro antérieur exige une preuve de rétroportage fournie par son distributeur.

Faut-il attendre un signalement d’exploitation active pour agir ? PHP demande une mise à jour immédiate des installations concernées. Les démonstrations techniques et le niveau de gravité publié justifient de préparer la correction sans attendre un constat d’attaque sur son propre site.

Un diagnostic déclaratif peut-il certifier que mon site est protégé ? Un questionnaire ne vérifie ni le paquet installé ni les processus qui traitent les requêtes. La conclusion exige des éléments techniques propres à l’environnement et une vérification après intervention.

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, 21 octobre 2026 ; disponibilité, périmètre et recommandations.

• RCE via OOM corruption : php/php-src ; CVE-2026-109618, conditions, versions et score CVSS 4.0.

• RCE via stale global state : php/php-src ; CVE-2026-109619 et distinctions entre modes d’exécution.

• PHP 8 ChangeLog : entrée 8.5.12 datée du 22 octobre, à distinguer des annonces du 21 octobre.

• Multiples vulnérabilités dans PHP : CERT-FR, alerte du 21 octobre fondée sur la préannonce ; limites des contournements.

• php_sapi_name : documentation PHP ; identification du mode d’exécution.

• phpinfo : documentation PHP ; nature des informations de configuration exposées.

• Supported Versions : PHP ; branches maintenues et limites du support amont.

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.