PHP publie des correctifs d'urgence pour deux failles CVSS 9.2 exploitables en une seule requête

PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont sorties le 21 octobre 2026 à 13h30 UTC, un jour après que le projet a annoncé une version de sécurité non programmée. Ces versions intègrent les correctifs de deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9.2 selon CVSS 4.0. Elles permettent une exécution de code à distance sans authentification, et du code de preuve de concept public a commencé à circuler dès la publication.

À lire aussi: WordPress corrige Comment2Shell, une faille dans les commentaires menant à la prise de contrôle du serveur · Check Point corrige deux failles VPN de gravité 9,8 permettant une exécution de code non authentifiée.

La plupart des failles qui touchent le web se nichent dans le code applicatif. Ces deux-là se nichent dans l'interpréteur. Un exploit démontré nécessite une seule requête d'un client anonyme, et il se déclenche avant qu'une ligne de WordPress ou de Drupal ne s'exécute. Un plugin corrigé et une règle de pare-feu applicatif bien réglée se situent tous deux en aval du point où l'attaque porte.

Deux façons de casser un worker

Les deux bugs sont sans rapport sur le plan du mécanisme et aboutissent au même endroit.

CVE-2026-109618, suivi sous GHSA-w8hw-w9fx-j79w, est une corruption de mémoire lors de la gestion d'un épuisement de mémoire. PHP applique memory_limit via longjmp(), qui peut interrompre une requête alors que les données internes de cette requête ne sont que partiellement initialisées. L'envoi d'un fichier multipart est l'exemple cité dans l'avis. Le chemin de nettoyage traite alors des données invalides comme valides et libère une mémoire jamais initialisée, qui peut encore contenir des octets contrôlés par l'attaquant, restes d'allocations antérieures. Résultat : une corruption de mémoire qu'un attaquant peut orienter vers l'exécution de code.

CVE-2026-109619, GHSA-6wmf-4rv5-p3rp, est un état global périmé. L'état interne d'une requête peut survivre après la libération de la mémoire qui le portait, une erreur fatale étant citée comme l'une des voies. Une requête ultérieure traitée par le même worker peut lire cet état périmé avant que l'initialisation normale ne l'écrase. Le worker n'a pas besoin de planter.

Cette dépendance à la réutilisation des workers explique pourquoi les conseils d'atténuation reviennent sans cesse aux redémarrages. Modifier un réglage dans php.ini ne touche pas un worker déjà en cours d'exécution avec l'ancienne configuration, pas plus que le remplacement du binaire sous-jacent. Il faut recycler le pool pour que l'un ou l'autre changement prenne effet.

Les deux bugs sont notés 9.2 et tous deux ont été signalés au projet PHP avant la publication, ce qui explique que les paquets des distributions et les fournisseurs de support à long terme disposaient de correctifs dès le premier jour. L'équipe PHP a aussi publié des rétroportages minimaux du code source pour PHP 7.4, 8.0 et 8.1, une solution provisoire pour des branches qui ne reçoivent plus de support officiel.

Quelles configurations serveur portent le risque

Toute installation PHP qui sert des requêtes web est concernée. Le projet PHP cite PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed, et classe mod_php comme la configuration la plus risquée des cinq. L'avis ne s'accompagnait d'aucune donnée d'exploitation par configuration : le classement est une évaluation du fournisseur, pas un taux d'exploitation mesuré.

Ce qui donne du poids au classement, c'est la base installée. W3Techs, cité par The Verge, situe PHP à 69,3 pour cent de tous les sites dont il peut identifier le langage côté serveur, un ensemble qui comprend Wikipédia et WordPress. Le scanner de VirusTotal recense environ 3,8 millions de sites faisant tourner PHP avec au moins un port ouvert. La télémétrie Cortex Xpanse d'Unit 42 a produit un chiffre plus élevé : plus de 22,6 millions d'instances exposées potentiellement vulnérables.

Aucun des deux chiffres ne compte des hôtes dont l'exploitabilité est confirmée. « Potentiellement vulnérable » couvre toute adresse faisant tourner une version de PHP antérieure au correctif, y compris les installations derrière un proxy qui bloque la forme de requête concernée et les hébergements mutualisés qui ont peut-être déjà corrigé l'interpréteur sans prévenir leurs clients.

The Verge a cité 4chan, DeviantArt, Wikipédia et le blog d'un bar local parmi les sites touchés. Kotaku a rapporté que Pokémon Home et Pokémon Champions avaient été mis hors ligne. Quelques agences gouvernementales néerlandaises et finlandaises ont retiré leurs sites par précaution, et Unit 42 a indiqué qu'au moins un gouvernement européen avait fait de même. Le directeur technique de Cloudflare, John Graham-Cumming, a déclaré à The Verge que l'entreprise « voyait émerger les premières attaques ».

Un bug vieux de 20 ans que l'IA a rendu praticable

Wiz Research, qui a découvert et signalé les vulnérabilités avec le projet PHP, affirme que le défaut sous-jacent était présent dans PHP depuis une vingtaine d'années.

Exploiter le bug « nécessitait une chaîne d'étapes exceptionnellement complexe, à la limite de ce que des chercheurs humains pouvaient accomplir en pratique ». — Wiz Research

Un bug peut dormir vingt ans dans une base de code sans devenir un incident de masse tant que le coût de construction d'un exploit fonctionnel reste au-dessus de ce que la plupart des attaquants acceptent de payer. Wiz attribue le changement aux modèles d'IA, qui ont rendu beaucoup plus facile la transformation d'un défaut obscur de gestion de mémoire en chaîne fonctionnelle. Google, propriétaire de Wiz, a publié son récit le 21 octobre. OpenAI a indiqué de son côté qu'un groupe de sécurité IA nommé Calif avait identifié une faille PHP critique à l'aide de GPT-5.6 Sol.

Deux organisations recourant à la recherche assistée par IA sont arrivées au même défaut au niveau de l'interpréteur, et le projet PHP et Wiz ont communiqué ensemble. C'est un cas, et un cas ne tranche pas la question de savoir combien l'IA déplace l'équilibre entre attaquants et défenseurs.

Ce que corriger implique au-delà du numéro de version

Pour la plupart des sites, le travail consiste en une mise à jour de l'interpréteur suivie d'un redémarrage, et c'est au redémarrage que l'hébergement mutualisé se complique. Les workers PHP-FPM de longue durée continuent de servir avec l'ancien binaire jusqu'à ce que chacun soit recyclé. Les conteneurs construits sur une ancienne image de base restent vulnérables jusqu'à ce que l'image soit reconstruite et redéployée. Un panneau d'administration qui affiche PHP 8.3 ne prouve pas que le pool fait tourner la 8.3.36 corrigée.

GoDaddy affirme que tout site utilisant PHP doit se considérer comme touché, et cela vaut aussi pour les installations WordPress, Drupal, Joomla et Magento, car aucune de ces plateformes n'embarque son propre interpréteur. Mettre à jour un plugin ou un thème modifie des fichiers dans le répertoire de l'application. Cela ne touche pas au binaire qui analyse la requête.

Deux lacunes de support allongent la traîne. PHP 8.1 et les versions antérieures sont en fin de vie et n'auront aucune compilation officielle : quiconque reste en 8.0 ou 7.4 doit migrer ou accepter un rétroportage du fournisseur. Et le dépôt remi, source courante de paquets PHP récents sur les systèmes dérivés de Red Hat, n'aurait pas de mises à jour le jour de la publication. Le conseil de l'équipe PHP était de passer aux paquets de la distribution ou de compiler depuis les sources.

Que faire pendant que la reconstruction attend

L'avis 2026-018 du CERT-EU énonce clairement la priorité : « le CERT-EU conseille aux organisations de corriger immédiatement les actifs touchés ». S'il n'est pas possible de corriger, il recommande d'isoler les applications exposées à internet des réseaux publics jusqu'à ce qu'un correctif soit appliqué et vérifié. Le compte de cybersécurité de la NSA sur X et le NCSC britannique ont donné des conseils similaires : mettre les systèmes hors ligne si une mise à jour immédiate n'est pas possible.

Pour les organisations qui ne peuvent pas aller aussi vite, le CERT-EU énumère des mesures temporaires. Elles réduisent l'exposition sans fermer la brèche.

• Pour CVE-2026-109618 : définir memory_limit=-1 d'une manière que les applications ne peuvent pas contourner, par exemple avec php_admin_value dans le pool FPM ou la configuration Apache. Abaisser post_max_size à 8M sans envois de fichiers et à 32M avec. Imposer des limites de taille de requête, de champs et de parties au niveau du proxy, et utiliser une limite de mémoire de conteneur ou de cgroup.
• Pour CVE-2026-109619 : définir session.upload_progress.enabled=0 et redémarrer tous les workers. Sur PHP 8.5, définir fatal_error_backtraces=0 et redémarrer. Supprimer les réglages invalides par requête qui émettent des diagnostics avant l'initialisation, et corriger les erreurs fatales et les délais d'attente accessibles depuis l'extérieur.
• Pour les deux : corriger, puis redémarrer. Un binaire à jour sur le disque avec des workers qui font encore tourner l'ancien n'est pas un correctif.

Ce que les chiffres ne prouvent pas

Les 22,6 millions et les 3,8 millions sont des estimations d'exposition tirées de télémétrie de fournisseurs et d'une enquête. Aucune ne compte les hôtes qui font tourner du code qu'un attaquant peut atteindre.

Tous les sites sous PHP ne sont pas exploitables par la même technique. Les bugs vivent dans des sous-systèmes différents, et la forme de requête qui déclenche l'un peut ne pas fonctionner contre une SAPI donnée ou un jeu d'options donné.

Aucune compromission de masse confirmée ni attribution d'attaquant n'avait été publiée au moment d'écrire ces lignes. Les récits de sites mis hors ligne décrivent des mesures de précaution autant que des incidents, et les deux sont faciles à confondre à ce stade. L'absence de compromission de masse publiée ne prouve pas qu'il n'y en a pas eu, seulement qu'aucune constatation de ce type n'avait été rendue publique le 21 octobre.

Ce qu'il faut surveiller

Le premier signal est de savoir si le code de preuve de concept devient un exploit prêt à l'emploi. Une chaîne fonctionnelle entre les mains du public abaisse le niveau de compétence nécessaire pour l'utiliser, et la base installée de PHP offre à quiconque scanne un ensemble de cibles inhabituellement vaste. Unit 42 a indiqué qu'un premier code de preuve de concept circulait et que l'exploitation était probable.

Le second est la traîne des versions en fin de vie. PHP 8.1 a cessé de recevoir des correctifs officiels, et 7.4 et 8.0 sont plus loin encore. Chaque site resté sur ces branches dépend d'un mainteneur de distribution ou d'un hébergeur pour rétroporter un correctif de corruption de mémoire, et son arrivée dépend du fournisseur.

Puis il y a le versant recherche. Si le travail assisté par IA continue de produire des bugs au niveau de l'interpréteur à ce rythme, l'écart entre la publication d'un correctif par un projet et son application par la longue traîne de serveurs non corrigés devient le chiffre qui compte, pas le score CVSS.

Pour l'instant, la séquence est courte. Corriger l'interpréteur, redémarrer chaque worker, confirmer la version en cours d'exécution et traiter les estimations d'exposition comme une raison de se hâter, pas comme une mesure. Les sites qui n'y parviennent pas aujourd'hui devraient sortir de l'internet public, ce que plusieurs opérateurs ont déjà choisi.

Image de couverture : « Custom-software-developement-php-net » de Ron23545, CC BY-SA 4.0, via Wikimedia Commons.