Bug Longjmp de PHP: intérieur CVE-2026-109618 et CVE-2026-109619

Le 21 octobre 2026, le National Cyber Security Centre du Royaume-Uni a émis une alerte qui est, de toute façon, inhabituellement émoussée : un problème critique en PHP peut permettre aux attaquants d'exécuter des commandes sur any serveur web exécutant PHP. Les deux CVE derrière lui — CVE-2026-109618 et CVE-2026-109619 — sont notés 9.2 sous CVSS 4.0, sont des défauts d'exécution de code à distance et ont un code de preuve de concept en circulation. Si votre domaine touche l'internet public, il ya une très bonne chance PHP est quelque part dans le rayon d'explosion.

Pourquoi celui-ci est différent

Les vulnérabilités de PHP sont de routine. Un bug de désérialisation dans un framework, un chemin traversant dans un plugin, une injection SQL dans un CMS — ce sont le pain et le beurre de la gestion de la vulnérabilité, et ils sont presque toujours projetés dans une application particulière, un module particulier, ou une configuration particulière. CVE-2026-109618 et CVE-2026-109619 ne sont pas cela. Ils vivent dans l'interprète lui-même, dans la machine PHP utilise pour gérer les erreurs fatales et les conditions hors de mémoire. Cela signifie que l'exposition n'est pas définie par l'application que vous exécutez, mais par le fait que vous exécutez PHP du tout.

Cette distinction compte énormément pour la façon dont vous réagissez. Lorsqu'un plugin CMS est vulnérable, vous corrigez le plugin ou le désactivez. Lorsque le runtime est vulnérable, chaque application sur ce runtime hérite de la faille — le portail client, le wiki interne, le microsite marketing oublié à partir de 2019, l'appareil vendeur qui regroupe discrètement une pile PHP que personne n'a documenté. La ligne directrice du CNSC reflète exactement ceci : identifier les installations PHP généralement, pas seulement celles dépassées.

Note: Le NCSC indique explicitement que les organisations utilisant any version de PHP sont affectées et doivent mettre à jour à la dernière version fixe. Ne présumez pas qu'une version récente est sécuritaire jusqu'à ce que l'avis du fournisseur confirme la présence de la correction.

Anatomie des deux failles

Les deux vulnérabilités remontent à longjmp(), le mécanisme de la bibliothèque C PHP utilise pour décompresser la pile lorsqu'une erreur fatale ou une condition hors mémoire se produit. En fonctionnement normal, il s'agit d'un sauvetage contrôlé : quelque chose va mal, l'interprète revient à un point de sécurité connu, et la demande est ravagée proprement. Les bogues surgissent lorsque ce renflouement se produit précisément au mauvais moment, laissant l'état interne incohérent.

CVE-2026-109618: initialisation interrompue

Le premier défaut est un problème de gestion des flux de contrôle. Lorsqu'une condition hors mémoire déclenche longjmp() alors que les données des requêtes internes ne sont que partiellement initialisées, le chemin de nettoyage peut traiter la mémoire non initiale comme si elle était valide. Le résultat est la corruption de la mémoire. Parce que l'attaquant contrôle le déclencheur — une condition OOM est quelque chose que vous pouvez provoquer avec une requête artisanale — Unité 42 décrit l'exploitation comme reliable, ce qui est un mot défenseurs devrait prendre au sérieux. Un RCE fiable signifie que la barrière entre un chercheur curieux et un exploit de travail est faible.

CVE-2026-109619: état qui survive à sa mémoire

Le second défaut est plus subtil et, à certains égards, plus insidieux. Ici, l'état interne de la demande peut survivre après que la mémoire a été libérée. PHP workers — les processus qui gèrent les requêtes, en particulier sous des modèles persistants comme PHP-FPM — puis récupérer la requête suivante et peut utiliser cet état statique avant l'initialisation normale la réinitialise. En effet, une demande peut laisser un héritage empoisonné pour la suivante traitée par le même travailleur. Ces régions libérées peuvent plus tard être lues ou ramifiées, et avec un contrôle suffisant sur la mise en page du tas, qui devient un chemin vers l'exécution arbitraire du code.

Les deux sont non authentifiés. Il n'y a pas de connexion à contourner car il n'y a rien à connecter à — la surface d'attaque est la requête elle-même, avant que votre code d'application ait son mot à dire. C'est ce qui pousse le score à 9,2 et ce qui rend la langue du CNSC si directe.

L'échelle d'exposition

La télémétrie Cortex Xpanse de Palo Alto Networks a identifié plus de 22,6 millions d'instances exposées potentiellement vulnérables à ces CVE. Ce chiffre compte les services face à Internet où l'empreinte digitale suggère un temps d'exécution PHP vulnérable, et c'est presque certainement un sous-compte une fois que vous comptez dans les appareils, les interfaces de gestion intégrées, et les systèmes internes qui sont accessibles à partir d'un poste de travail compromis. L'unité 42 signale également qu'au moins un gouvernement européen a pris son site Web hors ligne à titre de précaution — une décision qui vous indique à quel point la preuve de concept a été prise au sérieux par les personnes qui l'avaient vu.

Pour un défenseur, la question inconfortable n'est pas "est-ce que nous courons PHP?" mais "où ne savons-nous pas que nous courons PHP?" Systèmes de gestion de contenu, plates-formes de billetterie, front-ends CRM, tableaux de bord de surveillance, appareils réseau avec interfaces web, serveurs de construction, et des images de base de conteneurs sont régulièrement expédiés avec un interprète PHP en dessous. L'inventaire NCSC-NL de produits logiciels avec une dépendance PHP est un point de départ utile précisément parce qu'il capture cette exposition de deuxième ordre.

Attention: Une erreur courante dans les 48 premières heures d'une vulnérabilité comme celle-ci est de scanner seulement pour la chaîne de version rapportée par les gestionnaires de paquets. Les appareils et les piles groupées expédient souvent des builds PHP patchés ou personnalisés qui n'annoncent pas leur véritable niveau de patch. Traiter la détection de version comme un indice, et non comme un verdict.

Que faire, par ordre de priorité

Les actions prioritaires du CNSC méritent d'être suivies de près, parce qu'elles sont séquencées de façon sensée pour un incident de cette forme.

• Découvrez PHP partout, face à Internet d'abord. Ne pas filtrer par version. Énumérer les installations d'interprètes à travers les serveurs, les conteneurs et les appareils, puis classer par accessibilité externe.
• Patch à la dernière version PHP fixe. Le projet PHP a publié la mise à jour de sécurité, l'applique et continue de suivre les futures versions. Si vous êtes sur une branche de fin de vie, passez à une version entièrement prise en charge plutôt qu'à la rétroportation.
• Regardez les fournisseurs tiers. Les appareils et services qui regroupent PHP ont besoin de leurs propres mises à jour. Surveiller les avis aux fournisseurs en continu, pas une fois.
• Appliquez les directives de durcissement de l'équipe PHP en plus du patch — défense en profondeur contre le prochain défaut d'interprète.
• Si vous ne pouvez pas corriger immédiatement, appliquer les mesures d'atténuation temporaires publiées par l'équipe PHP. Si celles-ci sont peu pratiques ou trop lentes, prenez le système hors ligne.
• Si vous ne pouvez pas mettre à jour ou désactiver un système, évaluez-le pour la preuve de compromis et pour les portes arrière installées par l'attaquant avant vous mettez à niveau. La mise en place d'une intrusion n'enlève pas l'intrus.

Ce dernier point mérite d'être souligné. Il s'agit de défauts non authentifiés du RCE avec preuve publique de concept. La fenêtre entre la divulgation et l'exploitation est mesurée en heures, pas en semaines, et un travailleur PHP compromis est un excellent endroit pour cacher — l'attaquant hérite des privilèges du serveur Web, de ses identifiants de base de données, et de sa position réseau sortant. Si un système a été exposé et n'a pas été répertorié pendant une période significative, prendre des compromis jusqu'à ce que vous puissiez démontrer le contraire, et faire appel à un fournisseur d'intervention en cas d'incident assuré par le CNSC si vous n'avez pas la capacité interne de le faire de façon médico-légale.

Détection et vérification

Du point de vue des tests, le défi pratique avec les bugs de niveau interprète est qu'ils laissent peu d'empreintes digitales dans les journaux d'application. La requête qui déclenche un OOM ne ressemble pas à une attaque à votre WAF — il ressemble à un grand téléchargement, un régex pathologique, un corps JSON profondément niché, ou une requête qui demande simplement trop. L'exploitation se produit sous la couche que vous voyez.

Cela signifie que la détection doit s'appuyer sur les signaux d'infrastructure : les travailleurs inattendus s'écrasent et redémarrent, la pression de mémoire anormale sur les pools PHP-FPM, les dumps de noyau apparaissant là où ils ne devraient pas, et les connexions sortant des serveurs Web vers des destinations inconnues. Du côté de la prévention, le patching virtuel par le biais des contrôles de sécurité réseau peut acheter du temps — Le programme Advanced Threat Prevention Plus de Palo Alto avec Frontier Virtual Patching couvre ces CVE par signature 543004 depuis le 20 octobre 2026 — mais le patching virtuel est un pont, pas une destination. L'interprète a encore besoin de la correction réelle.

Si vous voulez valider votre propre exposition avant qu'un attaquant ne le fasse, l'approche honnête consiste à tester l'exécution directement : confirmer le niveau de patch de chaque interprète que vous trouvez, exercer l'OMO et les trajectoires fatales-erreur dans un environnement contrôlé, et vérifier que l'état du travailleur ne fuit pas entre les demandes. C'est précisément le genre d'évaluation au niveau de l'exécution que le balayage de la couche d'application a tendance à manquer, et c'est là qu'un test de pénétration ciblé gagne son maintien sur une vulnérabilité de cette classe.

La plus grande leçon

Ce qui rend CVE-2026-109618 et CVE-2026-109619 remarquable n'est pas que PHP avait un bug de sécurité de mémoire — chaque grande base de code C finit par le faire. C'est le rappel que l'interprète fait partie de votre surface d'attaque, et c'est la partie que la plupart des organisations stockent le moins soigneusement. Nous avons tendance à connaître nos applications intimement et nos runtimes à peine du tout. Quand un défaut atterrit dans l'écoulement, cette asymétrie devient la vulnérabilité.

Ce sont les organisations qui ont déjà eu une réponse fiable à "où fonctionne PHP, et à quelle version?" — et qui ont traité la réponse comme un inventaire vivant plutôt qu'un tableur unique. Si vous n'avez pas eu cette réponse le 21 octobre, construire maintenant est la chose la plus précieuse que vous pouvez faire cette semaine, avant la prochaine faille de l'interprète qui suivra inévitablement.