PHP 8.5.12 et 8.4.27 corrigent deux failles RCE critiques

PHP a publié les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 le 21 octobre 2026 pour corriger deux failles critiques. Toutes deux peuvent permettre à un attaquant d'exécuter du code sur un serveur web sans se connecter. L'avis de sécurité de PHP.net demande à tous les utilisateurs de PHP de mettre à jour immédiatement. Il ajoute qu'aucune modification de configuration ne protège entièrement un serveur. Installer la nouvelle version est donc le seul choix sûr.

PHP avait annoncé cette version hors calendrier la veille, après la fuite anticipée de détails sur les bugs. Nous avons couvert cette annonce préalable ce matin. La version publiée aujourd'hui répond aux questions en suspens : quelles versions sont corrigées, ce que font les bugs et qui est le plus exposé.

Ce que font les deux failles de PHP

Les deux bugs se trouvent dans le code qui prépare puis nettoie chaque requête web. PHP attribue à chacun une note de 9.2 selon CVSS v4.0, l'échelle de gravité standard de 0 à 10. Il précise que les deux « peuvent permettre une exécution de code à distance non authentifiée ». Non authentifiée signifie que l'attaquant n'a besoin ni de compte ni de mot de passe.

CVE	Avis GitHub	Ce qui ne va pas
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Un manque de mémoire peut arrêter PHP au milieu de la préparation d'une requête. Le code de nettoyage peut alors traiter les données à moitié construites comme valides.
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Certaines données de requête peuvent survivre à la mémoire qui les porte. La requête suivante sur le même processus worker peut alors utiliser ces données périmées en premier.

Un processus worker est l'une des copies de PHP à longue durée de vie qu'un serveur web garde actives pour répondre aux requêtes. Réutiliser les workers est normal et rapide. C'est pourquoi les données laissées par une requête comptent pour la suivante.

Qui est exposé

Selon l'avis de PHP, toute installation qui sert des requêtes web peut être concernée. Cela inclut PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. PHP considère mod_php, le module qui exécute PHP à l'intérieur d'Apache lui-même, comme le plus à risque. L'avis décrit un « exploit démontré » où une seule requête non authentifiée déclenche l'attaque avant l'exécution de tout code applicatif.

Ce détail compte pour tous ceux qui s'appuient sur des défenses au niveau de l'application. Une règle de pare-feu dans WordPress ou dans un framework n'a jamais l'occasion de s'exécuter.

L'avis de PHP ne signale pas d'attaques en conditions réelles. D'autres rapports sont moins tranchés. Selon TechStartups, le directeur technique de Cloudflare a observé les premiers signes d'attaques, même si leur ampleur reste floue. TechStartups cite aussi Benjamin Harris, directeur général de watchTowr, qui a déclaré à BleepingComputer que les deux bugs sont « CVSS10 ». C'est plus que la note de 9.2 attribuée par PHP lui-même. Gulf News, citant Reuters, rapporte que des sites gouvernementaux en Europe et ailleurs ont été mis hors ligne mercredi après la divulgation. Le média ne dit pas si des attaques ont causé ces pannes.

Amazon a ensuite indiqué que ses honeypots MadPot avaient enregistré une tentative d'exploitation dès le 17 octobre, quatre jours avant cette version, comme l'explique Amazon a vu des tentatives d'attaque PHP2Shell quatre jours avant la divulgation.

Quelles versions de PHP installer

Branche	Version corrigée	Remarques
PHP 8.5	8.5.12	Corrigée
PHP 8.4	8.4.27	Corrigée
PHP 8.3	8.3.36	Corrigée
PHP 8.2	8.2.35	Corrigée ; la branche arrive en fin de vie le 31 décembre 2026
PHP 8.1, 8.0, 7.4	Aucune	Correctifs source minimaux uniquement, sur des branches nommées PHP-8.1-CVE-2026-109618-109619 et similaires
Antérieure à 7.4	Aucune	Aucun correctif de PHP

Les correctifs source pour 7.4, 8.0 et 8.1 ne sont pas des versions empaquetées. Quelqu'un doit les compiler. Gulf News note que certains éditeurs pourraient rétroporter les correctifs vers des versions plus anciennes qu'ils prennent encore en charge.

PHP liste aussi des atténuations partielles, dont la désactivation de session.upload_progress.enabled et des limites plus strictes sur la taille des requêtes. L'avis dit sans détour qu'elles « ne rendent pas une installation sûre ». Elles ne font que restreindre l'attaque pendant le déploiement d'une vraie mise à jour.

Ce que cela signifie pour les développeurs

Corrigez aujourd'hui, et corrigez aussi les endroits que vous oubliez. Le serveur évident est rarement la seule copie de PHP qu'une organisation fait tourner.

• Vérifiez chaque environnement d'exécution, pas seulement le site principal. Lancez php -v sur chaque hôte. Vérifiez ensuite les images de base des conteneurs, les runners de CI, les machines de préproduction et les outils internes. Une image Docker figée sur un ancien tag garde le bug jusqu'à ce que quelqu'un la reconstruise.
• Redémarrez après la mise à jour. PHP-FPM et Apache maintiennent des processus workers en vie. Un nouveau paquet sur le disque ne change rien tant que ces workers n'ont pas redémarré. Vérifiez donc ensuite la version en cours d'exécution.
• Traitez d'abord les hôtes mod_php. PHP désigne cette configuration comme la plus risquée, avec un exploit qui se déclenche avant que votre code ne s'exécute. Si vous ne pouvez pas mettre à jour un serveur mod_php aujourd'hui, envisagez de le mettre hors ligne jusqu'à ce que ce soit possible.
• Traitez PHP 8.1 et antérieur comme une mise à niveau d'urgence. Aucune version officielle n'arrivera. Les correctifs source font gagner du temps, mais seulement si quelqu'un les compile et les maintient. Demandez à votre hébergeur ou à votre distribution Linux s'il fournit un rétroportage.
• Anticipez la fin de vie de PHP 8.2. La branche 8.2 cesse de recevoir des correctifs de sécurité le 31 décembre 2026. Passer à 8.4 ou 8.5 dès maintenant évite une deuxième course contre la montre en fin d'année.
• Surveillez les journaux. Les signalements d'attaques précoces ne sont pas confirmés, mais les détails sont désormais publics. Des plantages inhabituels ou des erreurs de mémoire insuffisante dans les workers PHP méritent un examen attentif.