Les deux failles critiques de PHP déjà visées par des attaques

Les serveurs web qui n’ont pas encore reçu PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 sont désormais des cibles : le jour même de la sortie de ces correctifs, mercredi 21 octobre, Amazon a écrit que les deux failles qu’ils ferment étaient « désormais largement exploitées ». Ces failles permettent à un inconnu, sans identifiant, de faire exécuter son propre programme par un serveur qui fait tourner PHP pour afficher des pages web, avant même que le site ne s’exécute.

Le projet PHP avait publié ses correctifs le jour fixé la veille par une pré-annonce, qui promettait la sortie pour 14 h UTC (16 h à Paris). Son équipe de sécurité y décrit « deux vulnérabilités critiques qui peuvent permettre une exécution de code à distance sans authentification » et demande à « tous les utilisateurs de PHP » de mettre à jour « immédiatement ». L’enjeu est large : selon W3Techs, PHP équipe 69,3 % des sites web dont le langage côté serveur est identifiable, à commencer par ceux qui reposent sur WordPress, dont l’éditeur recommande « PHP version 8.3 ou plus ».

Une première tentative quatre jours avant les correctifs

Amazon surveille les attaques grâce à MadPot, son réseau de pots de miel (de faux serveurs vulnérables, installés comme appâts pour observer les attaquants). Dans un billet signé par CJ Moses, son équipe de renseignement sur les menaces date du 17 octobre une première tentative d’exploitation, « quatre jours avant la divulgation publique ». Elle venait d’une adresse IP liée à un réseau commercial d’anonymisation ; viser un pot de miel depuis une telle adresse alors que la faille était encore sous embargo (le délai de silence convenu entre chercheurs, projet et distributions avant la publication) « suggère » selon Amazon l’œuvre d’un attaquant.

La suite s’est accélérée dans la nuit du 20 au 21 octobre. Amazon a repéré plusieurs preuves de concept (des programmes qui démontrent l’attaque), « la plus ancienne vers 2 h UTC » le 21 octobre (4 h à Paris), soit douze heures avant la levée de l’embargo, qu’il situe à 14 h UTC. Entre 2 h et 8 h UTC, d’autres tentatives ont visé ses pots de miel depuis d’autres infrastructures anonymisées, avec des charges et des réseaux différents, ce qui suggère selon l’entreprise « plusieurs acteurs ». Le billet ne chiffre ni le nombre d’attaques ni celui de serveurs compromis. Les requêtes qu’Amazon conseille de rechercher passent par le suivi de progression des envois de fichiers, l’un des chemins de la seconde faille décrits plus bas.

Cloudflare parle d’une fuite : la faille « a fuité avant la date officielle de publication », écrit l’entreprise, qui dit avoir observé « du trafic d’attaque visant [ses] clients » et des attaquants qui modifiaient leurs requêtes pour contourner ses filtres. Son pare-feu applicatif (le filtre qui inspecte les requêtes avant qu’elles n’atteignent le site) bloque ces attaques par défaut depuis le 21 octobre à 3 h 02 UTC, y compris pour les comptes gratuits ; Cloudflare demande malgré tout à ses clients de corriger PHP. Le CERT-EU, l’équipe de cybersécurité des institutions européennes, note de son côté dans son avis du 21 octobre que « les premières preuves de concept ont commencé à circuler ».

Les deux failles ont désormais un nom, « PHP2Shell », donné par ceux qui les ont trouvées. Selon leur compte rendu, Ryan Austin, de la société de sécurité Calif, a mené la recherche en collaboration avec OpenAI et Wiz, et signalé la première faille au projet PHP le 11 août, la seconde le 21 août ; une démonstration d’exécution de code a été transmise le 14 août et confirmée par PHP le lendemain. Calif dit avoir obtenu une exécution de code sans connexion préalable sur WordPress, Drupal, Joomla, MediaWiki, Roundcube, Magento, phpMyAdmin, Nextcloud, Laravel, Symfony et WHMCS, et fait remonter le problème à PHP 5.4. Calif montre des vidéos de démonstration, sans publier de code d’attaque.

Le CERT-FR a émis le 21 octobre, en plus de son avis, une alerte dans laquelle il recommande « d’isoler les équipements affectés » puis de migrer vers une version corrigée ; elle ne fait pas état d’exploitation. Jeudi 22 octobre au matin, les deux avis du projet PHP et sa page d’annonce n’avaient pas été complétés, et l’agence américaine de cybersécurité CISA n’avait pas inscrit les deux failles à son catalogue des failles exploitées (dernière version datée du 21 octobre à 14 h 04 UTC).

Deux pannes de mémoire transformées en porte d’entrée

Les deux failles ont la même origine : la façon dont PHP range, puis nettoie, la mémoire qu’il consacre à chaque requête (chaque page demandée par un navigateur). Toutes deux sont notées 9,2 sur 10 sur le barème public de gravité CVSS.

CVE-2026-109618, « RCE via OOM corruption » (exécution de code à distance par corruption de la mémoire lors d’un manque de mémoire ; avis GHSA-w8hw-w9fx-j79w). Quand PHP dépasse la mémoire qui lui est allouée (le paramètre memory_limit) pendant qu’il prépare une requête, il interrompt brutalement son travail. L’avis explique que PHP « ne tient pas correctement compte de cette sortie anticipée et laisse la mémoire de la requête dans un état invalide » ; le nettoyage qui suit traite alors ces données à moitié construites comme valides. Un attaquant peut provoquer ce manque de mémoire à distance avec un envoi de formulaire fabriqué : requête sans taille déclarée qui échappe à la limite post_max_size, en-têtes en nombre illimité dans les parties d’un envoi de fichiers, champs de fichier vides qui contournent max_file_uploads. Selon l’avis, « l’exécution complète de code à distance a été validée par HTTP contre mod_php avec les limites d’entrée et de mémoire par défaut de PHP ».

CVE-2026-109619, « RCE via stale global state » (exécution de code à distance par un état global périmé ; avis GHSA-6wmf-4rv5-p3rp). Un serveur PHP traite les requêtes à la chaîne avec des processus réutilisés (les « workers »). Si une erreur fatale ou un manque de mémoire interrompt le nettoyage, un de ces processus peut garder un pointeur vers la mémoire d’une requête déjà terminée et libérée ; la requête suivante s’en sert avant que l’initialisation normale ne la remette à zéro. C’est ce que les spécialistes appellent une « utilisation après libération ». Deux chemins sont confirmés : le suivi de progression des envois de fichiers dans les sessions, qui, note l’avis, « est activé par défaut » et ne demande aucun appel de l’application ; et, en PHP 8.5 seulement, les traces d’appels enregistrées lors des erreurs fatales. L’impact confirmé : fuite de mémoire et exécution de code « avec les privilèges du worker web », sans authentification.

Le vecteur CVSS des deux avis précise une complexité d’attaque « élevée » et des conditions préalables à réunir. Les avis créditent quatre signaleurs sous leurs pseudonymes GitHub.

Apache avec mod_php en première ligne

PHP s’exécute de plusieurs façons derrière un serveur web, et toutes ne sont pas exposées de la même manière. Php.net cite « toutes les installations de PHP qui servent des requêtes web » : PHP-FPM (un gestionnaire de processus PHP séparé, souvent associé à Nginx), mod_php (le module qui intègre PHP directement dans le serveur Apache), php-cgi, FrankenPHP et LiteSpeed. Les avis détaillent :

• Apache avec mod_php : le cas le plus grave pour le projet, qui y a démontré une attaque où une requête anonyme agit « avant

que le moindre code de l’application ne s’exécute ». Les deux failles s’y appliquent.

• PHP-FPM : pour la première faille, FPM arrête le processus quand le démarrage de la requête échoue ; l’analyse du code le

désigne comme vulnérable, mais « aucune exploitation complète de FPM n’a été démontrée ». Pour la seconde, l’exécution de code a été validée sur FPM comme sur mod_php, par un chemin qui passe par une erreur fatale pendant l’exécution de l’application ; FPM est aussi exposé si le serveur placé devant lui (Nginx, Apache) lui transmet des réglages PHP par requête qui produisent un message d’erreur avant l’initialisation.

• FrankenPHP : « probablement vulnérable » à la première faille, comme mod_php, selon l’analyse du code ; pour la seconde, le

chemin d’attaque n’a pas été établi dans sa configuration par défaut.

• LiteSpeed (LSAPI) : candidat « conditionnel » pour les deux, avec des attaques propres à certaines applications jugées

« probables mais non validées ».

Les versions touchées sont toutes celles des branches 8.2 à 8.5 antérieures aux correctifs. Le CERT-FR, qui a publié son avis le jour même, y ajoute toutes les versions 7.x, 8.0 et 8.1, et les plus anciennes.

Ce qu’il faut faire, selon votre installation

Site sur un hébergement mutualisé. Le client ne gère pas PHP lui-même : c’est à l’hébergeur d’appliquer le correctif. Le geste utile est de vérifier dans le panneau de gestion la version de PHP choisie pour le site et, si elle date (8.1 ou avant), de passer à une branche suivie. Nous n’avions lu aucune communication d’hébergeur sur ces failles mercredi vers 17 h.

Serveur géré soi-même avec les paquets de la distribution. Php.net indique que les distributions Linux et les fournisseurs de support long « ont reçu les correctifs à l’avance ». Mercredi vers 17 h, Ubuntu avait publié son bulletin USN-8948-1 pour les versions 22.04, 24.04, 26.04 et 26.10, et Debian son DSA-6574-1 pour php8.4 dans Debian 13 « trixie » (version 8.4.27-1~deb13u1). Debian 12 « bookworm », passée en support à long terme, a reçu le même jour son correctif pour php8.2 (version 8.2.35-1~deb12u1, avis DLA 4848-1). Red Hat a publié le 21 octobre l’avis RHSA-2026:87080 pour le module php 7.4 de RHEL 8 ; jeudi matin, ses fiches publiques ne permettaient pas d’établir lesquelles de ses autres versions de PHP étaient déjà corrigées. Après la mise à jour, il faut s’assurer que les processus PHP (Apache, PHP-FPM) ont bien été relancés : un processus déjà en mémoire garde l’ancien code.

Dépôt de Remi Collet (Fedora, Red Hat et dérivés). Php.net prévient que ce dépôt tenu par un bénévole, rpms.remirepo.net, « n’aura pas de mises à jour aujourd’hui », et conseille de revenir aux paquets de la distribution ou de compiler PHP soi-même.

Image Docker officielle. Le dépôt qui construit l’image php de Docker Hub a intégré mercredi la modification « [security] Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35 » (historique). Il faut retélécharger l’image, reconstruire ses propres images qui en dérivent et relancer les conteneurs, puis contrôler la version avec php -v.

Logiciel ou appareil qui embarque PHP. Le centre national néerlandais de cybersécurité (NCSC-NL) tient sur GitHub une liste de produits qui reposent sur PHP, avec l’état connu de leurs correctifs, à côté de conseils de détection.

PHP 8.1 ou plus ancien. Ces branches ne reçoivent plus rien du projet (8.1 est arrivée en fin de vie le 31 décembre 2025, selon php.net). Vu la gravité, l’équipe de sécurité a toutefois publié des correctifs minimaux, à appliquer au code source, pour PHP 7.4, 8.0 et 8.1. Certaines distributions corrigent aussi leurs anciennes versions : Ubuntu 22.04 reçoit un php8.1 corrigé dans le même bulletin. La question n’est pas marginale : d’après les chiffres de W3Techs, nous estimons qu’environ un site PHP sur deux annonce une branche que le projet ne suit plus (7.x, 8.0, 8.1 ou plus ancienne). Le chiffre est approximatif : beaucoup de serveurs masquent leur version, et un « 8.1 » de distribution peut avoir été corrigé.

Si la mise à jour doit attendre

Php.net insiste : seule la mise à jour est une « solution complète », et les annonces de version répètent qu’il n’existe « pas de parade complète ». Avec des attaques en cours, l’attente se compte en heures, pas en jours. L’avis liste des réglages qui ferment certains chemins d’attaque, sans rendre le serveur sûr :

• contre la seconde faille, désactiver le suivi de progression des envois (session.upload_progress.enabled=0) dans php.ini ou la

configuration du serveur, puis redémarrer tous les processus PHP ; en PHP 8.5, désactiver aussi fatal_error_backtraces. Le réglage par l’application (ini_set()) ou par un fichier .user.ini ne suffit pas, précise l’avis. C’est sur ce mécanisme que portent les requêtes qu’Amazon conseille de rechercher dans les journaux ;

• contre la première, retirer la limite de mémoire de PHP (memory_limit=-1) au niveau du serveur, pour que l’application

ne puisse pas la rétablir, et réduire la taille maximale des envois (post_max_size à 8 Mo sans envoi de fichiers, 32 Mo sinon), idéalement en filtrant aussi la taille et la forme des requêtes au niveau du serveur web ; la mémoire reste alors bornée par le conteneur ou le système.

Retirer la limite de mémoire a un coût : un script gourmand peut alors consommer celle de toute la machine, d’où le conseil de php.net de s’appuyer sur la limite du conteneur. Amazon suggère en outre de bloquer provisoirement les envois de fichiers en plusieurs parties (le format des formulaires d’envoi), là où le site peut s’en passer. Le CERT-FR, dans son alerte, préconise les mêmes parades d’attente (désactiver le suivi de progression des envois, ou bloquer les requêtes en plusieurs parties) et recommande d’isoler les équipements affectés ; le CERT-EU, quand la mise à jour immédiate est impossible, conseille d’« envisager d’isoler » des réseaux publics les applications exposées à Internet jusqu’à ce que le correctif soit appliqué et vérifié. Ce sont des gestes d’administrateur ; un client d’hébergement mutualisé n’y a en général pas accès.

Chercher une intrusion déjà passée

La première tentative datant du 17 octobre, corriger aujourd’hui ne dit pas si un serveur a été visité avant. « Avec PHP2Shell, la compromission peut précéder l’avis », prévient Amazon, qui conseille de chercher dans les journaux du serveur web les requêtes POST contenant la chaîne PHP_SESSION_UPLOAD_PROGRESS dans des envois de formulaires, puis de vérifier l’absence de processus lancés ou de fichiers modifiés de façon inattendue. Une requête de ce type dans les journaux signale une tentative, pas forcément une intrusion réussie.

Un délai plus court qu’en 2024

L’annonce de mardi 20 octobre ne disait rien des failles, seulement leur nombre, leur note et l’heure de sortie, en invitant à « se préparer dès maintenant ». Les archives de php.net de 2023 à 2025 ne contiennent aucune pré-annonce de ce type. Le projet s’y réservait le droit d’avancer la publication si des détails devenaient publics ou si des preuves d’exploitation apparaissaient ; selon Amazon, l’embargo a été levé à 14 h UTC comme prévu, et rien n’indique si le projet a été informé de la tentative du 17 octobre.

En 2024, la faille CVE-2024-4577, qui touchait PHP en mode CGI sous Windows, avait été corrigée le 6 juin ; six jours plus tard, la CISA l’ajoutait à son catalogue des failles exploitées, sur la foi de « preuves d’exploitation active ». Cette faille de 2024 supposait une configuration rare. Celles de mercredi ont été exploitées en démonstration sur Apache avec mod_php, la première avec les limites par défaut de PHP, la seconde aussi sur PHP-FPM ; et cette fois, les tentatives d’attaque ont commencé avant même que les correctifs ne soient disponibles.

Les citations de php.net, de GitHub, de WordPress, de la CISA, d’Amazon, de Cloudflare et du CERT-EU sont traduites de l’anglais par la rédaction.